Changes can happen at any time within your organization, spanning from infrastructure and operations to software development and supply chain revisions. This is why having a standardized change management plan is essential to any enterprise.
For purposes of this blog we will refer to “the change management process” as described in ITIL v3, as opposed to “the change enablement practice” which are the latest best practices updates in ITIL 4.
What is the Change Management Process?
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. If you like more formal definitions, 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.”
This also points out the need for changes to be made in a safe way that doesn’t interfere with business operations—whether internal or customer-facing.
Change management is ultimately a balancing act between the need for speed and the management of the inherent risks associated with a change. After all, no organization wants its latest change to cause its customers and/or employee’s issues; and 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 the Change Management Process Important?
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, catering for 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.
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 itil change management process that consistently delivers first-time change success, and, hopefully, one that effectively balances speed, risks, costs, and business value.
View our webinar on change in onboarding!
Let’s look a little deeper at 3 ITIL v3/2011 best practices that help describe the change management process elements at a high level.
1. Using Different Change Models for Different Change Types
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 (these are commonly called standard changes). Changes that are low risk and undertaken frequently via well-established procedures. This model type allows changes to be progressed at speed and with a light touch. There might be multiple change model variants here too, 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 (these might be called exceptional changes, urgent changes, or something else). Changes that 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 (these are also called non-standard changes). These are the other changes, i.e. those that aren’t standard changes or emergency changes. 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.
2. Having a Request for Change (RFC) Process
The ITIL v3/2011 change management process guidance describes an RFC 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.” The RFC is different from the change record that’s maintained within the corporate ITSM tool and is only used to submit requests. Whereas the change record will record more information on the full lifecycle of the change.
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. Or a major change might require a larger “change proposal” to be created rather than the usual RFC process to be followed. Future related RFCs are then associated with the initial change proposal.
3. Operating a Change Advisory Board
A Change Advisory Board (CAB) is a cross-business body created to assist the change management process with the assessment, authorization, prioritization, and scheduling of 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).
Does your Organization Need a Better Way of Handling Changes?
If your organization is plagued by incidents, and the associated business disruption, caused by change-related issues, then a formal, fit-for-purpose change management process is needed.
Migrating to any change management solution is a huge investment for your organization. This is why it is important to take the time to make an informed decision because whichever tool you go with, is crucial to your company’s success.
See for yourself just how effective EV solutions can be and get a live demo with one of our ITSM experts today!
