3 ITIL Change Management and Best Practices

Can you imagine driving to a brand-new destination without a map or GPS, and without really knowing what will await you when you get there? That’s what it’s like to implement a change in the IT organization without using ITIL change management best practices.

In this post, we’ll cover the reasons that the journey is just as important as the destination and how you can use change management to keep you on the right track.

ITIL Change Management and Change Enablement Basics and Benefits

Change management has been refined between ITIL v3/2011 and ITIL 4. For the purposes of this post, we will discuss both.

The formal definition from the ITIL 2011 Glossary describes the change management process 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 v3/2011 change management process flow includes five stages:

1. Request for Change (RFC)
2. Change Assessment and Planning
3. Change Approvals
4. Change Implementation
5. Post Implementation Review

The main purpose behind ITIL change management is to deploy changes, whether due to internal factors or external, without any business disruption or downtime.

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 employees an issue, 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 4

In ITIL 4, the idea of change management shifted to the change enablement practice. The reason for the move away from the term “change management” reflects the expansion of ITIL’s scope with the introduction of ITIL 4. 

The purpose of the change enablement practice is defined as:

“To maximize the number of successful service and product changes by ensuring that risks have been properly assessed, authorizing changes to proceed and managing the change schedule.”¹

While previous versions of ITIL were focused on IT service management (ITSM), ITIL 4 recognizes the applicability of service management and its best practices to other business functions. Therefore, the potential for confusion with the people-focused version of change management needed to be considered.

When is Change Management or Change Enablement Necessary?

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.

In ITIL v3/2011, the change management guidance has 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.

In ITIL 4, these instances remain similar but include more people-focused scenarios, including the change of team members. Although changes can be implemented without a formal change management process, there may be more steps to consider.

ITIL Change Management Best Practices

Whether your ITSM strategy follows ITIL v3/2011 or has fully transitioned to ITIL 4, there are a few best practices to consider that are applicable to both change management and change enablement.  

1. Don’t Treat ITIL as Law

If you’re on a journey, you know that the map isn’t the only way to get where you need to go. There might be a few side roads to travel, or stops to make along the way that your GPS doesn’t immediately present. In the same way, you should consider ITIL the framework but not the hard-and-fast rules to follow. It is okay to stray from the guidelines in areas where it doesn’t add value for your organization.

This all ties into the notion that change enablement is on a complexity spectrum. Not every change will rise to the level of needing a CAB, and the level of complexity will tell you which practices to apply.

The Spectrum of Change Complexity

Source: AXELOS, Change Enablement ITIL 4 Practice Guide (2020)

As shown in the diagram, change exists on a spectrum that ranges from business-as-usual tasks, where standard changes can be applied, through to business-continuity-related needs that likely require emergency-change practices.

2. Consider smaller changes or releases over time through the Agile Methodology

When your IT department has a major change to roll out, it may be worth breaking these changes into smaller, more manageable chunks. This can help keep your team working within the agile methodology.

For example, by releasing smaller changes over time, your team can continually apply feedback from customers and on the processes from stakeholders.

To break this down further, you can break down the steps of the ITIL 4 service value chain into smaller chunks to continually refine, including:

• Design and transition – changes are often the result of new or changed services, with change enablement a key contributor to service transition
• Obtain/build – whether built or provided by third-party suppliers, changes to infrastructure components are subject to change enablement
• Deliver and support – changes will usually impact service delivery and support operations, with it important that these functions are involved in assessing and approving them
• Improve – improvements will often require assessed and approved changes.

3. Encourage Collaboration and Rethink the CAB’s Role

When it comes to implementing changes, there is often the idea that what is being implemented has come from an order on high and is set in stone. But, for effective change you’ll need to encourage collaboration and transparency.

To do that, you can change the way that the Change Advisory Board interacts and in their role in providing feedback throughout the implementation of the change. You can also consider stakeholders to include that aren’t readily named in the CAB guidelines in ITIL.

The important thing is to include those who will add the most value and create avenues for collaboration and to reduce duplication of effort.

Conclusion

Change management and change enablement are just some of the many important modules in the IT Infrastructure Library. To learn more about the updates in ITIL 4, including change enablement, download our eBook, ITIL in a Nutshell.

_{1.”(Source: AXELOS, Change Enablement ITIL 4 Practice Guide (2020)}