Service Level Management
Service Asset and Configuration Management
IT Financial Management
Background System Management
IT Process Automation
Incident Management Automation
Deploy and Monitor
Alerts and Notifications
IT Health Status
Digital Experience Monitoring
Looking to learn about all things ITSM, ESM, Self-Service, Knowledge Management, AI, and more? We've got you covered.
We’re committed to providing resources that help you address all of your ITSM software needs.
Stay up to date on our latest ITSM, ITOM or ESM webinars and events now
The one change that will always remain consistent in life and business is change itself. Changes can happen at any time within your organization, which is why having a standardized ITIL change management plan is essential.
For purposes of this blog we will refer to “the change management process” as described in ITIL v3/2011, as opposed to “the change enablement practice” which are the latest best practices updates in ITIL 4.
In this post:
In short, the ITIL v3/2011 change management process provides organizations with a proven methodology for handling changes to the corporate IT infrastructure and operations. Whether this relates to hardware, software, services, or even the (ITSM) capabilities used to deliver and support corporate IT services.
The formal definition from the ITIL 2011 Glossary describes change management as:
“The process responsible for controlling the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services.”
The ITIL change management process flow includes five stages:
Change management is ultimately a balancing act between the need for speed and the management of inherent risks associated with a change. After all, no organization wants its latest change to cause its customers and/or employee’s issues, nor the IT service desk to be drowned under a deluge of change-related incidents. This unwanted disruption, and potentially cost, is a foundation stone in the need for a change management process.
“ITIL change management processes just add red tape. My organization doesn’t need that. Especially not for non-emergency changes!”
Did you just find yourself thinking that statement? There is a common idea that change management will slow down the change processes – but that is not necessarily the case.
Whether we like it or not, modern business is all about change and the ability to quickly respond to change drivers (including preempting impending changes). Some of the many drivers of change may include:
The main purpose behind ITIL change management is to deploy changes, whether due to internal factors or external, without any business disruption or downtime.
Without formal change management capabilities, the handling of all this change would be like the Wild West, because any part of the IT infrastructure could be changed at any time, potentially adversely affecting business operations. Impact could range from simply preventing a business function team from working (because a specific system no longer functions), to preventing the whole organization from working, especially if the corporate network or internet connectivity is affected. It’s why change management is one of the most adopted ITIL processes.
For those reasons, all organizations need some semblance of a formal change management process that consistently delivers first-time change success, and, hopefully, one that effectively balances speed, risks, costs, and business value.
One of the first things to recognize about change management is that there are different types of change that will require different mechanisms to deliver them. This is because some changes are large and some are small both in terms of their complexity and/or business impact. Some are riskier than others, and some need to be done immediately.
The ITIL v3/2011 change management guidance handles this by having a number of change types, or models, that are treated according to how an organization perceives them in terms of risk and business impact in particular, and this is likely to be based on previous experiences.
These models include:
Although changes can be implemented without a formal change management process, there may be more steps to consider. The ITIL change and release management processes provide a step-by-step framework to ensure that business continues running smoothly.
Release and Deployment Management, often referred to as simply “Release Management” or “Change and Release Management”, is an integral part of the ITIL process lifecycle. Every changing aspect of your enterprise, from infrastructure to operations, from software development to supply chain revisions, needs management from top to bottom, which is where Release Management comes in.
Like change management, the goal of release management is to minimize disruptions.
According to Wikipedia:
“Release and Deployment Management aims to plan, schedule and control the movement of releases to test and live environments. The primary goal of this ITIL process is to ensure that the integrity of the live environment is protected and that the correct components are released.”
So, what is the difference between Change Management and Release and Deployment Management? Change Management is about the way people work with changing processes and tools, while Release and Deployment Management covers specific processes behind delivering features and services to production.
When considering a change, it is important to consider a few major factors before proceeding. The “7 R’s of Change Management” will help minimize change request rejection and should be posed any time a change is needed. Before moving forward with a change request, answer these “7 R’s”:
It is important to understand who raised the change, as this question may be important to stakeholders and other managers. Answering this question will also help establish who the point of contact for more information should be.
Answering this question is important because it can be an indicator of changes that are high risk with low reward. In asking this question, you should also understand the impact of NOT implementing the change. This can be a high-level overview and should not be skipped.
The expected ROI of any change will dictate its priority. For example, a change that reduces call time by 30% or more while increasing employee productivity may have a higher ROI than a smaller project and may therefore be more prioritized.
All changes have some degree of risk. Some can be avoided while some simply cannot, which is why it is important to assess risk on a case-by-case basis. The question of risk also includes the risk of potential issues if you choose NOT to move forward with the change. For example: Will failing to implement a change result in loss of productivity or system downtime? Additionally, when posing this question, you must consider the risk of a roll-back plan in case of change release failure.
When considering resources needed to deliver a change, it is important to factor in not only the infrastructure needed, but the human resources needed to implement the change. Will taking resources from other projects cause additional needs elsewhere? If so, you may need to consider a different approach.
Responsibilities of each portion should be clearly stated before the change is considered. If those responsible are currently undertaking other large projects, the change may need to be delayed or the other projects may need to be re-assigned.
This question may be the most difficult, and is where many IT leaders find it helpful to leverage an IT service management software equipped with change and release management processes. Because of the complex and interconnected nature of IT, one change may ripple out and impact several other changes and processes, therefore mapping out the potential impacts is an important consideration.
There are several moving parts when it comes to change and release management, which is why ITIL has an assigned set of roles and responsibilities.
Most changes will require a Change Advisory Board (CAB). This group is comprised of various people on the team and acts as an advisory committee for major or significant changes. A CAB should be able to consider both the business and technical aspects of any proposed changes and, as such, is usually made up of representatives of the IT service provider, the business, and even third parties such as suppliers.
An important point to note with the ITIL v3/2011 change management process’s CAB is that the “A” is for “advisory” rather than “authorization” (and a CAB’s recommendations can then go to a “change authority” for approval). Another is that RFCs are reviewed by the change manager prior to presentation to the CAB.
A CAB’s membership will often be composed of different stakeholders based on the changes under review. There might also be different CABs convened within an organization to reflect the change needs of different business units. And a variant of the CAB is the Emergency Change Advisory Board (ECAB) which, as the name suggests, is used for the review of emergency changes (if time allows).
Further, an Emergency Change Advisory Board (CAB/EC) may be needed to operate within the CAB and is activated for emergency changes that require rapid authorization.
Additional roles include:
Altogether, these roles work together to ensure that each change is fully planned and executed with minimal disruption. These roles are typically filled within the IT team, but the process can be used in any business unit.
The change management process can only function properly if it is accepted and adopted by the people who will be working with and through the change. Like nearly all ITIL processes, successful implementation requires a people-centered initiative.
You can encourage a people-centered process with these 3 steps:
Overly complicated change request processing can become daunting for everyone involved. Change and release management software can help users request changes and can expedite the process. By simplifying the process, more people will understand the vision of the process without feeling bogged down by red-tape processes.
Not all proposed changes will need an RFC to be raised. For example, the ITIL request fulfillment process can be used to manage standard changes, i.e. a service request is raised rather than an RFC for pre-approved, low-risk changes.
When changes impact infrastructure, it is tempting to postpone or ignore them completely. However, some of these changes shouldn’t be ignored, which means it is vital to keep your infrastructure up and running as much as possible. This might mean making changes at off-peak times or doing a phased roll-out. No matter the solution, infrastructure should always be a top priority.
General risk and compliance can only be managed well when you know which line-of-business processes might be affected by any given change, IT or not. With automatic notifications, customizable dashboards, change management schedulers, and more, you can keep your eye on the business as a whole and minimize risk due to change, especially before and during any major deployments. This can be accomplished with a configuration management database (CMDB) equipped with the ITIL framework.
A few of the best practices for adopting and implementing change and release management have already been listed above, but it is important to reiterate how important these best practices are. Three best practices include:
Because there are several best practices in ITIL for change and release management, it can be helpful to use change and release management software for additional guidance.
An ITIL Change Management Software may be housed within your IT service management software and features should include:
Because requests for change may be mistakenly submitted as tickets to the service desk, setting up a knowledge management database to inform users of protocol can also be a positive feature to consider. Additionally, change management software should be scalable and able to grow with your business.
With ITIL Change Management, messy or complicated change and release rollouts can be avoided. A uniform process will not only streamline procedures for future changes but will empower the IT team to take on more change projects without the overwhelming issue of knowing where to start.
To learn more about how EasyVista can help with your Change Management processes, request a demo with one of our experts today!
Krista Lyons is the Content Marketing Manager at EasyVista and is dedicated to sharing helpful information and industry insights through EasyVista's website, social media, and communications. A graduate of the University of Tampa, Lyons has a background in journalism and communications. She enjoys all things tech and has a passion for reading and writing about artificial intelligence.