Change management

What is change management?

• Services should be stable, reliable, and predictable.
• Services need to be adaptable to rapidly evolving business requirements.

Change management applies a formal process to accomplish change and is sometimes thought of as making change more difficult by creating more work for the IT team. But a properly implemented change management process enables a streamlined approach to capturing change requirements while enabling the proper governance needed for success.

Benefits of change management

Adopting a standardized ITIL approach to change management enables an IT organization to deliver significant improvements.  An effective change management process provides the following benefits.

• Provide a standardized approach for prioritizing and responding to business requests for change
• Reduce failed changes and service disruption, defects and rework „ 
• Deliver change promptly to meet business timescales „ 
• Provide better estimations of the quality, time and cost of change 
  
• Comply with all governance, legal, and regulatory requirements for tracking changes to IT systems
• Improve the overall productivity of IT teams by minimizing disruptions due to high levels of unplanned or emergency change

Change management process

This process represents a streamlined approach to a request for change based on ITIL recommendations. It address the two most common types of change requests: standard and normal. This example provides a starting point from which you can adapt your existing processes and support procedures.

Changes management roles

How your IT team is structured to manage change requests will vary by IT organization, but there are a couple of key roles to consider when defining your support process and procedures.

The change requestor is an IT team member that works with IT systems who provides support services for customers. When they recognize a need for a change to an IT system, service or application, they will raise a formal request for change. This request should be fully documented and clearly indicate the service and system impacted by the change.

The change manager  is the one responsible for managing the change procedures. As part of their responsibilities, they  review and prioritize all change requests, and evaluate their change risk level. In some IT organizations, they may provide the initial level of approval before the change is allowed to move into the detailed planning stage. The change manager is responsible for scheduling the change implementation date based on the use of a centralized change calendar. They also review all changes once they are complete to monitor the overall quality of the change process.

The  change advisory board  (CAB) is responsible for reviewing and authorizing change requests when the change manager has determined there is a high risk associated with it. The CAB takes into account the impact that a change request may have on the business and all affected organizations. When high-risk changes occur it's the responsibility of the change manager to communicate the appropriate information about the change to the CAB. In an effort to keep the change process streamlined and efficient, the use of a virtual CAB may be an effective means of managing this part of the process. A virtual CAB leverages the use of technology to communicate the high-risk change and indicate their approval or disapproval with ease in the change record. In the case of some high-risk production changes a formal meeting may be required to determine how to proceed.

The  change implementation team  consists of the specialists across your IT organization who are responsible for actually making changes. You will likely be part of this team and employees directly under you may also be assigned to implement changes. The change implementor is responsible for completing the change request and documenting all work completed in the request.

Changes request types

There are three different types of change requests that are typically managed in different ways:

Standard change

Standard changes are pre-approved changes that are considered relatively low risk, are performed frequently, and follow a documented (and change management approved) process. Think standard as in, ‘done according to the approved, standard process’. Not standard, as in run-of-the-mill. The process for a proposed standard change is presented to change management to review/approve. The proposed standard change describes how the change and associated risks will be managed. Once change management has approved the standard change, it can be carried out in production as needed. It’s worth noting that standard changes, even after approval, are still under the jurisdiction of change management. If standard changes start causing incidents, change management can bring the standard change back for review and request changes as needed.

The primary purpose of standard changes is to provide a way of streamlining the process to enable rapid implementation of frequent changes while managing the risk. A standard change must have a documented process that’s been reviewed and approved by change management. 

Normal change

Normal changes are the run of the mill not ‘standard’ and non-emergency changes that require change management review. They are raised as Request for Change (RFC), reviewed by CAB (Change Approval Board), and approved or rejected by the Change Manager. Normal changes are often non-trivial changes to services, processes, and infrastructure. 

Emergency change

Emergency changes arise when an unexpected error or threat occurs, such as when a flaw in the infrastructure related to services needs to be addressed immediately. A security threat is another example of an emergency situation that requires changes to be made immediately. 

Change Management process summary

The ITIL change management process includes many vital steps to ensuring a change request is successfully completed.  Here's a summary of the vital steps included in a change management process:

1. Request for Change - the first question to consider in your IT organization is who should be allowed to request a change and what is the proper procedure for creating one. You want a simple and streamlined process that is easy to use and enforce. When an IT team member creates a request for change, they are responsible for documenting the details that will help others understand what change needs to be implemented, and why they are making the request. The initial change request should included details about what service and IT system is impacted, the expected risk, and the implementation details if known at the time of submission. The more information they include at the beginning, the more efficiently the request will move through the process. Here's some information that may be included in the request for change:
   • Description of how the change will be implemented
   • Is this change request the result of any related incidents?
   • The impact that the change would have on all associated services and systems
   • Change impact, urgency, and risk assessment
   • Contact information for everyone involved in the change
   • Listing of initial change approvers (this list may be modified by the change manager)
   • Backup plan to follow in case the change is not successful
2. Reviewing a Request for Change - the change manager or their designated member is responsible for reviewing and evaluating all change requests submitted to the change management team. During this stage of the process they will evaluate the change request to determine if the request is reasonable and provide feedback to the requester if additional information is required. In some organizations a formal approval process by the change manager is put in place to provide a check-point before a change request moves onto the planning phase. During this review, the change will be evaluated according to the impact the change will have on the IT services, systems and business. The ultimate determination a change manager has to make at this point is the likelihood of a successful change implementation and the impact on the business.   
3.  Planning for a Request for Change - once a change request moves into this phase it's ready for the detailed planning that is required to ensure it is successfully implemented. Some of the information documented in the change request includes the following:
   • A detailed change plan that outlines the course of action for implementing the change. The details should include the type of change, the priority associated with a change request, and the outcomes that could occur if the change is not made.
   • A complete listing of resources needed to complete the change.
   • Change implementation timeline - change manager will assist with choosing the appropriate dates based on a centralized change scheduling calendar they maintain that helps determine the best timing for when a change should occur.
   • Change testing plan - typically needed for major production changes where a successful test point is needed before implementing the change in production.
   • Change back out plan - for higher risk change requests a back out plan is needed so the IT team has a document to refer to if they need to quickly roll back the change.   
4. Approving a Request for Change - based on the type of change and risk the change manager will route it to the appropriate groups for approval. This may be a simple peer review or a more involved CAB approval for high risk production changes.  
5. Implementing a Request for Change - Implementing a change, especially in a production environment, is not a simple process. The change has to be constructed and prepared during the planning process, this is where most of the hard work is completed. Once the change has been implemented, tests must be done to determine whether the desired results have been achieved. If the change is not successful, troubleshooting may be used to determine what went wrong, and to implement a backup plan to alleviate the issues that necessitated the change request. It is very important that the change implementation assignee documents the results, whether the change is successful or needs to be rolled back. This information is valuable to help the team learn from any failures so they can improve their process and capabilities in the future.
6. Change closure and review - The post-implementation review is an essential part of the change management process and a key aspect for improving the change management process. This part of the phase allows the change management team to understand whether your change procedures are working as effectively as possible. During this phase of the process the change manager will review a completed change request to determine whether the change was successful, whether the change timing was appropriate, and the expense of the change to determine the accuracy of estimates that were made during the planning phase. Reviewing change performance on a regularly basis provides an excellent check point to fine-tune your change management process for improvement.

Setup for change management in JIRA Service Desk

Configure the workflow and fields with the Change Management workflow add-on

We built the following workflow add-on based on the ITIL framework for change management:  https://marketplace.atlassian.com/plugins/com.atlassian.servicedesk.change/server/overview.

You can use this workflow as a basis that you can then build out your own change management process on.

To use the workflow from the Marketplace:

1. Log in as a user that has the JIRA administrator global permission, and follow the instructions listed here to import a workflow.
2. To have the fields created by the workflow import displayed on your change issues, activate the screen by following the instructions here: https://confluence.atlassian.com/adminjiracloud/defining-a-screen-776636475.html#Definingascreen-Activatingascreen.  

What does the workflow look like? 

This sample workflow has the following transitions and statuses. 

When you import it, the workflow will create a few screens and some custom fields for you as shown below:

*To display these fields for your 

Change management fields

We recommend the use of the following fields to support your change management process:

• Description: Use this field to capture the summary of the change request 
• Business Justification: Describes the business reason for implementing the change
• Status: Indicates the current state of the change request. 
• Pending Reason: Specifies the reason for why a change request is moved into pending and what the change request is pending on. 
  • Example values: Waiting on vendor, More info required, Awaiting approval, Pending on change request
• Priority: This is determined by the urgency and impact of the change. Your team can define the value matching according to your own processes. 
  • Example values: Critical, High, Medium, Low
• Urgency: A measure how quickly a resolution of the change is required
  • Example values: Critical, High, Medium, Low
• Impact: A measure of the extent of the change and of the potential damage caused by the change before it can be resolved.

  • Example values: Extensive / Widespread, Significant / Large, Moderate / Limited, Minor / Localized

• Operational categorization: Classifies an change for the purpose of assignment and reporting from the operational perspective. 
  •  Example values: Configuration > Printer
• Product categorization: Classifies an change it for the purpose of assignment and reporting from the product perspective. 
  •  Example: Hardware > Printer
• Change type:  Classifies the type of change to be implemented. Change types include Standard, Normal, Emergency.
• Change reason: indicates the reason for attempting the change. This field provides classification that is useful for reporting purposes.
  • Example: Repair, Upgrade, Maintenance, New Functionality, Other
• Change risk: Classifies the overall risk of implementing the change. The higher the number the higher the likelihood of a failed implementation.  Various methods exist for determining the change risk based on an assessment of various factors which include: complexity, scope, testing, recovery and timing associated with the change. The change manager should review these factors to determine the appropriate change risk value to assign to the request.  
  • Example: Critical High, High, Moderate, Low
• Change Start Date: identifies the start date for when the change will be implemented
• Change Completion Date: identifies the completion date for when the change should be completed
  
• CAB Approval: indicates the persons resonsible for reviewing and approving a change request before implementation begins.
• Component: Indicates the service impacted by change
• Resolution: Classifies the reason for completing the change. This is referred to as Change Closure.

Change scheduling

A change schedule (sometimes known as a change calendar) gives you an clear graphic view on past and future change requests. This calendar view of change requests allows you to co-ordinate your change events with major business events and/or scheduled releases.

With Team Calendars for Confluence, you can visualize and track change request raised from JIRA Service Desk on the calendar view. It's easy to see the full details for change requests from the calendar view by going to the issues themselves. 

To set up the change calendar: 

1. Add Team Calendars for Confluence to your site. 
2. Go to the Confluence and choose the space for your team, e.g. 'IT Sample'. 
3. In the left sidebar, click Calendars. 
4. Select Add Calendar (top right).
5. After a Calendar is added, select Add Event.
6. In the Add Event dialog, on Event type dropdown select JIRA Issue Dates. 
7. For Display, select JQL "advanced". In the JQL type in:  project = "Your IT project name" AND issuetype = Change
     
8. A list of dates should show up, select "Add start and end date..." under Date range and select Change start date as the start date and Change completion date as the end date.
   Note: these two fields are added by the Change Management for JIRA Service Desk workflow mentioned above. If you have your own fields for the dates, use your own fields in this step. 
9. After clicking Add and then OK, you now have a change schedule! 

From now on, whenever a change request is raised in the project, the change schedule will automatically display it on this calendar.