Atlassian product evolution
In 2013 Atlassian realized that nearly 40% of their customers were adapting the basic Jira platform to be a tool for managing “service requests”. With this realization, Jira Service Desk was released – which essentially was a version of Jira, pre-built to handle the needs of a service desk (for any part of a business, but primarily starting with IT).
In 2020, Atlassian released Jira Service Management as their next-gen evolution of Jira Service Desk. The opportunity captured here was the expansion of a service desk product to an end-to-end service management solution, most specifically targeting advancements in IT Service Management (ITSM). The results of this launch have been highly successful in helping IT operations and development teams respond to business changes and deliver improved customer and employee service experiences fast.
A typical customer journey
Jira is an effective tool for managing work, but has evolved to meet many organizational use cases beyond issue tracking for development. Prior to the introduction of Jira Service Management, many organizations leveraged Jira Software for Change Management, thereby proving it is possible.
Essentially the 2 primary choices at hand are structure based:
- Centralized approach: Create a separate “Change Request” project with an issue type named “Change Request” that users will use to submit changes, OR
- Decentralized approach: Create a “Change Request” issue type and associate that issue type with all projects that eligible to create change requests
Option #1 is a more scalable approach, as you’d only need to manage one project and one issue type for change requests specifically. If a field needed to be changed, in a singular project, you would only adjust one field configuration whereas if multiple projects are used, you’d need to modify all of the schemes that utilize that change request issue type.
Option #2 is effective such that users that only work within their own Jira project can easily submit change requests inside of their own project without having to go to another project to submit a CR.
In either use case, once users submit a change request, we can use validations so that only specific users can move tickets from a “To Do” state to an “Approved” state for example. Those specific users are generally part of a Change Advisory Board (CAB) in more structured organizations. This means that in order for work to be approved and ready to be worked on, users need to get approval from a member of the CAB.
Additional functionality and processes can be built coming out of this, such as having specific stages in the workflow to show that issues are Approved for Development, Approved for Testing, and Approved for Production as examples.
An ideal end-state
Although the above is a perfectly feasible way of managing Changes, Jira Service Management represents a target end-state that is ITIL aligned. This is important, because as the Jira Service Management product evolves, and your organization matures, there are significant opportunities for automation and integration that will be challenging to implement within Jira Software. Key Differentiators for Change Enablement:
-
- Jira Service Management streamlines the typically manual process of change management with approval workflows, risk assessments, automation, and collaborative planning in Confluence.
- The integration with DevOps workflows speeds up changes, so developers can create and track change requests without leaving their CI/CD tool.
We recommend that organizations keep an open mind, and make educated decisions with longer term plans weighting the decision-making process.
If you’re interested in implementing this type of functionality, structure and process in your organization, contact us here as we’ve helped countless clients utilize Jira for change management.
