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:
- What is Change Management in the ITIL Process?
- Why is ITIL Change Management Used?
- When is ITIL Change Management Used?
- What is Release Management in the ITIL Process?
- The 7 R’s of Change Management
- Change Management Roles and Responsibilities
- Selling the Vision for an Effective Change Management Process
- Best Practices for Adopting and Implementing Change and Release Management
- Features to Look for in ITIL Change Management Software
What is Change Management in The ITIL Process
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:
- Request for Change (RFC)
- Change Assessment and Planning
- Change Approvals
- Change Implementation
- Post Implementation Review
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.
Why is ITIL Change Management Used
“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:
- Internal Drivers - for instance the delivery of new products and services, new ways of working (for example, remote vs on-site), addressing mergers and acquisitions, or the need to add new features to or correct an issue in a production system.
- External Drivers - such as legal or regulatory changes, or where there’s a compliance-related need to be changed by a certain date.
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.
When is ITIL Change Management Used
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:
- Pre-approved changes (commonly called standard changes) - Low risk and undertaken frequently via well-established procedures. This model type allows changes to be progressed quickly and with a light touch. There might be multiple change model variants to reflect the different levels of risk and complexity of changes to different infrastructure areas. An example of a pre-approved change is the installation of a commercial software application on a PC.
- Emergency changes (commonly called exceptional changes or urgent changes) - Need to be addressed as quickly as possible, often with some of the usual change management process rigor applied retrospectively to speed things up. An example is the changes in response to major incidents, but this could also be an additional change type/model if warranted. Importantly, emergency changes should be kept to a minimum – due to the potential risks – and this change model shouldn’t be used as a “get out of jail free card” for poor planning on the part of change requesters.
- Normal changes (also called non-standard changes) - These are the other changes that do not fall into the categories above. These changes need to be considered on their merits and will usually be presented to a Change Advisory Board (CAB) for review – which will be explained shortly. A separate type of change might also be broken out of normal changes – major changes.
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.
What is Release Management in The ITIL Process
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.
The 7 R’s of Change Management
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”:
1. Who raised the change?
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.
2. What is the reason for the change?
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.
3. What return is required from the change?
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.
4. What are the risks involved in the change?
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.
5. What resources are required to deliver the change?
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.
6. Who is responsible for the “build, test, and implement” portion of the change?
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.
7. What is the relationship between this change and other changes?
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.
Change Management Roles and Responsibilities
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:
- Change Manager (CM) – The Change Manager acts as a facilitator of the process who is responsible for authorizing minor changes, coordinating and conducting meetings with the CAB, and overseeing implementation of changes. Additionally, the CM prepares a summary to help the CAB understand proposed changes.
- Change Requestor or Change Initiator – This is the person who requests the change and provides information to the CM to present the CAB. This person also attends CAB meetings, reviews the change plan and resolves issues relating to the change, and informs the users of the change.
- Change Assignee/Tester/Implementer – This person is the owner of the change and is responsible for working with the Change Requestor. The Change Implementor is also responsible for creating a Request for Change (RFC), assessing and managing risks, testing and implementing changes, coordinating and communicating with impacted teams, documenting the change process, and executing the change at the scheduled date and time.
- Change Approver – This is the manager who provides the first review before taking the RFC to the CAB. They ensure all necessary communication, documentation, and testing are done prior to approval and approve or deny the RFC before it moves to the CAB.
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.
Selling the Vision for an Effective Change Management Process
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:
Simplify Change Request Processing
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.
Keep Your Infrastructure Up and Running
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.
Mitigate Risk with Complete Visibility into Changes
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.
Best Practices for Adopting and Implementing Change and Release Management
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:
- Operating a Change Advisory Board (CAB) for all major changes, including emergency changes.
- Having a formal Request for Change process (RFC). This is defined by ITIL v3 as “a formal proposal for a change to be made. It includes details of the proposed change and may be recorded on paper or electronically.”
- Using different change models for different change types. 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.
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.
Features to Look for in ITIL Change Management Software
An ITIL Change Management Software may be housed within your IT service management software and features should include:
- Full coverage of ITIL processes
- Simplified Change Request processing with a graphical workflow engine
- Full integration with a CMDB
- Automatic notifications and customizable dashboards for greater visibility and outage avoidance
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.
Next Steps
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!
