Skip to main content
Understanding the ITIL 4 Change Management Process (And How Automation Can Enhance IT)
Last Updated Jul 28, 2020 — AI-Powered Analytics expert

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

AI-Powered Analytics

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.

Traditional ITIL Change Management Processes Can Be Cumbersome

The original versions of ITIL 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.

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, fairly cumbersome.

The need for constant CAB review delayed changes and could introduce significant inefficiencies. As a result, the value produced by each individual change was 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 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 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 office moves.

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 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-modelled changes can be split up so that only the novel proposal is being formally considered, while standard components are considered pre-authorized.

When possible, RFCs can be generated in direct response to an indicated need for a change based on IT operations-derived data feedback. This reduces the need for emergency changes by proactively identifying risk and then addressing that risk, using as high of a ratio of pre-modelled standard changes as possible.

Change Evaluation

Per ITIL 4, CAB meetings should be based to address special circumstances rather than on a pre-set cadence as standard procedure. A change manager can often be enough to evaluate the given risk or impact of a change when their judgement 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 role of change authorizations to the extent possible. Modeling changes allows authorization to be instantaneous, 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, modelling 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. Once more, "normal" low risk changes should be the rule, 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 changes.

Review Changes, and Close the Change Record

The importance of comprehensive change closures for reducing unanticipated problems and disruptions should not be overlooked, but 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 process steps most ripe for automation, even in smaller organizations. Automated testing and review performs a "quality assurance" role, while automated CMDB updates and other change closure tasks reduce the need for manual change closure. This ensures more-complete records and reduces the risk that organizational mistakes can affect the accuracy of CMDB data and other major systems of record.

Accelerate Change Deployment with IT Analytics at Every Step of the Process, And Make Each Step More Invisible

Humans are creative, and we can be excellent problem-solvers, but we are not as qualified as computers to rapidly review thousands of line 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, automation's use is considered a best practice in a world where velocity may be measured in milliseconds, not months.

See how AI and analytics can empower organizations to accelerate change while minimizing risk in our recent webinar: "Mastering DevOps with AI-powered Change Risk Prediction"

Watch the Webinar

More from the Blog

View more
Sep 09, 2021

Analytic lenses: essential views for your Value Stream Management (VSM) organization

AI-Powered Analytics's Value Stream Management platform is built from three main ...
Read More
Aug 26, 2021

Risk management in the age of digital transformation means resilience, not avoidance

AI-Powered Analytics
Risk has become an inevitable aspect of the modern business landscape. ...
Read More
May 27, 2021

Leverage analytics to improve change management

AI-Powered Analytics
One of the main objectives of agile product management is to speed up ...
Read More
Agile, DevOps and the Future of Change Management
Nov 05, 2020

Agile, DevOps and the Future of Change Management

AI-Powered Analytics
Today, change is an expected and significant part of the business wo ...
Read More
Contact Us