Last updated on: April 07, 2020
This guide will help you understand the fundamentals of change management in ITIL and provide the necessary tools to implement effective changes using a well-defined change process.
- Introduction to ITIL change management
- The “what”
- The “why”
- How do organizations carry out change management?
- Types of changes in ITIL
- Change management roles and responsibilities
- 4 common change management challenges
- 10 change management best practices
- How does change management fit into the larger picture of IT service management?
Introduction to ITIL change management
The business landscape and customer expectations are constantly changing, and digital transformation has become a key contributor to the success of businesses across industries. Digital transformation is all about leveraging available technology to address business challenges and seize opportunities. When you break it down, digital transformation is basically IT management done better to eliminate problematic areas and equip your IT infrastructure to face business challenges. And this involves implementing IT changes that help your organization apply new technology to existing business and IT processes.
These changes can be as simple as moving collaborative apps to the cloud for better operational efficiency, or taking a mobile-first approach for a better consumer experience. Despite their simplicity on the surface, these changes come with their own logistical challenges. Not implementing a change properly can cause your organization to take one step forward and two steps back.
A popular bank's failed mobile app upgrade back in December 2018 is a great example of how not to implement a change. The bank's plan to introduce a new and improved mobile banking app was a great idea and a much-needed one. But from the moment the new app was launched, it had problems. The bank introduced the new app after it had already phased out the old one. When the new app failed to work, thousands of customers were left unable to access their bank accounts through the app. To make matters worse, communication about a fix for the new app was minimal, leaving customers frustrated. The mobile app was down for four days before the bank decided to bring back the old app.
We can see that the bank failed at various stages of its proposed change: releasing the new app when it wasn’t ready to be deployed, failing to be transparent and communicate downtime associated with the update to end users, and not coming up with an alternative plan in case of failure. Definitely not the way you'd want your change to be implemented.
This is where change management comes in; it helps you manage all the different changes in your organization and gives you a process for efficiently rolling out changes without affecting the rest of your organization. Change management reduces the chance of disruptions similar to what the bank faced.
In this guide, we'll cover the what, why, and how of change management. You’ll learn how to help your organization keep up with industry trends with effective changes.
Let's get right into it!
What is change management?
ITIL describes change management as the process of tracking and managing a change throughout its entire life cycle, from start to closure, with the aim to minimize risk.
Setting up a systematic change management process helps your organization implement incident-free changes with a high success rate.
What is a change?
According to ITIL, a change is "the addition, modification, or removal of anything that could have a direct or indirect effect on services."
At its simplest, any change to an organization's IT infrastructure that can affect the organization's operations is called an IT change. This includes replacing printers, projectors, servers, and more.
What’s the difference between an incident, a problem, and a change?
|Definition||According to ITIL, an incident is "an unplanned interruption to a service or reduction in the quality of a service."||According to ITIL, a problem is "a cause, or potential cause, of one or more incidents."||According to ITIL, a change is "the addition, modification, or removal of anything that could have a direct or indirect effect on services."|
|Scope||Restoring normal service operations as soon as possible||Identifying the root cause of disruptions to normal service operations||Implementing a change that addresses the root cause to prevent further disruptions to normal service operations|
|Nature||Reactive||Reactive and proactive||Reactive and proactive|
|Example||Users are unable to connect to the network. A workaround is issued to resolve the incident and give users access to the network.||A problem ticket is created to perform root cause analysis (RCA). A network switch is malfunctioning, leading to the incident. The switch needs to be replaced.||A change ticket is created to replace the defective switch.|
Why do organizations need change management?
Now that we know what change management is, let's look at why organizations need it, starting with the objectives of change management.
ITIL change management objectives
Give organizations the power to take control and manage their changes:
Change management will give you better control over your change process and help you implement changes with minimal risk. By following standard processes, change management ensures that all aspects of each change, such as planning, risk assessment, and tracking the implementation, are effectively managed. Utilizing a service desk tool to track changes from start to end can work wonders and enable an organization to better manage its IT infrastructure with well planned and executed changes.
Help organizations implement changes better:
By tracking the entire change process, change management makes it possible for organizations to stay on top of all change requests. It also makes it easier to identify and curb the number of unauthorized changes. By allowing users to submit a request for change (RFC) only through the service desk tool, organizations can collect all the necessary information about the change right at the beginning and then decide if the change needs to be implemented. A robust approval mechanism ensures that changes receive all the necessary permissions before they are implemented.
Enable continuous improvement:
Change management isn’t just for a rainy day; it aims to help organizations continuously improve their infrastructure and processes, as well as keep up with industry trends by ensuring they can smoothly roll out the necessary changes without affecting current service operations.
Change management benefits
To the organization:
- Fewer change collisions thanks to effective management of changes.
- The ability to roll out upgrades without affecting operations.
- Fewer failed changes.
- Accurate classification of changes.
To end users:
- Better communication about downtime and unavailability of services due to scheduled changes.
- Smoother service operations with fewer disruptions caused by poorly planned changes.
How do organizations carry out change management?
Let's now look at how you can implement change management in your organization. The first thing is to set up an effective change process that enables you to plan changes, get the necessary approval, and implement changes. Here is a change management process you can follow to effectively handle changes.
The change management process
Step 1: Submission
The first stage is initiating the change. This involves collecting basic change ticket information like the change type and priority.
- Creation: Change tickets are initiated with the service desk tool. The necessary information is collected right at the beginning using a change form containing mandatory fields.
- Defining change roles: By using change roles, organizations can delegate change responsibilities to various stakeholders and control the level of access each role has for each stage of a change.
Step 2: Planning
The next stage is where the planning of the entire change happens. A well-planned change is the secret to a successful change implementation. It is also essential to get the necessary approvals required to implement the change. Details like the impact, rollout plans, backout plans, and associated downtime are documented to clearly convey the change plan to stakeholders and convince them that the change is worth doing.
Step 3: Approval
Next, the change plan needs to be approved by the change advisory board (CAB), emergency change advisory board (ECAB), and any other authority that has a stake in the change or in the organizational infrastructure affected by the change. Creating custom CABs helps organizations group relevant personnel to easily manage approvals. Automating the approval process speeds up the entire change and ensures that no approval requests are overlooked.
Note: The CAB is a combination of various job roles and teams. It may include C-level executives, team managers, technical teams, finance staff, and more, depending on the severity and scale of the change.
Step 4: Implementation
Once the necessary approvals are gained, the change can be implemented. Organizations can track and manage the implementation of changes by creating tasks or using a project.
- Delegation of work through tasks: Tasks are created and assigned to different technicians from different teams to easily manage the work done by all those involved in the implementation of the change. Parent and child tasks can be used to set up task dependencies and ensure that tasks are done in a particular order and that no tasks are missed.
- Leveraging project management: Organizations can use projects to handle large-scale changes, like moving the organization's entire infrastructure to the cloud. Projects support a larger scope of implementation and can better handle a greater number of tasks, people, and milestones. Strong integration between change management and project management can be very beneficial to organizations.
Step 5: Review
Next, a post-implementation review is carried out to ensure there are no deviations in the implementation and any issues are ironed out before the change is closed.
Step 6: Closure
This is the last step in the change management process. The nature of the completed change is recorded as successful, failed, or incomplete. Recording the right closure code makes an organization’s metrics much more accurate and useful.
Types of changes in ITIL
Not all changes are the same, as some have different requirements. Some changes need to be implemented as soon as possible, some need approval from the organization's higher-ups, and some are just normal changes that are implemented on a weekly basis.
According to ITIL, changes can be broadly divided into three types: standard, normal, and emergency changes.
These are preapproved changes that are low-impact, well-known, and documented. Standard changes require a risk assessment and authorization when implemented for the first time, but subsequent implementations can be done without these precautions as long as the change hasn’t been modified.
Example: Replacing a printer’s ink cartridge
A normal change needs to follow the entire change process; it should be scheduled, have its risk assessed, and be authorized. Normal changes include both minor (low to medium impact and urgency) and major changes (high impact and urgency). All changes that aren't standard or emergency ones should be treated as normal changes and adhere to the change process.
Example: Moving on-premises services to the cloud
Emergency changes have high impact and urgency, requiring expedited assessment, approval, and implementation to get services up and running as soon as possible. Modifications to components that affect business operations, and therefore cause downtime, are treated as emergency changes.
Examples: Primary server failure, data center disruption, emergency patch for security vulnerability
Change management roles and responsibilities
The change owner is accountable for the entire change management process, including its improvement. Since they’re responsible for change management at their organization, they’re usually a high-ranking official.
The change manager handles the implementation of the change and the activities related to it. They also manage the CAB and the various teams and stakeholders involved, and coordinate with them.
The change initiator is the one who initiates the change and adds the change plans, implementation plans, and other required details. They also organize the change implementation plan. A change initiator can either be a technician or an end user.
The CAB is a collection of various members from different teams and job functions. Together they analyze the proposed change and give their approval and recommendations regarding the change and its implementation.
Some organizations use custom roles in addition to these four main ones to delegate work and break down responsibilities. Being able to create custom roles helps you tailor your change management to your organization's needs. A few commonly used additional roles are:
- Change approver
- Change implementer
- Change reviewer
- Change planner
|Process/roles||Change manager||Change initiator||CAB||Change owner|
|Defining change roles||C||R||-||A|
|Delegation of work through tasks||C||R||-||A|
|Leveraging project management||C||R||-||A|
* R - Responsible, A - Accountable, C - Consulted, I - Informed
4 common change management challenges
Here are four common challenges that can hinder change management.
Changes take up quite an amount of resources, as a lot of time and research goes into planning changes. A large number of failed changes can become expensive fast if left unchecked. In the case of infrastructural changes, a high failure rate can result in larger problems either during implementation or while implementing backout plans. Many failed changes is also an indicator of a poor change management process.
Example: Zylker planned to upgrade its primary network infrastructure, so the company set up an alternate network with a third-party network provider; it planned to implement the change over a weekend. During implementation, Zylker received tickets about services being down, which was surprising given that the company had set up an alternate network. Turns out that the alternate network provider was also performing scheduled maintenance that weekend, which meant both Zylker’s primary and alternate networks were down, rendering Zylker's services unavailable. Since the change was not planned properly, it ultimately failed.
Unauthorized changes are the result of a lackluster approval mechanism and failure to include the right stakeholders in the approval stage. These changes bypass the necessary permissions and may end being implemented if not flagged in time. Unauthorized changes can lead to changes that your organization doesn’t need or isn't ready to implement. The bottom line is that unauthorized changes are bad and an unnecessary expense.
Too many emergency changes:
As previously explained, emergency changes require expedited approval so they can be implemented as soon as possible. Treating too many changes as emergency changes may lead to delays in the event of a serious emergency change that needs to be implemented. It’s always good to exercise caution when classifying a change as an emergency change.
Note: The popular story about the boy who cried wolf is a good analogy for why treating too many changes as emergency changes can backfire. In the event of an actual emergency, your organization may not take the change with the seriousness it requires, and you may not have the required resources to handle the emergency.
Poor planning can lead to change collisions. A change collision is when two or more changes are inadvertently planned to be implemented simultaneously, disrupting the implementation of either change. Utilizing a change calendar to plan your changes better can help prevent change collisions.
10 change management best practices
Here are the best ways to approach change management.
Identify the types of changes:
Not all changes are the same. Changes have varying levels of priority and different requirements, as explained under the types of changes section. Therefore, it’s important to first identify the kinds of changes that your organization might perform, and then create different change types to effectively roll them out.
Design processes for different change types:
Since different change types have their own unique requirements, you need to design unique processes to fulfill those needs. Using the same change process for all change types will only lead to unnecessary delays and incomplete change implementations.
Note: You can create different change workflows for each of your change types.
Define key roles and responsibilities:
Defining roles allows the change manager to delegate activities and responsibilities to others. Roles make it easier to manage changes, and they clearly define the activities that each person can perform.
Log, manage, and prioritize change proposals:
It’s a best practice to have an organized way to log your changes, as well as manage and prioritize them in one place. With better visibility into your organization's changes, you can prioritize which changes need to be performed ahead of others.
Gain clear insights on the risks and impact of changes:
All changes need to go through risk and impact analysis to understand the change better and allocate the necessary resources. The risk and impact details should be added at the planning stage so the CAB has a clear picture of the change and can give their recommendation.
Put an effective approval mechanism in place:
Defining the approval process makes it easy to get the necessary permissions for a change to be implemented. It ensures that all key stakeholders are aware of changes and give their recommendation before a change is implemented. This helps curb unauthorized changes.
Communicate schedules and downtime with stakeholders:
Keeping stakeholders informed of planned changes reduces the number of incidents caused by changes. Delivering prompt information also ensures that no services are affected due to changes, and that the change can be carried out effectively. As a bonus, management is also happier when they’re informed throughout the change life cycle.
Measure the progress and effectiveness of change implementations:
Keeping an eye on a change throughout the entire change life cycle ensures that nothing goes wrong and that the change is implemented according to the change plan. Measuring key metrics gives you a clear picture of how effective your change process is and also lets you identify areas you can improve.
Keep contingency plans in place:
You can never be too prepared, so it's always a good idea to plan for the worst-case scenario and come up with a backout plan during the change planning stage. This in-depth planning can mean the difference between a run-of-the-mill failed change and irreversible damage to your IT infrastructure.
Implement continual service improvement:
Although firefighting is a crucial function of change management, changes have a wider scope in your organization. Using changes to improve technology and processes, and thereby continually enhance your organization’s ability to provide better services, is becoming an important function of change management.
Set up your own best practice change management process with ServiceDesk Plus
How does change management fit into the larger picture of IT service management?
Change management doesn’t end with just completing a change. Change management's ability to effectively roll out changes can greatly benefit from information collected in other ITSM processes, and vice versa. The ability to associate incidents with the changes they caused or were caused by, or update the CMDB based on IT infrastructural changes, are just the beginning of creating a wholesome ITSM practice that works together to help manage your organization better.
Here’s how change management can work together with your other ITSM processes:
Tracking the incidents causing a change and the ones caused by a change gives you a better understanding of how changes affect your organization. For instance, when a router is being updated, you might get incident tickets reporting that the internet is down. Associating changes with the incidents they caused helps you quickly identify the cause of an incident and forego having to assign resources to fix that particular incident, as it will be fixed as soon as the change is completed.
It’s important to use changes for high-impact service requests to keep your IT infrastructure updated. Without changes, a service request for a server upgrade or a request to upgrade the Azure storage space ends with the service being delivered. But when you use a change to implement the service request, you can collect more information like the reason for the change and the implementation plan, get the necessary approvals from all stakeholders, and update the CMDB with the new information.
Note: Using a change for request fulfillment works best for high-impact service requests and any service requests that require a change to the CMDB. If it requires the CMDB to be updated, then it needs a change!
Problem management requires creating a change to fix the root cause of a problem. Being able to create an RFC right from within a problem ticket makes it easy to track associated changes and problems. It also gives the CAB a better picture of why the change is required, and denotes the severity of the problem that initiated the change.
Release and deployment management:
Release and deploy upgrades benefit from the structured approach that the change process brings. You can easily track the implementation plans, rollout plans, and the actual implementation of releases and deployments using changes. The transparency and visibility changes offer also helps keep all stakeholders informed.
Any updates to the CMDB should always be done with a change. A change provides a lot of useful information on why, how, and when the update was done. The impact analysis performed alongside a change also ensures that any updates to the CMDB are properly analyzed and that the update does not create any disruptions to the rest of your organization. You can use change types to record CMDB updates of varying priority.
Make your ITSM wholesome
Change management KPIs
Here are some important metrics to measure the effectiveness of your change management process.
|Number of unauthorized changes||The number of unauthorized changes identified over a particular period of time||A lower number indicates that your approval process is robust and capable of managing all changes.|
|Number of high-impact service requests fulfilled without a change||The number of high-impact service requests fulfilled without a change over a particular period of time||High impact service requests need to be fulfilled using a change. A higher number is a sign that your infrastructure is vulnerable to issues like failure to update the CMDB.|
|Percent of backed-out changes||The percent of changes that used their backout plan due to issues during implementation||A higher number is an indicator of poorly planned changes.|
|Change acceptance rate||The percentage of changes that were approved by the CAB||This indicates the effectiveness of your change requests and change plans. A higher number is a sign that your changes and planning are solid.|
|Schedule variance||The deviation in time consumed and the estimated time||This indicates if your changes are implemented on time and adhere to the change plan.|
|Number of incidents caused by change||The number of incidents caused by a particular change||This indicates whether a change affects other service operations. A high number is sign that changes need to be communicated better.|
|Percent of changes completed on time||The percent of changes completed on time||This indicates whether the change process is working at optimum efficiency. The higher the percent, the better your change management process.|
Let's look at a change in detail to see how you can improve your change management process.
Zylker, a company with a huge number of remote users, decides to take the cloud route.
Currently, all of the company’s productivity applications and resources are in-house, so remote users are given VPN access to the network. In order to provide faster access to data, Zylker decides to start using cloud applications. It chooses Zoho One for its productivity suite, and Office 365 for email. Part of the company’s resources, like its file servers and databases, are still on-premises, so remote users have to be given access to those as well.
To achieve this requirement, the IT team sets up a hybrid Azure Active Directory (AD) environment. They provision a federation server to replicate their on-premises AD in the cloud-based Azure AD. Now end users, even remote users, can access cloud resources with their AD credentials.
Step 1: Raising the RFC
The first step is to raise a change ticket and collect the necessary information about the change, like the change type, change impact, and urgency, and set the change roles. The change initiator can easily raise a change ticket using their web portal and pick the relevant change template and change type. The change template collects all the necessary information using mandatory fields. Here, the change initiator sets the change type as normal, selects the appropriate change template, assigns the change roles, and gives a description for why the change is required.
Step 2: Planning the change
Next, the change initiator adds the change information, such as the reason for the change, detailed information on its impact, rollout and backout plans, and scheduled downtime. The change initiator also adds all associated incidents and problems to better track the change and its impact. Below are the various plans the change initiator came up with.
- Get Azure AD and Office 365 accounts
- Set up Active Directory Federation Services (ADFS)
- Initiate sync between on-prem AD and Azure AD
- Configure single sign-on
- Sync on-premises Exchange with Office 365
Since the existing configuration is intact, revert to the old configuration and resume services.
Planned downtime: 12 hours
Step 3: Getting the right approvals
The change manager sets up CABs to review the change plan and give their recommendation on whether the change needs to be implemented or if the plan needs to be modified. Since this is a large-scale change, approvals are required from various job roles spanning a variety of functions. Here is a list of CABs and members involved in the approval process:
- Executive CAB:
- Chief information officer (CIO)
- Chief technology officer (CTO)
- Chief financial officer (CFO)
- Chief executive officer (CEO)
- Technical CAB:
- Service delivery manager
- Operations manager
- Information security manager
- Data protection officer
- Business CAB:
- Business administration manager
- Human resources manager
- Business relations manager
Step 4: Implementing the change the right way
Zylker utilizes tasks to track the implementation. Tasks are assigned to different technicians, and the order in which they need to be done is defined using task dependencies. The change owner can easily track the progress of the change implementation and manage tasks all in one place.
Here is how Zylker broke down the implementation into tasks to make it easy to track and manage the implementation of the change:
- Prepare Office 365 and Azure AD
- Set up an ingest server
- Initiate data migration
- Configure Azure AD proxies
- Check the data integrity
Step 5: Sticking to the plan
Next, the change implementation is reviewed by the change owner/manager to check for any deviations from the plan. Any deviations are reported and fixed before the change is deemed successful.
Step 6: Closing the change ticket
Finally, the change is closed and a closure code is assigned based on the nature of the change closure.
Step 7: Mustering metrics
The change manager measures certain KPIs to ascertain how efficient the change process is and identify areas that can be improved.
Change management feature checklist
Here is a list of features that you need to keep an eye out for when choosing a service desk tool. Having these features in place will help you implement an effective change management process in your organization.
Change creation and logging
- Create changes from incidents and problems, and carry over the necessary information.
- Collect required information with custom change templates.
- Create different types of changes, and build unique workflows for each type.
- Involve the right stakeholders, like the change owner, approver, line manager, and change reviewer, using change roles.
Change planning and evaluation
- Create elaborate change plans featuring impact analysis and rollout, backout, and downtime plans.
- Maintain a checklist of essential steps to be completed.
- Form multiple CABs.
- Configure multiple levels of approval. Mark whether the RFC has to be approved by all members of the CAB or by any one member.
- Allow the change manager to have final say over the approval of the change.
- Bypass approvals from the change manager and change approver by auto-approving the change when all CAB members recommend it.
- Mark end users as service request approvers.
Coordinating change implementation
- Break down changes into tasks, and use work logs to estimate how long it will take the change implementation team to complete activities.
- Streamline implementation by creating projects from a change or associating a change with existing projects.
- Track all associated incidents and problems that caused or were caused by the change.
- Schedule downtime and announce it to key stakeholders.
- Keep stakeholders in the loop with regular notifications.
Change review and closure
- Document post-implementation review (PIR).
- Create distinct workflows for different change types and processes with varying levels of complexity and functions.
- Configure various actions like conditions, switches, notifications, field updates, and approvals during the transition between stages.
- Draw up change workflows on a drag-and-drop canvas.
Tick all the boxes for effective change management
The addition, modification, or removal of anything that can have a direct or indirect effect on services.
Change advisory board (CAB):
A team of various stakeholders who give recommendations about the change and approve the change plan.
When two or more changes are inadvertently planned to be implemented simultaneously, disrupting the implementation of either change.
The process of taking changes to completion with minimal disruptions and collisions.
The delegation of responsibility over the various aspects of the change to different members of the organization.
Used to record the nature of the change closure, such as failed or successful.
Configuration management database (CMDB):
A repository of all configuration items and their relationships.
Continual service improvement:
The process of identifying and fixing areas that can be improved to make services better.
The period of time when a particular service in not available.
An unplanned interruption to an IT service, or a reduction in the quality of an IT service. Failure of a configuration item, even if it has not yet affected a service, is also an incident (e.g. failure of one disk from a mirror set).
A cause or potential cause of one or more incidents.
The process of evaluating whether the change plan was followed without deviations, as well as examining the implementation to see if anything needs to be changed.
Request for change (RFC):
The process of initiating a change with a valid reason.
The process of evaluating the potential risks involved with a change.
The point of communication between service providers and the organization’s users.