The ITIL 4 Managing Professional publications and exams are now over a year old, including the revised best practice guidance on what was previously the “change management process” in ITIL v3/2011, which is now called the “change enablement practice” in ITIL 4. Importantly, this is so much more than a name change or “rebranding.” Instead, the ITIL 4 body of change enablement guidance is radically different to reflect the advancement of corporate DevOps adoption and the business need for greater agility.
To help you to understand the key differences, this blog outlines six key change-related updates between ITIL 4 and ITIL v3/2011.
1. The Importance of the Name Change
The change enablement practice was initially called “change control” until industry debate caused a rethink (but that needs a completely different explanation). The reason for the move away from the term “change management” reflects the expansion of ITIL’s scope with the introduction of ITIL 4.
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 – which ITIL 4 now includes via its organizational change management practice guidance (which was first included in 2016’s ITIL Practitioner Guidance) – needed to be considered.
Hence, the change management process is no more, with the change enablement practice its successor. If you like definitions, 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.” (Source: AXELOS, Change Enablement ITIL 4 Practice Guide (2020))
2. Change Enablement’s ITIL “Positioning”
In ITIL v3/2011, the change management process was positioned in the service transition stage of the five-part ITIL service lifecycle. However, the ITIL service lifecycle is no more in ITIL 4 (although it can be recreated using the ITIL 4 service value chain). You can find out more about this and other ITIL concepts in the EasyVista eBook, ITIL 4 in a Nutshell. Instead, the change enablement practice is now positioned within the service management practices section of the ITIL service value system.
If you’re wondering about the difference between an ITIL v3/2011 process and an ITIL 4 practice, then this is to reflect that roles, skills, people, partners, and resources are as important to successful service management as the “mechanics” of the process.
3. New Change-Related Roles, Including the “Change Authority”
ITIL 4 espouses that product-focused organizations should not have change-related job titles and roles. Instead, change enablement should be integrated within the roles of product development teams.
There’s also the concept of the change authority being responsible for change approval, meaning that organizations have more flexibility on approval rather than thinking that every single change needs to go to ITIL v3/2011’s (and previous versions’) change advisory board (CAB). This includes, for example, delegated authority, standard changes (facilitated by automation), peer reviews, and business exceptions. Interestingly, it’s now hard to find mention of the CAB in the ITIL 4 best practice guidance.
4. Change Enablement is Viewed Through a Complexity Lens
In ITIL 4, the change enablement guidance covers how to respond to different levels of change complexity. The diagram below shows the spectrum of this complexity, and the new guidance offers actions appropriate to each level of complexity.
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.
5. The Integration of DevOps Best Practices
Pre ITIL 4, DevOps wasn’t integrated within the best practice guidance (which was likely due to the age of ITIL v3/2011). The latest guidance now blends in key DevOps concepts. For example, safe to fail testing, continuous integration and delivery, and feedback loops.
Another key difference is the increased use of technology for delivering change, especially automation. For example, ticketing and workflow tools for planning, assessing, and approving changes, backlog management systems to increase flow and reduce WIP, automated scheduling using service and configuration item information, and collaboration tools that facilitate virtual change review and improvement discussions.
6. Change Enablement is Viewed Through a Value-Creation Lens
Change management has long been about delivering additional business value. It still is, especially given ITIL 4’s increased focus on value co-creation. The change enablement heat map below – taken from the Change Enablement ITIL 4 Practice Guide – shows where change enablement is used, and creates value, within the ITIL 4 service value chain.
A Change Enablement Practice Value Heat Map
Source: AXELOS, Change Enablement ITIL 4 Practice Guide (2020)
Example change enablement contributions within the ITIL 4 service value chain include:
- 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.
