How Has ITIL 4 Evolved Change Management? And How Can AI-powered Analytics Propel Its Objectives?

ITIL Change Management best practices have been heavily revised in the ITIL 4 rerelease. Rather than offer a set of prescriptive processes, ITIL 4 now illustrates the roles and responsibilities needed to make change management agile while reducing the risk of service disruptions to the largest extent possible.

Following ITIL 4 change management — now called “change enablement” — guidelines can allow organizations to structure their teams and workflows in a way that avoids rigid approvals yet still ensures operations teams only promote stable changes that contribute to value co-creation.

Understanding ITIL’s guidelines can help IT leaders structure their change management process in an efficient manner without standing in the way of continuous integration (CI) and continuous value creation. Combining ITIL practices with analytics can accelerate value creation by giving IT change teams rapid access to insights that can help them manage change risks.

What Is ITIL?

The Information Technology Infrastructure Library — or “ITIL” — is a framework designed to help IT teams develop processes and practices that are reliable, yet still flexible. 

Global best practice firm AXELOS defines ITIL as, “a professionally recognized certification scheme, [that] provides comprehensive, practical and proven guidance for establishing a service management system, providing a common glossary of terms for businesses using IT-enabled services.”

AXELOS also notes that “ITIL supports organizations and individuals to gain optimal value from IT and digital services. It helps define the direction of the service provider with a clear capability model and aligns them to the business strategy and customer needs.”

How ITIL 4 Changes Change Management

The ITIL system was originally developed to provide guiding principles on how to manage and operate information technology (IT) departments. Once personal computers started seeing more widespread business use, organizations were eager to determine a framework and a system of best practices for technology management and support. This structure could encompass all needed responsibilities and ensure that work was performed up to the expected standards.

ITIL’s original hierarchies and rigid, prescriptive processes acted as a stand-in for a lack of corporate structure that organizations had come to expect. However, software development practices evolved rapidly within a span of 15 years. Businesses began to realize that quarterly or bi-annual application enhancements were too slow. To reflect the rapid pace of technological evolution and changing market expectations, developers began to switch from a rigid, approval-based process to the process now known as Agile.

Agile — and later DevOps — reflected the need to constantly be updating and adapting platforms, applications, and other technology services and products. Software cycles changed from yearly or quarterly updates to updates every few weeks. Now, millions of software changes are committed to major platforms like Facebook and Amazon Shopping on a daily basis. In the face of such fast-paced iterations, ITIL practices had to evolve, too.

ITIL 3 tried to address changes needed to maintain an Agile/DevOps philosophy, but it still prescribed rigid change approvals governed by a Change Advisory Board (CAB). ITIL 4 recognizes that not all changes need CAB approval. In fact, an ideal situation for many organizations would be for there to be as few CAB approvals as possible.

To reflect the values of nimbleness and adaptability, ITIL 4 does away with processes in favor of practices. It establishes the values and goals needed for changes to produce the needed value with minimal risk of service disruptions. It defines roles needed to oversee change management, evaluate the risk of proposed changes, and maintain the stability of the production environment even amidst thousands of deployed changes a month.

What Are ITIL 4’s Core Change Management Principles?

ITIL exists to keep two seemingly contradictory elements in place — that IT service remains stable and reliable, and that the service can change rapidly to meet evolving business requirements. 

One key semantic feature of ITIL 4 is that it originally referred to Change Management practices as “Change Control”. Because that sounded too rigid and proscriptive, it was changed to “Change Enablement”. The new name reflects the idea that changes should be examined and promoted within a framework that encourages minimal gatekeeping and disruptions.

With this in mind, ITIL 4 describes three major categories of changes:

1. Standard Changes: Pre-authorized, low-risk Changes that follow a well-known procedure.
2. Emergency Changes: Changes that must be implemented immediately, for example to resolve a Major Incident.
3. Normal Changes: All other Changes that are not Standard Changes or Emergency Changes.

Importantly, the Change Enablement model prioritizes Standard Changes because they are implemented rapidly — even on an automated basis.

Emergency changes are seen as risky since they might fail to evaluate the risk of further disruptions, so they should be avoided to the extent possible using proactive risk management practices.

Non-standard and non-emergency changes can be proposed using a formal Request for Change (RFC) delivered to the change management team. The team can analyze, evaluate, and then approve/reject the proposed change. An Emergency Change Advisory Board (ECAB) can be called upon on short notice to rapidly respond to major incidents and other emergencies. Organizations are encouraged to streamline the change management process, reduce gatekeeping and bureaucracy, and strive to model anticipated changes in such a way that most become Standard Changes, minimizing the need for approvals. The use of data analytics, such of an AI-backed change risk prediction engine, can facilitate these goals without introducing unneeded business disruption risks.

Atlassian observes that “data-informed, adaptive practices strive for efficiency, in contrast with traditional change management, that can often be unnecessarily slow, process-heavy, and overburdened. Because change management deals with challenges around risk and compliance, auditability, and cross-team coordination it too often becomes complex, bureaucratic, and painful.”

Roles Outlined Under ITIL Change Management Best Practices

Minimal use of prescriptive organizational practices is emphasized under ITIL 4, so the change management roles described therein are relatively spartan. They include the following:

Change Manager (Process Owner)

This individual is ultimately accountable for change activities and responsible for the lifecycle of all changes. Their primary objective is to enable the unhindered promotion of beneficial changes while minimizing disruptions and other negative impacts that can be caused by change problems. 

Daily responsibilities might include monitoring proposed changes for risk, auditing change logs, helping schedule changes and build authorization, and reviewing recent changes to ensure proper change closure. Strategically, the change manager can seek to streamline the change proposal and approval process using categories of model changes, making fewer changes require explicit approval.

Change Advisory Board (CAB)

Originally, the CAB was used to oversee, audit, and approve nearly all changes. This is unfeasible at the current rate of change implementation under CI cycles. Accordingly, ITIL 4 suggests that the CAB take a more explicitly advisory role to facilitate the decision-making and analysis capability of the change manager. 

Ideally, the CAB will be made up of delegates from multiple areas within IT as well as business leaders and, occasionally, third-parties like suppliers or key vendor representatives.

Emergency Change Advisory Board (ECAB)

These committees can be standing committees made up of individuals uniquely qualified to address emergency problems and incidents. However, ITIL 4 proposes that ECABs can be ad-hoc and assembled from individuals most qualified to address the exact nature of the current proposed Emergency Change. 

Whatever its makeup, the ECAB should be prepared to rapidly consider Emergency Changes, evaluate their risks, and establish a process for rapid implementation, post-implementation review, and further remedial action as needed.

Using AI-powered Analytics to Maintain Agility Within the ITIL 4 Change Enablement Framework

“Enablement” is all about creating the conditions for a given practice or value to flourish. In this case, change enablement prioritizes the creation of organization-specific roles and processes to reduce common barriers to rapid change approval. At the same time, change enablement seeks to minimize disruptions that can not only impact organizational value co-creation but also the ability to promote changes with minimal approvals comfortably.

Human judgement alone may not be up to the task of ensuring change enablement practices come to fruition. They can be aided by the use of AI-powered analytics capable of revealing insights to enable more informed decision-making. Using analytics, organizations can establish KPIs that drive agility, uncover and monitor change risk factors to guide decisions, and iterate on their change models to more accurately flag changes that require review — all while increasing the volume of Standard Changes that can be promoted through automation or rapid IT operator implementation.

Data fuels this value creation chain, and AI can accelerate its productivity — all while enhancing your IT workers’ current capabilities. With this in mind, organizations seeking to implement ITIL Change Management best practices to improve agility while managing risks should strongly consider how IT business analytics can enable the goals they seek.

Learn more about how AI-backed analytics can propel DevOps goals while empowering your ITIL-driven change enablement objectives in our recent webinar: “Mastering DevOps with AI-powered Change Risk Prediction“

Watch the Webinar