ITIL 4’s Move from Change Management to Change Enablement

ITIL 4’s Move from Change Management to Change Enablement

If you’ve still to move your personal IT service management (ITSM) knowledge and organisation’s IT service management (ITSM) capabilities on from ITIL v3/2011 to ITIL 4, you might not have seen that the new ITIL 4 change guidance is now significantly different. To help, this blog looks at what changed with "Change" in ITIL 4 to provide you with a better appreciation of how the IT industry’s approach to change management is evolving.

“Change enablement” is the new “change management”

The most obvious change in ITIL 4 is in the name. First, change management changed to “change control” in the 2019 ITIL 4 Foundation publication. However, this new name didn’t sit well with the ITSM community, and by the time the full change-focused practice guide was published in 2020, it had been renamed “change enablement”. This renaming took the emphasis away from the restrictive nature of the word “control” in favour of the need for change-facilitation in its role as a business enabler.

ITIL 4 defines the purpose of the new change enablement practice as:

To maximise the number of successful service and product changes by ensuring that risks have been properly assessed, authorising changes to proceed, and managing the change schedule.

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

The name change also helps to avoid the traditional confusion of people-related change management (that Google returns in searches for “change management”) – which ITIL 4 now covers as “organisational change management” – with IT-related change. Although the latter usually needs the former to be successful.

ITIL 4 finally recognised the influence of DevOps

ITIL v3/2011 didn’t sufficiently reference DevOps practices and benefits. In some ways, this can be excused by the publication dates of these two bodies of ITSM guidance – ITIL v3 in 2007 and the 2011 refresh in 2011. This omission changed with ITIL 4.

Now ITIL blends key DevOps concepts and principles into its change guidance, including the increased use of automation which is covered in more detail later.

Three specific elements of the DevOps approach are called out in ITIL 4:

1. Continuous integration and delivery as a more effective and efficient change delivery model than traditional ITSM change practices
2. Safe to fail testing to support the DevOps principle of “failing fast”. Encouraging experimentation and providing an environment where failure is accepted.
3. Feedback loops through which quality issues can be identified and fixed early (to avoid more expensive defects and rework later on).

ITIL 4 reflects complexity as a critical factor for change

The ITIL 4 Change Enablement Practice Guide shows the different levels of complexity involved with IT and business changes. This is a spectrum or range of change complexity, with the ITIL 4 guidance suggesting the appropriate response for the varying levels of complexity.

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

The above ITIL 4 diagram shows that change activity ranges from business-as-usual tasks, which should still be handled via “standard change” practices, through to business continuity changes that might need to be actioned via the corporate emergency change process.

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

The change roles are different in ITIL 4

A key change in ITIL 4 is that the change advisory board (CAB) model of previous ITIL versions is replaced by the “change authority” role and the concept of “delegated authority”. As a result, ITIL 4 now recognises the need for swifter change through peer reviewers and automation.

This is similar to Agile approaches, where a team can act as the “change manager” and the “CAB” thanks to “collective responsibility”. The service management standard ISO/IEC 20000 Part 1 also takes a similar approach, describing what needs to be done without mentioning specific change management roles.

Thanks to the success of DevOps, change enablement embraces automation

Automation is nothing new to the ITSM world. In the context of change enablement, and based on DevOps successes, it increases flow and change velocity. The Change Enablement ITIL 4 Practice Guide calls out the use of automation and other technology-enablement in areas such as:

• Planning, assessing, and authorising changes using ticketing and workflow tools
• Visualising work, limiting work-in-progress (WIP), and maximising efficiency using Kanban boards
• Reducing WIP and increasing flow using backlog management systems
• Automating change scheduling using service and configuration item data and information
• Improving change communications through the use of models
• Supporting change review discussions with collaboration systems.

Finally, ITIL 4’s change enablement practice has a “customer” focus

In the Change Enablement Practice Guide, one of the practice success factors (PSFs) relates to ensuring stakeholder satisfaction. This PSF is designed to elevate change capabilities from operational success, i.e. delivering a change well, to the resultant outcome(s) and the associated stakeholder experiences.

There are, of course, other changes presented in ITIL 4; if you would like to understand more about change enablement why not attend our next ITIL4 Foundation course.