Understanding the New Change Enablement Practice in ITIL 4

(the artist formerly known as ITIL “Change Management” and “Change Control”)

The Purpose of the ITIL 4 Change Enablement Practice

In order for organizations to thrive in today’s digital world, the ability to deliver new, exciting products and services to customers⁠—and do so quickly⁠—is essential. With that said, one of the things we have to be sure of while delivering these products and services is that we are very clear (and protect ourselves) when making changes along the way.

The Change Enablement practice in ITIL 4 provides lots of recommendations and ideas on how to make frequent changes and, at the same time, lessen the chance that we’ll take something really important down as a result. It’s like putting breaks on a car; we don’t use our breaks all the time, but they are critical when needed.

Let’s first define what we mean by “change” in the first place. Here is the definition from the new ITIL 4 practice (with my own notes added in brackets):

When we make changes in our, often, highly connected organizations, we have the potential to impact other teams, services, applications, customers, etc. Here’s where the Change Enablement practice can help.

Now let’s get into some of the details of this new ITIL 4 practice.

Three Premises of the Change Enablement Practice

At the end of the day, the way in which we manage change needs to benefit our organization and, ultimately, our customers. We should not introduce crushing bureaucracy or force teams to wait for approvals, thereby slowing the organization down. Further, we only need to focus on those changes that have a direct impact on delivering products and services to customers.

Our customers need to tell us how quickly change should happen; and we don’t have to have a traditional Change Advisory Board (CAB) in place to discuss all of our changes together. Changes can, and should, be reviewed by decentralized teams so work can continue to get done quickly and safely. More on that in the next section.

Here are three premises detailed in the new ITIL 4 practice (emphasis and notes added):

• Changes are planned and realized in the context of value streams (Get familiar with value streams here). Change Enablement is integrated into value streams and ensures that changes are effective, safe, and timely in order to meet stakeholders’ expectations.
• Change Enablement does not aim to unify all the changes planned and carried out in an organization into one big picture – a digital environment where hundreds of changes may be happening simultaneously. This is neither possible nor required.
• Change Enablement should focus on balancing effectiveness, throughput, compliance, and risk control for all changes in the defined scope.

Change Enablement in Action

Here are a few, quick examples from our Senior Advisor, Mark Hillyard, on how Change Enablement transforms and enhances the Change Management process. If we consider the industry shift to high velocity development (and thus, higher velocity change) within IT, the ideas presented by the Change Enablement practice align with how software development teams are working.

Take, for example, a fully functioning DevOps environment that has embraced Continuous Integration/Continuous Deployment (CI/CD). This model eliminates nearly 100% of the human interaction involved in code releases to production environments. In the Change Management process from ITIL v3, this would be practically impossible to accommodate. The CAB would need to be meeting nearly continuously in order to review, authorize, and schedule every change. The very idea is crazy. Instead, by creating a tailored change authority, each autonomous development team could establish its own method of authorization. If deployment is truly continuous (many times per day), then a daily stand-up describing upcoming releases could serve as the baseline for authorization and scheduling. A team lead would act as the change authority, and the user stories (along with their acceptance criteria) included in each release would serve as the documentation, satisfying operational teams’ needs for transparency and knowledge sharing.

A less extreme example of this improved practice might include an Agile development team that has a stable frequency of change (releases every two weeks). This may seem like a system that could easily fit into the CAB model, but as the goal of Change Enablement is to ensure higher volumes of successful change, bogging a development team down in the plodding nature of CAB meetings would likely extend the project overall, and actually slow the development velocity (if not the frequency of change). This does not serve our customer very well, forcing them to wait on approvals rather than delivering on their timeline. Additionally, the people most suited to provide meaningful risk assessment are likely the developers themselves. Thus, it would make sense to create a change authority within the development team that can quickly analyze and schedule each change. Here, a sprint review prior to deployment would provide an excellent backdrop for assessment and authorization.

As you can see, Change Enablement has the potential to create significant efficiency within your organization.

How Change Enablement in ITIL 4 is different from Change Management in ITIL v3

For those of you familiar with ITIL v3’s Change Management process, here is a quick overview of some of the major changes to this practice.

What’s emphasized – a complexity and predictability-based approach to changes

The ITIL 4 Change Enablement practice introduces the idea of responding differently to varying levels of complexity, from the routine stuff (handled via the Standard change category) to the catastrophic stuff (handled via Emergency procedures). The diagram below shows the range of complexity and responses to change.

What’s de-emphasized in the Change Enablement practice – the Change Advisory Board (CAB)

The idea of a CAB is de-emphasized in the Change Enablement practice. In fact, what it does state about the CAB is the following:

Not so flattering. The idea of the CAB has been, for the most part, replaced by the idea of having some sort of “Change Authority.” This may seem like a small change, but it’s actually a pretty big shift. Organizations are moving away from the idea of forcing their people fill out 2,485 pieces of information, wait for a weekly CAB meeting, and then have to defend their change to be able to make it (no wonder everyone hated submitting changes). The CAB concept is being replaced by peer reviews, automated testing and authorization, and daily stand-ups to approve team-level changes. Those that authorize changes are now called change authorities.

This definition leaves the door open as to how changes are authorized and by whom. Further, the practice recommends breaking changes into smaller pieces to lesson risk in the first place. As a result, changes can happen at the pace our customers need them, not the other way around (where customers are waiting for the CAB to approve changes).

The practice goes on to say:

Other nice additions to the Change Enablement practice

Here are some additional ideas mentioned in the new ITIL 4 practice that I really like and have found to be helpful when approaching how we manage changes:

• Conduct safe-to-fail experiments, automation, and peer reviews whenever possible
• Make changes smaller, thereby decreasing the risk you introduce into your environment
• Write change requests in User Story format
• Use “Backlog management tools” to capture, prioritize, and manage both changes as well as improvements to the practice itself (see the section below for more details on this)
• Use Kanban boards to capture and plan for changes, which makes the work visible.

I also like that the practice includes simple workflow examples for handling different types of changes (when handling automated software changes, etc.) along with ideas on defining Practice Success Factors, or PSFs.

The addition of a Change Optimization focus

Last, I love that there’s a section entitled “Change Optimization” that discusses how there should be a focus “on the continual improvement of the Change Enablement practice, change models, and standard change procedures,” which is what we’ve been advising our customers to do all along. I highly recommend taking a look at your change practice often, tinkering with it and seeing how your experiments pan out, and always looking for ways to make it better.

On that note, the way you manage and enable changes should be driven by what works best for your teams, the types of changes you’re making (risk or complexity behind them, etc.) and, ultimately, what works best for your customers and overall organization. It should not be based on what one of the ITIL books say or what was done at a different organization. In fact, near the end of the ITIL practice document is the disclaimer, “…practice guides are catalogues of things that organizations might think about – not a list of answers.” Instead of telling ourselves, “This is what the ITIL book says, so let’s do things exactly as documented in this here workflow,” It’s up to each of us to ask ourselves: “How should our organization work? “Does this make sense for us? Is there a better way?”

Side Note: Explaining the name change from Change Management (to Control) to Enablement

ITIL v3 to ITIL 4 name change

If you’ve taken any sort of ITIL training in prior years, this practice may have been called something different. If you took your ITIL training before February of 2019, the process was called Change Management. This is the verbiage that most people still use. However, there was confusion around the difference between IT-related Change Management and Organizational Change Management. And when ITIL 4 was released in February of 2019, the name changed from the Change Management process to the Change Control practice (more on the “process” to “practice” terminology change here).

ITIL 4 name change

If you took an ITIL 4 Foundation class sometime between February and August 2019, you will have learned the term Change Control. Unfortunately, when ITIL 4 terminology was tested across a global audience, the phrase “Change Control” brought new confusion with it. The name didn’t resonate with many organizations, especially those that are embracing faster ways of working, like Agile and DevOps, and it was assumed that Change Control had the potential to slow organizations down. Thus, the name was changed to Change Enablement to more accurately reflect the true intent of the practice. Having an efficient and effective Change Enablement practice actually helps organizations speed up how work gets done and still protects us from downtime and resulting issues when changes go sideways.

Yes, the irony isn’t lost on me that the name for the practice that discusses change keeps changing 🙂 But change is inevitable.