1.7 Pilot Configuration Aspects

After you have installed / set up a trial instance, you might want to spend some time planning the pilot phase of the project. One major lessons learned in this phase is that the vast flexibility and customizability of JIRA should be taken advantage of to adapt the instance to the specific requirements and business processes of the organization. Spend some time to familiarize yourself with the issue type, field configuration, notification, permission and workflow schemes. What you don't want is to run an out-of-the box version of JIRA and discover the configuration capabilities once the project is on its way.

Pilot aspect

JIRA configuration item

Comments

Select Participating projects

Project, users

Generally, it is recommended to choose fertile ground for the first JIRA project. Select a group that wants to take advantage of JIRA's benefits, e.g. the improved ALM collaboration or the introduction of agile methodology for a new project. It would be also to your advantage if the members of that first group are early adopters. This will help enormously with the change management in the first stages.

Determine ticket types

Issue types, fields and field configurations

JIRA comes with a set of pre-populated issue types and fields. But know that those can be renamed, removed and amended. Make sure to determine which types of tasks, issues, requirements, change requests, etc the project should entail. Also, distinguish those issue types that require different fields and workflows and therefore should be dedicated their own issue type. Also, consider your existing corporate language around tasks, issues, requirements, etc. instead of using the default JIRA labels.

Determine statuses and transitions

Workflow

Before going into the workflow designer and start drafting new workflow schemes, you might want to do some planning on paper first. Line out through which work statuses each issue type will go through and which activities by which group or role are necessary for the respective transitions. Most of the time, a simple Open - Progress - Resolved will suffice. However, in some cases like software development, separate stages that indicate the different stages of completeness of a software requirement can help, e.g. 'requested', 'specified', 'development progress', 'in QA', 'resolved' whereas issues would transition from phase to phase, be visually distinct (e.g. in the Rapidboard of JIRA Agile). In case the project team already has established and proven business processes, rebuild them in JIRA using the workflow designer or editor to prove the powerful customizability of the application.

Determine stakeholders

Project roles

If there are specific stakeholders in the project you can create project roles and assign them to individual users. This is for example useful as you can make a project role an automatic assignee of an issue after a specific status transition. E.g. When an issue enters the stage 'resolved', then the issue could be automatically assigned to the role 'QA Dispatcher' who then organizes the testing of the issue. However, also make sure that processes don't overly rely on the action of specific individuals in order to avoid bottle necks.

Plan components, versions and releases

Components, version

Each project might have certain sub-areas which you can use components for. These could be parts of a software product or areas of expertise in the project. You can use this field to group issues, requirements and change requests. Also, populate the versions of the project which could be software versions, SPRINTS or in the case of pure project management major milestones.

Pilot Training

Atlassian university, CAC

Although the implementation of JIRA is in a pilot stage, make sure that participants are trained in how they should use the system to fulfill their work. This can be done using process documents that roughly sketch out the necessary steps to take in the system. You can also make use of Atlassian University which has courses to perform certain actions as well as refer to Atlassian's official documentation

Business Metrics

Dashboards, Reports

Enquire from the business stakeholders in Portfolio Management and Finance which key performance indicators and other metrics are required. With some customers, JIRA really took off once time-tracking (especially with Add-Ons) was demonstrated to the financial department. Also focus on productivity and forecast reports. Filters can also be used to identify trouble issues or areas were work has been stopped. Set up various Dashboards for the different project and business stakeholders and use them in regular meetings.

 

Pilot system adjustments

schemes / custom fields

Take an agile approach to the pilot project itself. You might not be able to plan the ideal JIRA scenario in the beginning. Instead, the working knowledge produced by the pilot team should be harnessed. Schedule regular pilot project review meetings (iteration meetings) In which the system itself is reviewed and implement respective changes afterwards. This will create ownership and motivation among the pilot team and could spread the word further.

Welcome ideas for other usage

Further projects / schemes

While the scope of the pilot project should be clearly defined, invite other departments to review the instance and demonstrate the flexibility of the system. Welcome other ideas for using JIRA including non pure-development areas like project management, service desk, HR, support, time-tracking, etc. Setup new projects with separate schemes in which these ideas can be quickly visualized and demonstrated.

Do not create ClearQuest in JIRA!

One of the lessons learned by our customers is not to re-create exactly your ClearQuest field and project hierarchy structure in JIRA. Take advantage that you can create more than one project and align them with the actual teams and products of your company. Also, leverage the ability of tracking many ticket types such as improvements, change requests, knowledge article, user story, epic, etc and keep them in the same context as your defects. In the past, issue trackers have been often used by Quality Assurance Departments only - JIRA is meant to bring all the teams in the Application Lifecycle Management process together!

Less is more

Although you will spend time thinking about these different project parameters, one danger that arises from configuration and customization being that easy is overkill. At the first stage of the Pilot, make necessary adjustments but don't overdue it (e.g. you don't need 50 ticket types or 10 workflows for your first pilot iteration). Leverage an iterative approach and implement changes / extensions according to user and stakeholder feedback.

Last modified on Mar 3, 2014

Was this helpful?

Yes
No
Provide feedback about this article

Not finding the help you need?

Ask the community

Powered by Confluence and Scroll Viewport.