What’s Changed with Change in ITIL 4?

A new version of the ITIL IT service management (ITSM) best practice framework – ITIL 4 – was released early in 2019. It was big news because ITIL is used by millions of people across the globe for everything from the incident management basics to the management of complex enterprise IT organizations.

One of the most adopted, and frequently referred to, areas of ITIL best practice is change management. This blog takes a look at what changed with change management in ITIL 4 – calling out the main differences – starting with its name!

Difference #1: change management has a new name

ITIL 4 now calls what was the change management process, the change enablement practice (it’s one of ITIL 4’s 34 management practices). At first though (in the ITIL 4 Foundation Edition), it was called change control. But now how should I put this? There was quite a lot of social debate on this name change – with people not liking the term “change control” and the word “control” in particular. I totally understand the concerns and issues – “control” is a word that has negative connotations and is generally avoided in the modern business lexicon, with people now empowered to do what’s right. The What’s with ‘Change Control’ in ITIL4? blog from Greg Sanker nicely articulated the reasons for “change control” over “change management.” However, the name has since changed again – this time to change enablement.

According to the new version of ITIL (ITIL 4 Foundation Edition), the purpose of change enablement is:

“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.”

This might feel familiar, there are two important points to note with the change management name change. The first is the generic move from processes in ITIL v3 to management practices in ITIL 4 – this is covered in Difference #2.

Then the difference between names – change management to change enablement – really highlights the scope of change in ITIL 4. Whereas ITIL v3 focused on the service lifecycle, wrapping change into service transition, ITIL 4 is focused on IT change and highlights that organizational change management is a completely separate entity to change enablement.

Difference #2: Change enablement’s “location” and process versus practice

The ITIL v3 best practice framework positioned change management in the service transition stage of the service lifecycle. ITIL 4 now has the change enablement practice within the service management practices section of the ITIL Service Value System (more on this later). (The service lifecycle is no more but it can be created in ITIL 4 using the ITIL Service Value Chain – see Difference #4).

A key difference between ITIL v3 and ITIL 4 is the move from processes to practices. This is exciting because practices are so much more than processes and workflows. Practices include ideas from each of ITIL’s four dimensions of service management. If you’re not completely up to speed with this yet (and don’t worry I still keep having to check too) the dimensions are essentially an extension of the 4 Ps we first met in ITIL v3. The four dimensions are:

•     Organizations and people
•     Information and technology
•     Partners and suppliers
•     Value streams and processes

Change enablement in ITIL 4 is therefore about roles, skills, people, partners, and resources as well as the process.

Difference #3: The change authority

The change authority is the new term used to cover change approval. One of the biggest issues people had with ITIL v3 was the (incorrect) assumption that every change had to go to the change advisory board (CAB). It’s so not true!

What about standard changes or middle of the night break/fix emergencies? Introducing the concept of a change authority means that people have more flexibility on approval, for example:

•     Delegated authority
•     Standard changes
•     Peer reviews
•     Business exceptions

Difference #4: A focus on continuous integration

Change needs to flow in order to align it to the business and to deliver value. The ITIL 4 version of change enablement calls out the fact that while a normal change can be triggered manually by raising a change request, automation also plays a part.

Used effectively, technology can be used to create an automated pipeline that supports continuous integration and delivery – enabling most steps of the change enablement practice to be automated.

Difference #5: The alignment to Service Value Chain activities

As already mentioned, a big difference between ITIL v3 and ITIL 4 is the move from the service lifecycle to the ITIL Service Value System. The Service Value System is a key part of ITIL 4 and facilitates value co-creation. It shows how all the components and activities of an organization work together for the creation of value. At the center of the Service Value System sits the Service Value Chain (shown below).

Source: AXELOS, ITIL Foundation ITIL 4 Edition (2019)

The change enablement practice can be employed throughout various elements of the Service Value Chain, for example

• Plan – change is involved in everything from planning new IT services to policy update
• Improve – continual improvement is all about change and will need the change control practice to facilitate and manage the change activity required to drive improvement activity
• Engage – making customers aware of change activity
• Design & transition – transitioning new or improved services into the live environment
• Obtain/build – ensuring that the scope of change control extends to components of services as well as the services they underpin
• Deliver & support – supporting the tasks that drive the business-as-usual (BAU) work

So, there’s a lot of change (with change) in ITIL 4 but value is still king

Even with a new name and location, change is still all about delivering value. The heat map below highlights the level of contribution of change to the Service Value Chain and then value creation.

Source: AXELOS, ITIL Foundation (ITIL 4 Edition), 2019

From the diagram it’s clear to see that the main areas of change focus are design and transition, obtain/build, deliver and support, and, of course, improve.

One of the key tenets of DevOps is the avoidance of dead cat syndrome. The name aside (cat lover here), delivering a product or service that’s not fit for purpose is a losing situation all around. End users are frustrated that the product doesn’t work as expected. IT operations staff are overloaded with calls from said users. Development staff are then trying to juggle finding a fix while already dealing with the next new thing. So, a more holistic approach is definitely needed.

Having change enablement as a practice that not only delivers change but supports day-to-day support as well as continual improvement? Now that’s a win.

So, that’s my take on the new ITIL 4 change enablement practice. What would you add to this? Please let me know in the comments.