When organizations decide to migrate their Atlassian Jira instance to the cloud, it’s often to relieve the administrative and financial burden on their organization from having to store, manage, and maintain their own servers, as well as the upgrades, updates, backups, and security that they’re responsible for.
They’re also eager to take advantage of the scalability available with Cloud Premium and the remote access that their teams can use to collaborate on-the-go.
But to truly reap the full performance and productivity benefits of a mature cloud infrastructure, there are some best practices to perform during onboarding to make sure you set your teams up for success.
One of those is creating a change request protocol. In other words, a standard, defined process that your teams must use to submit a request to change a workflow in Jira.
Why Do I Need a Change Request Protocol?
When Jira users are working day-to-day in Jira, it’s not uncommon for them to make ad hoc change requests to workflows or custom fields. It’s also not uncommon for administrators to allow these changes without giving it much thought.
Furthermore, it’s often considered regular practice for administrators to also over-do it on user provisioning to relieve the burden of fielding change requests and give more autonomy to individual teams to configure as they see fit.
While this might seem like a good idea at the time, it can degrade hygiene and search functionality later on down due to unnecessary complications and duplication. As these compromises increase, it can create issues that make your Jira software can be rendered unusable just a few years later.
Instead, it’s recommended that you build a solid permissions scheme and change request protocol into your onboarding process. In this post, we’ll review the best practices for implementing this practice and how they help you avoid the downfall of your Jira infrastructure.
Additionally, if you’d like to learn more about which organizations are best for a Jira Cloud migration and how to optimize for a fully-functioning, mature cloud infrastructure, see our latest whitepaper, Lessons Learned From Jira Cloud Migrations.
Without further adieu, let’s get to your change request protocol!
How to Create a Change Request Protocol
As a Jira administrator, it can get quite overwhelming when faced with the number of requests that come in on a weekly, and even a daily, basis. If you’re part-time or a sole administrator, it can be downright impossible to manage.
It can be convenient to allow teams the authority to make changes as they deem necessary to attain more autonomy and relieve some of the administrative burdens. But as we’ve said earlier, this is not advised.
A wiser practice is to create a change request protocol where team leaders can prioritize requests from their teams before sending off to the Jira administrator.
When doing this, create a standardized intake, prioritization, and decision-making framework that you and team leaders can adhere to at the individual level. In addition, to creating a more orderly process, you also now have a paper trail of all requests that were approved or denied in the event that there is a discrepancy down the road.
Change Management Considerations
Here are a few considerations, you’ll want to make when creating a change request protocol:
- Create a Jira project, workflow, and custom field for each request use case you anticipate getting.
- Create a custom field to indicate whether a request is approved or denied.
- Create a backlog for change requests.
- Update documentation associated with accepted changes to avoid confusion later on.
- To limit the number of change requests you get, limit submission to a select team representative.
- Test changes by creating a sample configuration to validate and correct any flaws before full implementation.
- Notify all impacted users of the change and include the rationale for the change so users aren’t caught off guard.
- Consider implementing changes during non-business hours to avoid any work disruption
Creating a change request is a proactive way to avoid a black box Jira instance that will kill productivity and functionality over time.
Test Changes First
Just like you would for any other major Jira rollout, creating a test project before fully launching any change is recommended, particularly because Jira Software does not provide a staging environment.
Experiment with the test configurations and once you’ve ensured its functionality, copy the respective scheme, and apply it to the project in question.
When to Implement Changes
Once you’re satisfied with testing and ready to push the changes live, there are a few final considerations to make.
- Notify all impacted users of the changes that will be pushed through and explain why the changes are being made.
- Include a knowledge base of all release notes, change request tickets and Jira issues submitted so that users understand the rationale and context behind the change, and aren’t caught off guard by sudden dramatic changes.
- Be considerate of when these changes are pushed live. Best practices dictate to implement changes during non-business or non-peak hours, over the weekend or in the late evening. This way you won’t disrupt any work in progress by team members.
- Be sure to give yourself enough time to troubleshoot any unintended configuration breaks that happen as a result of the change.
If you’re not already in Jira Cloud and want to test Atlassian Cloud, there is a free extended cloud trial that will allow you to explore and test the cloud over time to make sure that it’s the right fit for your organization.
Also, if you’re considering migrating to Jira Cloud or looking for an expert hand to help your organization get the most value out of cloud infrastructure, please contact us to set up a consultation today!
We’d love to help you through this process and optimize your infrastructure for best practices so that you’ll be up and running on the right foot.
At Coyote Creek, as an Atlassian Platinum Solution Partner, we know it’s the human connection that makes the difference in all that we do.