Understanding the ITIL 4 Change Management Process (And How Automation Can Enhance IT)

What is change management?

ITIL 4 Change Management refers to a set of guidelines established by the ITIL foundation These guidelines help organizations manage digital product changes with minimal friction or risks.

ITIL 4 is the fourth revision of these guidelines, with the first version published back in 1989! Unlike ITIL 3, which established a set of specifically defined processes for organizations to follow, ITIL 4 aims to provide flexible guidance. Importantly, organizations can adopt the specific processes described by ITIL 3 while still remaining fully compatible with ITIL 4’s guidelines.

ITIL 4 change management recommendations primarily provide specific definitions for key concepts and roles that take place in IT operations. The described concepts are generalized so that can apply universally, regardless of the actual structure of the company. The intent is for organizations to develop their own processes and practices with the change management framework established by ITIL 4 in mind.

Using ITIL 4’s recommendations hand-in-hand with change risk prediction analytics can greatly accelerate release velocity while guiding product teams to start making lower-risk changes overall. Stay ahead of risks with with Digital.ai Intelligence.

Why use ITIL 4 for change management?

Changes are a standard part of daily IT Operations, no matter what category it may fit into. Decades ago, changes were relegated to rare patch events or configuration updates that happened just a few times a year, or less. But now, some of the most popular applications, services, and platforms in the world receive thousands of change updates in a given year. Google famously reported in 2018 that it made over 3,000 changes to its search engine algorithms that year alone, averaging about 9 per day.

With so much change happening at such a rapid pace, IT organizations need a structured way to integrate and deploy changes in order to minimize the risks of service disruptions. At the same time, IT operations leaders need to remove any obstacles that stand in the way of change velocity. Any unnecessary delays or gatekeeping impedes the value production chain.

This presents a paradox: we must implement changes in a safe way at a faster speed than ever before.

The recently updated ITIL change management process seeks to address this conundrum. ITIL 4 change management’s main objective is to remove all barriers to change deployment while retaining efficient control over operational metrics and other change risk management goals. In this spirit, ITIL 4 proposes a change enablement framework rather than rigidly defining a prescriptive set of change management processes.

By adopting ITIL 4’s ideals and customizing them to best-fit the organizational environment at hand, IT operations teams can accelerate the speed of change while minimizing inefficiencies — and disruptive threats — along the way.

ITIL 4 aims to make change management less cumbersome

The original versions of ITIL — with the first being published in the late 1980s — rigidly mapped processes that could bring predictability and structure to an organization’s IT-related activities. This guidance was vital for enterprises where IT requirements were either unfamiliar or led to unpredictability. It was a product of a world unfamiliar with emergent technology, and businesses as well as governmental organizations were hungry for this level of specific guidance.

However, a major shift in software development methodologies arose in the early 2000s: Agile. With Agile, rigid “waterfall” development processes were done away with. This gave individual development teams more autonomy and control over their end results, which could be achieved in a significantly shorter time period.

Agile made popular the idea that applications and technology platforms could evolve continuously — as long as work was put in to make sure each new change added value to end users.

In response to the rise of the Agile methodology (and DevOps after it), ITIL was forced to adapt. ITIL v3 built upon existing ITIL change processes and developed a model for continual change implementation that many organizations followed with the following steps:

1. Create a request for change (RFC)
2. Review RFC
3. Have a Change Advisory Board (CAB) assess and evaluate the RFC
4. Authorize changes based upon the RFC
5. Plan updates
6. Coordinate implementation
7. Deploy/integrate new changes
8. Review changes, and close the change record

This version of the ITIL change management process was reliable, repeatable, and exerted a great degree of control over the outcome of change proposals. It was also, for some organizations, still fairly cumbersome.

The need for constant CAB review delays changes and could introduce significant inefficiencies. As a result, the value produced by each individual change is encumbered.

In response to these shortcomings, the new ITIL 4 framework suggested that the rigid change “proposal > approval > implementation > close” model be reserved for certain changes that were considered non-standard. So, while the ITIL 4 framework preserves room for a “normal” change management process that is familiar from past versions, it encourages IT operations leaders to migrate as many changes as possible to a different category: standard changes.

Accelerating change velocity using ITIL’s standard change models

ITIL v3 had a category of proposed changes described as “standard changes.” These were considered low-risk, and they would occur frequently in the given IT environment. Examples offered included password changes, new hire procedures, and the relocation of physical equipment.

With ITIL 4, ITSM leaders recognize that organizations could strive for standard changes to be the norm, not a special exception to “normal changes.” It proposes that, by modeling categories of changes or specific change types, formalized gatekeeping and CAB approval are no longer needed in many contexts.

Figuring out which changes are actually “normal” (i.e., “low risk) can, therefore, remove most of the bottlenecks that stand in the way of agility. When higher risk changes are introduced into the formal RFC process, IT operations leaders can also begin working to accept, mitigate, or reject the risk.

The process of implementing a normal change can now be largely automated, meaning that as soon as the change is proposed by development (often in response to IT operations’ data feedback), it can be tested, integrated, and deployed in the production environment, and then closed with little to no human intervention.

So, while standard changes do mirror the normal change process, the RFC is reviewed and authorized through a low-latency process instead of formalized CAB review.

Adapting the ITIL change management process to accelerate changes while managing risk

Each step of the original ITIL 3 change management process can be preserved, in essence, without sacrificing velocity or flexibility.

Proposals suggested by the updated ITIL 4 framework to adapt an organization’s change management process include:

• Creating change models for recurring changes
• Decentralizing change approval for standard changes
• Breaking bigger changes into smaller pieces that carry less risk
• Using automated checks, testing and deployment

Here’s how adaptations might be reflected in reference to each step of a more formal ITIL change management process:

Request for change

Individual proposed “normal” changes should first be considered relative to a standard change model to see if the change can actually avoid the approval process. Changes that are “low risk” and involve some characteristics of pre-modeled changes can be split up so that only the novel proposal is being formally considered, while standard components are pre-authorized.

When possible, RFCs can be automatically generated in direct response to an indicated need for a change based on IT operations-derived data feedback. Autogenerated RFCs can then be incorporated into the proposed change/feature portfolio. Automated RCFc reduces the need for emergency changes because they proactively identify risk and then aim to address that risk, preferably by hewing as closely to pre-modeled standard changes as possible.

Change evaluation
Per ITIL 4, CAB meetings should be called to address special circumstances rather than scheduled on a pre-set cadence or as part of standard change procedure. A single change manager role can often be enough to evaluate the given risk or impact of a change when their judgment is supplemented by AI-powered analytics. Standard changes can be evaluated mostly or wholly through an automated process, preventing a backlog of considerations while greatly reducing latency. Normal changes requiring formal approval can become the basis of a new standard change model, or they can help update existing standard change models to fit a broader scope.

Change authorization
A primary goal of ITIL 4’s agility-focused change enablement framework is to reduce the presence of change authorizations to the extent possible. Modeling changes allows authorization to be instantaneous, in most instances, and utilizing analytics to evaluate change risks can make human-guided normal change authorization less cumbersome and less research-intensive.

Plan changes
Change scheduling and build authorization can be dramatically streamlined through the use of change analytics, up to the point of nearly complete automation. Manual scheduling and change build planning should be reduced to the extent possible. Again, modeling changes can eliminate the role of uncertainty by isolating changes that require special attention from those that can be rapidly planned and built into a future release deployment.

Deploy/Integrate new changes
Thanks to Release Management tools, change deployment and integration have been largely automated for many enterprises. “Normal” low-risk changes should be prioritized, meaning that most changes shouldn’t require manual deployment or integration. Those that require attention can be monitored post-deployment, reducing the need for direct human supervision for a small subset of risky changes.

Review changes, and close the change record
The importance of comprehensive change closures should not be overlooked. They have been shown to effectively reduce unanticipated problems and disruptions. However, this maxim does not mean that IT organizations need to introduce cumbersome manual review processes to make sure each change is stable and is accurately reflected in the needed documentation.

Change closures are one of the change management processes steps most ripe for automation, even in smaller organizations. Automated testing and review perform a “quality assurance” role, while automated CMDB updates and other change closure tasks reduce the need for manual change closure. These practices ensure more complete records and reduce the risk that organizational mistakes can affect the integrity of CMDB data and other major systems of record.

Accelerate change deployment with IT Analytics at every step of the process

Humans are creative, and we can be excellent problem-solvers, but we are not as qualified as computers to rapidly review thousands of lines of code or millions of data entries. Analytics provides this functionality, and it can dramatically enhance IT productivity while adding agility to your change review and deployment process.
Adding AI and ML models further enhances IT capabilities by automatically uncovering patterns in data the human eye might not be able to see, such as change risk factors or the likelihood a given change is to produce a disruptive effect upon performance.

These functionalities illustrate the vital role technology has in helping us manage the technology we create and modify on a daily basis. While change automation is not inherently necessary to modern change management practices, ITIL guidelines consider it a best practice, one that’s vital in a world where velocity may be measured in milliseconds, not months.