3.2 Plan Production Deployment
Part of running the pilot is also preparing a plan on how a production deployment could look like. And while we are not able to provide detailed steps in this cookbook, we still want to outline the necessary elements of such a plan on a high level.
- Infrastructure and Performance
- Resource Plan
- Support Plan
- Training Plan
Infrastructure and Performance
If you decide to go for JIRA Cloud, then this chapter can be skipped. However, any instance of JIRA Server will require hardware to run on.
In many organizations, the process of requesting supported server space and infrastructure can be thorough so you need to plan enough calendar time for this phase of the deployment. As a base of requirements, the server hardware requirements section of JIRA requirements is recommendable.
To further test the hardware requirements before deployment, you can also test the selected hardware by installing a JIRA instance and filling it with test content for a performance test. You can use the Data Generator that was developed by Atlassian to generate random projects, workflows, issues, etc comparable to your current production instance. The JIRA documentation also contains a chapter describing how to conduct performance tests using JMeter.
No matter how easy to use an IT system is, it will always require effort to administrate, maintain and manage it. Most important though is to define clear ownership of the system and roles that are responsible for its maintenance.
Roughly, the feedback we received from customers is that JIRA requires a full time equivalent (FTE) administrator for every 3000 end users in the system. The administrator should be in charge of schemes, workflows, permissions, etc. It seems a low headcount requirement on the administration side compared to other issue tracking software. One of the reasons why this headcount requirement is lower than with competitor products is the ease of extensibility.
Also, plan effort for hardware administration. JIRA publishes new releases every other month which might be requested by your organization. Also, once the JIRA instance grows in size, you might want to reserve administration resources for performance monitoring and tuning to ensure high productivity.
See also chapter 2.5 Enterprise Criteria
Make sure that you show how the new JIRA instance will be supported. As you are running ClearQuest, you probably can reuse the existing support teams and processes that supported your ClearQuest instance after they have been trained.
If not, we recommend devising a support process that captures incidents, change requests and how-to requests that users raise. Depending of the size of the support system and the number of its users, you can establish different roles / teams as follows:
First level Support
Assign this role to individuals or a team in departments / regions that can answer basic questions around the system and properly categorize raised issues by users.
Second Level Support
This role / team should handle cases that go beyond the scope of first level support. Make sure to plan extensive training for the members of this team. Atlassian offers JIRA Administration training that would cover the general functionality of the application. However, it is also important to train this team in the way your instance has been configured and customized according to the business processes of your organization.
Third Level Support
In case your organization has developed custom interfaces and add-ons for JIRA, the respective development teams need to be integrated into the support process. Also, show how the second level team works together with Atlassian and add-on vendors (if applicable) to resolve errors in the software itself. For the cooperation with Atlassian, show how http://JIRA.Atlassian.com is completely open and how Atlassian collaborates transparently with the user community on an issue level. Also, point out that Atlassian's Enterprise offering includes a 24x7 support coverage.
Last but not least, we highly recommend using JIRA itself to support its own instance. Set up a separate project that covers change requests, issues and How-To questions, create separate groups for each support level / team and customize the workflow accordingly. In case of the existence of service level agreements (SLA) between the support teams, Add-on Exchange has an Add-on to bring resolution and reaction times to JIRA.
Devise a plan how the users will be informed and trained to work with the new JIRA instance. Training activities and material should cover the usage of the new software itself (coming from ClearQuest) as well as the work processes that have been implemented in the tool and how to follow them during day2day business.
Make sure that you plan the production of user guides and other documentation that concentrates less on the general functionality of JIRA but the specific use cases in your organization's processes. The question to be answered should be "How do I need to use JIRA to perform my work".
To cover the general JIRA functionality itself, Atlassian has an offering called University that comprises interactive courses on a hosted JIRA instance that can be used to train users on basic and advanced functionality of JIRA Software and other Atlassian applications.
Key User Training
Identify users in departments and teams that are early adopters and make them key users for their groups. Give these individuals more advanced training and make them official power users that colleagues can refer to. The better trained and integrated these individuals are, the more work load will be reduced for your first level support team.
End User Training
Plan to roll out training for end users as the instance is rolled out. You can do this in the form of webinars, lunch meetings, blog articles and video tutorials. Also, you can foster a community culture around your instance and host a forum / enable commenting on documentation pages so that users can help each other.