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.