What does ITIL 4 teach us about change management?

When ITIL 4 was released in 2019, several of the major changes received a great deal of attention from the ITSM industry. The most notable changes include the entire shift in terminology from “processes” to “practices” as well as the newly introduced concept of the ITIL service value system.

Crucial changes were also unveiled in ITIL 4’s approach to change management, including a new name:  “change enablement.” In ITIL 4, change enablement is part of the service management practices section.

At first, there were some discrepancies associated with the initial new name. An early first edition of ITIL Foundation: ITIL 4, had originally renamed “change management” to “change control,” a problematic term for many in DevOps. It was only after a dust-up that the terminology was revised to “change enablement” for the newest revised edition.

Observers note that the semantic implications of change enablement are not minor. By definition, the term “enablement” indicates a goal of facilitating changes in the most efficient and frictionless way possible. In essence, this captures the approach ITIL 4 recommends for managing changes.

Yet despite the change in language, a certain degree of control remains in the change enablement approach. ITIL 4 section 5.2.4 recommends oversight from the appropriate subject matter expert and administrative authority for each given change. While this is approach isn’t centralized, it is far from being uncontrolled.

With this shift in mind, the following are some of the largest changes made to ITIL 4’s change management recommendations that can have an impact on organizational thinking.

Change control should be guided by principles

Several key concepts are baked into the relatively short, but idea-rich, section for change management in ITIL 4. For instance, the section urges IT leaders to emphasize all aspects of the value stream while encouraging simultaneous agility and responsibility. This approach can help organizations be nimble without becoming brittle. Further, supplementing actions with automated approvals and/or deployment along with decision-making with analytics can reduce the risk that any given change will produce unexpected negative results.

The unrevised version of ITIL 4 begins with a major statement regarding the value and effects of changes, as follows: “Change control must balance the need to make beneficial changes that will deliver additional value with the need to protect customers and users from the adverse effect of changes.”

This approach to change management makes it necessary to maintain a balancing act between speed and risk in order to be successful. Organizations must take appropriate measures to calculate risk objectively and promptly so that decisions regarding the assessment and management of risk can be made relatively quickly. We will address how analytics can benefit these priorities below.

In addition, ITIL 4 places an emphasis on creating value through changes. In fact, all impacts of a change should be assessed from a value creation perspective. Organizations should set priorities according to established business outcome criteria. Certain changes may be delayed until sufficient value creation can be proven. This acts as a safeguard that prevents non-value-related criteria from guiding change priorities — for example, if a change was proposed by a specific senior authority.

Changes should be overseen by an appropriate authority

Some of the language in ITIL 4 that pertains to assessments and authorizations of change seems to go against the grain of agile principles. For example, the publication notes, “All changes should be assessed by people who are able to understand the risks and the expected benefits; the changes must then be authorized before they are deployed. This assessment, however, should not introduce unnecessary delay.”

At second glance, though, this language does not prescribe cumbersome approval processes. It indicates that change decisions should be guided by those best equipped to understand the impact of the change, including value creation versus risk.

The person who has ultimate ownership of certain change areas is known as a “change authority.” According to ITIL 4, “It is essential that the correct change authority is assigned to each type of change to ensure that change control is both efficient and effective.”

The change authority is not necessarily a central authority. The individual can also be a team leader or even a group. It’s noted that in high-velocity organizations, change approval is commonly decentralized, “making the peer review a top predictor of high performance,” according to ITIL 4. Change models must be involved in order to retain agility while still putting every change through some sort of approval process – automated or not.

Model changes to make them more agile and fluid

ITIL 4 strongly implies that a manual review process should be conducted whenever changes are made. However, change models can be implemented into change best practices in order to make this review procedure more fluid. In many cases, the change model can make the review process effortlessly efficient, or completely automated.

Within ITIL’s change management framework, “normal changes” are non-standard and involve change requests that lack precedence. But once the change is implemented, it can be studied and then used to form the basis of a standard change model. By using a change model, the next time a similar change is introduced, the approval process can be more streamlined.

In addition, the volume of normal changes can be reduced by modifying changes to better fit the model, or by splitting changes into “normal” and “standard” components. Using this approach as a guiding framework can have a positive effect on coding practices, encouraging containerization as well as the use of models to reduce unknown variables.

Use a change schedule to serve as a single source of truth

Another straightforward concept in change enablement is the use of a change schedule, which is used, according to ITIL 4, to “help plan changes, assist in communication, avoid conflicts, and assign resources.”

Certainly, the entire team or organization should be on the same page for change scheduling, reducing the chances of any type of conflict, confusion, or surprise. A change schedule can also allow the organization to implement changes on a priority basis.

Additionally, change schedules serve as an efficient way to invite collaborative input and communication from across the organization, regardless of who the change authority is, ITIL 4 notes. For example, a schedule can facilitate the risk assessment process when SMEs are needed to weigh in on a proposed change.

Visualize a change’s impact across the organizational value chain

A key concept of ITIL 4 is the service value chain model that it uses to indicate the holistic nature of ITSM, generating awareness of factors beyond the daily duties of IT leaders.

ITIL 4 illustrates how changes can be incorporated throughout the value chain, as follows:

• Plan: Change enablement is necessary for any planned changes, from products to policies.
• Improve: Change and improvements will often go hand-in-hand and will require assessments and authorizations that are part of change enablement.
• Engage:  Customers and users will need to be notified or consulted as changes are made.
• Design and transition: Change as part of new services and transitions.
• Obtain/build: Change enablement in-service components.
• Deliver and support: Teams involved in delivery and support need to be part of the change enablement. (Source: ITIL 4)

In addition, using value stream mapping can allow IT leaders and peripheral departments to develop metrics and set goals pertaining to each affected component of value creation.

Using analytics and automation to make agile change management achievable

By incorporating analytics and automation, organizations can succeed at creating agile change management. While the “fast, but careful” approach may seem contradictory, there are several technologies that can be used to enhance agility.

ITIL 4 recommends implementing a combination of the right people and the right technology. For instance, automation can eliminate many of the manual in-between steps typically associated with a conventional review process. ITIL 4 notes that with some low-risk normal changes, “the change authority for these is usually someone who can make rapid decisions, often using automation to speed up the change.”

Analytics can be effective on a number of levels, not only speeding up the decision-making process but also making information more visible, actionable, accessible, and accurate. Modeling change risk and determining sources of it, for instance, can expedite decision-making.

Furthermore, analytics can reduce the timeline that is usually found with a slow and often redundant manual review process by eliminating uncertainty. They can also provide feedback to drive more productive automation goals.

With the proper approach, changes can be swift but safe. Change authorities need to ensure that each change produces value while it simultaneously moves the organization closer to its goals.

ITIL 4 is not dogma, but it does provide a beneficial working model for organizations to improve the way they implement changes.

Many organizations are moving away from ITIL but still preserve some of ITIL 4’s biggest strengths. Find out how AI can enhance DevOps and give organizations flexibility within this framework in our recent webinar with Pink Elephant’s George Spalding: “DevOps & AI: Do we still need ITIL Change Management?“