What is Change Management?

Managing change is one of the core responsibilities of any effective IT team. In fact, this is central to all kinds of transformation, process improvement, and day-to-day service delivery projects.

The aim of this guide is to provide a full account of change management within the IT Infrastructure Library (ITIL).

Specifically, we’re covering what change management is, what it achieves, and the activities required to successfully implement changes for the benefit of service users.

Along the way, we’ll also cover how we can apply the core principles of IITL to our change management processes in order to deliver value across the organization while minimizing the impact on our IT team.

Let’s start with the basics.

What is change management?

Change management comprises all of our efforts to plan, assess, control, implement, and monitor changes to our service delivery and our wider IT environment. This could apply at the level of processes, workflows, staffing, policies, or technology.

In other words, this means taking a structured approach to handling changes in order to ensure that they meet our organizational goals.

As such, change management comprises the full lifecycle of new initiatives, from identifying demand for change to problem analysis, planning, solutions design, and, ultimately, execution.

At the highest level, the goal is to ensure that we have the controls in place to implement the changes that will deliver value to service users without incurring unnecessary costs, risks, disruption, or other issues.

Why do we need change management?

Changes to our IT services can have an outsized impact on just about any other party of the business.

Therefore, it’s vital to account for the various ways that changes might affect colleagues across the organization, both in terms of the change itself and how we implement it.

To understand this better, we can think more deeply about how exactly IT changes can play out for various stakeholders.

The specific factors we need to control include:

• Demand for change - identifying an actual need to update, expand, or modify our ITSM provision.
• Suitability - the ability of a proposed change to meet the underlying business need.
• Costs - the direct financial impact of the proposed change.
• Workforce - the skills and work required to implement our changes, as well as how this will impact our wider staffing needs.
• Culture - including internal resistance to change.
• Technical requirements - such as hardware, software, integrations, and infrastructure that will be required to implement the change at hand.
• Disruption - minimizing interruptions or other issues within processes during change implementation.
• Integration - how our changes will fit in with other elements of our ITSM efforts.
• Service quality - the quantifiable value our changes will deliver.

Across all of these factors, ITSM change management has three key goals:

1. Determining where a demand for change exists.
2. Controlling which specific changes are authorized and implemented.
3. Ensuring that change delivers maximum value to service users while incurring minimal downside for the IT team.

Structuring a change management process

Change management requires us to control, document, and plan changes across their entire lifecycle. This starts with identifying a demand for change and ends after that change has been successfully implemented.

The specific steps in between will vary depending on our internal rules and the nature of the change at hand.

However, the basic structure of a change management process will typically follow the same pattern.

We can break this down into five stages.

1. Identifying change demand

First, we must identify a demand for change. This is the point when our change management process is initiated. A demand for change means that an IT colleague or service user raises a potential improvement opportunity or solution to a known problem.

Typically, this can stem from one of three sources:

1. A change request from a service user.
2. IT colleagues identifying potential changes based on service quality goals.
3. Changes necessitated by environmental factors, like new regulatory requirements or security threats.

In all cases, our initial priority is recording structured data relating to the demand for change.

Each of the following stages in our change management process will involve applying defined business rules based on this original submission. So, it’s vital that we have the required data in the appropriate format to enable this.

We’ll touch on some of the specific tools and strategies we can leverage to manage change requests elsewhere in this resource.

We might also perform some basic routing at the point of submission. For instance, if we provide different points of submission for distinct types of change requests, thereby initiating separate workflows.

2. Evaluation and planning

Once a potential change has been identified, we move on to the evaluation and planning stage. Our core goal here is to establish the potential value of the proposed change, as well as its associated costs.

In other words, we want to first determine the impact of implementing a change and then establish what will be required to achieve this.

The demand for change might stem from an opportunity to improve efficiency, enhance service outcomes, streamline user experiences, respond to a new risk, or account for a new environmental factor.

Once we’ve verified that this is a worthwhile change, our next task is establishing what’s required to achieve the desired impact.

This requires extensive analysis and planning. The goal is to outline the associated risks, timelines, resources, costs, and deliverables of implementing a change, including weighing up competing options, where necessary.

By the end of this stage, we should have a clearly defined business case for the proposed change, ready to be used as an input in our approval process.

3. Authorization and approval

Authorization and approval is the stage at which we decide whether or not to proceed with a change initiative, based on established business rules.

Depending on the nature and scale of the change, the rigor and complexity of our approval workflows will also vary.

The two elements we need to be most concerned with are:

• The change authority - The colleague or other actor responsible for authorizing a change.
• The approval criteria - The specific factors that determine whether or not a change should be approved, including budgets, other resources, workloads, business priorities, compliance issues, security, and the business case for the change.

An example of a very simple approval process would be a routine code change. Here, the change authority might be a QA colleague or other code reviewer. The approval criteria would simply be that the new commit works according to the specifications.

More complex changes might require multi-stage approval processes. For instance, taking in opinions from technical, operational, legal, and financial teams.

In other cases, major changes with more strategic importance might be the responsibility of the change authority board (CAB). This is a group of colleagues with a shared responsibility for assessing, prioritizing, and authorizing more consequential change initiatives.

4. Implementing change

Once we’ve secured authorization, the next stage of the change management process is implementation. Naturally, this will vary greatly depending on the change at hand.

In a small number of cases, implementation might be essentially self-contained. For instance, pushing a new commit or deploying a new end-user device.

More often, though, implementation will require extensive communication and coordination. This involves using project management strategies to ensure that change is delivered according to specifications and within the agreed budget and timelines.

Additionally, we may need to factor other considerations into our implementation plan, including providing training to colleagues affected by the change and managing logistical issues, such as the transport, storage, and installation of equipment.

Perhaps most importantly of all, successful implementation requires us to manage service continuity, with a specific focus on minimizing disruption to service provision, thereby ensuring a smooth transition.

5. Monitoring and review

Effective change management practices don’t end with implementation. Rather, it’s imperative that we monitor, document, and review outcomes, experiences, and learnings as part of our change management process.

Notably, this is equally applicable in the case of positive and negative outcomes.

The first strand of this is assessing the impact of our change against its original business case. That is, whether it delivered the return on investment we expected based on the real-world value we achieved and the costs we incurred.

Ongoing monitoring is also required to ensure that our initiatives continue to deliver value to service users.

Building on this, we must also thoroughly document any unforeseen issues, roadblocks, successes, or other learnings as part of our knowledge management practice.

Ultimately, the goal of the monitoring and review stage is primarily to assess the effectiveness of our change initiatives and, secondarily, to better inform future decision-making by providing a clear record of what has and hasn’t worked in the past.

Managing change within ITIL

Like all core ITSM processes, ITIL prescribes a particular approach to change management.

However, as of the fourth version of ITIL, change management is no longer one of its constituent processes.

Instead, the activities that previously fell under the umbrella of change management have been subsumed into two new practices:

1. Change control,
2. Organizational change management.

Let’s take a look at each to see how they differ and where they overlap.

Change control

Change control deals with changes to our ITSM products and services. A change here is defined as any update, modification, removal, or addition that could impact our services.

This could be a new software release, policy, infrastructure upgrade, or any alteration to anything that contributes to our service delivery.

As the name suggests, the goal here is to control changes.

Specifically, change control is the process of analyzing, assessing, and authorizing changes, taking account of their relative risks, costs, and potential impacts. Change control also comprises delivery and implementation, including managing our change schedule.

Organizational change management

By contrast, organizational change management deals specifically with the human side of transformation initiatives, including beyond the limits of IT products and services. This ensures that all stakeholders impacted by a change understand, accept, and support it.

Like change control, this can include any elements that contribute to our service delivery. However, it also includes any changes outside of our IT service, such as wider workflow management, digital transformation, or process improvement projects.

The goal is to minimize any resistance to change that might be introduced by human factors.

There are a few key human factors that can present barriers to change. The first is cultural. That is, key stakeholders, acting as blockers due to a lack of buy-in. For instance, if proposed transformations could lead to lay-offs or redistribution.

The other relates to workforce management and resource allocation. The biggest issue here is typically securing the investment we need to implement change.

Therefore, when we talk about change management, we’re using it as an umbrella term, drawing in both change control and organizational change management.

Types of change within ITIL

Changes will naturally differ in terms of their scale, scope, costs, and potential impact. As such, it is important to reflect this fact in our change management efforts.

ITIL distinguishes between four types of change with IT services.

These are:

1. Standard changes - routine or low-risk changes to our ITSM efforts that might require relatively minimal approval processes. For example, regular software updates.
2. Normal changes - more substantial changes that present moderate but still manageable risks and, therefore, require more detailed approval processes. For example, introducing new workflows.
3. Major changes - highly substantive changes that implement multiple aspects of the business in a more fundamental way and, therefore, carry a high degree of risk. These require a large level of planning and complex authorization processes. For example, restructuring teams.
4. Emergency changes - changes that are required to respond to an incident, disaster, or other event that necessitates an expedited response. Approval processes may be modified to account for the urgency of the situation, but thorough documentation is still required for future usage and continuity management.

Applying the service value chain (SVC)

Within ITIL, the delivery of IT services is structured around the service value chain. This is a generic framework that outlines the various ways that IT teams can deliver value across the organization while delivering products and services.

This comprises six activities:

1. Plan - Understanding the current state of our processes, including opportunities for change and improvement.
2. Improve - Identifying specific improvements that can be implemented.
3. Engage - Working with stakeholders across the organization to understand where IT can deliver value.
4. Design and transition - Developing new solutions, systems, processes, and policies that meet the requirements of stakeholders.
5. Obtain/build - Acquiring the capabilities we need to put changes into practice.
6. Deliver and support - Implementing new products and services in line with agreed specifications.

The service value chain applies to all of ITIL’s constituent practices, as well as to our ITSM efforts as a whole. However, certain processes and services might be more or less weighted towards certain activities within the SVC.

As such, applying the service value chain to our change management efforts could involve:

• Plan - identifying demand for change, allocating the necessary resources, workload scheduling, contingency management, forecasting, and other planning activities relating to implementing change.
• Improve - assessing and analyzing proposed changes to determine if proposed changes can enhance existing processes, tools, or assets.
• Engage - working with stakeholders across the organization to understand and secure agreement on proposed changes.
• Design and transition - developing plans and roadmaps for implementing specific changes.
• Obtain/build - acquiring any new capabilities or CIs required to enact change.
• Deliver and support - implementing changes, including any work required to ensure a smooth transition.

It’s also important to think in terms of how we can apply change management tools and processes to other elements of the service value chain.

That is, across all of our ITSM efforts, implementing an SVC-based approach will invariably require change, both in terms of change control and organizational change management.

For instance, building change request and authorization workflows into our engagement with stakeholders in order to build consensus across the organization will also maintaining control and visibility within our IT service delivery.

Measuring value

One of the central principles of ITIL is focusing on delivering value for service users and other stakeholders across the organization.

As such, in order to adequately apply ITIL thinking to our change management efforts, we must understand exactly where this contributes value, as well as the specific metrics that we can benchmark this against.

Given the nature of change management, there are two key strands to how we can deliver value.

The first relates to the impact of individual changes. So, we can benchmark our change management efforts against KPIs relating to specific improvements we’re seeking to make with individual changes.

Alternatively, we can take a more operations-focused view, assessing the value we deliver through change management in terms of the costs, timelines, administrative burden, and service user satisfaction.

Change management and other ITIL practices

ITIL also emphasizes a holistic approach to IT service delivery. This stems from a recognition that there is a huge degree of overlap between the 37 constituent ITIL practices.

As such, it’s crucial to have a clear picture of where both change control and organizational change management most commonly intersect with other core processes.

In the case of change control, the biggest overlap is with service configuration management. This is the process concerned with handling and documenting any element that contributes to our service delivery. These are described as configuration items (CIs).

CIs can include devices, software tools, infrastructure, policies, information assets, human resources, or anything else that’s needed to deliver our services.

The primary point of overlap here is keeping our change management database accurate and up to date as part of our change control processes.

Organizational change management is more heavily interconnected with ITIL practices under the general management umbrella, especially relationship management, knowledge management, risk management, workforce and talent management, and any other processes that relate to the human aspects of change.

Change management practices are notable in their applicability to just about all other areas of IT service delivery. That is while implementing any of ITIL’s constituent practices, we’ll almost certainly encounter a need to assess and implement change in a controlled manner.

Benefits and challenges of ITIL change management

Next, we can flesh out our understanding of why we’d implement ITIL change management rather than a competing framework, as well as some of the key challenges we’re likely to encounter along the way.

Benefits

ITIL is based on seven core principles that are tightly linked to how applying the framework to our IT services provides benefits across the organization.

Specifically, ITIL’s guiding principles are:

1. Focus on value,
2. Start where you are,
3. Progress iteratively with feedback,
4. Collaborate and promote visibility,
5. Think and work holistically,
6. Keep it simple and practical,
7. Optimize and automate.

Applying these principles to our change management workflows, we’re likely to see the following positive results:

• Improved efficiency - Standardizing change processes into their optimal flows in order to minimize both times to resolution and resource incursion.
• Reduced risk - Providing IT colleagues with a systematic approach to identifying, assessing, and mitigating the risks of proposed changes.
• Clear responsibilities - Ensuring colleagues across the IT team and the wider organization understand who is responsible for authorizing specific kinds of changes.
• Enhanced service quality - Including both service performance and user satisfaction metrics.
• Integration across services - Working holistically helps to ensure that change management integrates neatly with interrelated practices.
• Clear paper trails - Providing a robust, consistent record of when and why changes have been implemented.
• Communication and visibility - Establishing systematic, efficient channels for communicating within IT teams and across the wider organization.
• Continuous improvement - Providing a basis to continuously identify and implement improvements to our change management process and other ITSM activities.

Challenges

ITIL’s core principles make it a flexible framework that can be implemented in a wide range of contexts, largely irrespective of the current state of our IT operations.

Specifically, guiding ideas such as starting where we are, thinking holistically, and focusing on practical solutions make ITIL applicable across organizations starting from a wide range of positions.

Nevertheless, there are several common stumbling blocks that can derail our change management efforts. We must therefore be aware of these in order to maximize our chances of success.

The most pertinent challenges include:

• Internal resistance to change - Resistance to change occurs when stakeholders’ goals don’t align with our change initiatives. Successful change management relies on establishing agreement and buy-in for new changes.
• Securing resources - Securing the financial and other resources to implement changes can often be challenging, especially for IT teams working within tight budgetary constraints. Therefore, it’s vital to demonstrate the value that changes deliver, as well as prioritizing the flexibility required to adapt to financial realities.
• Handling change in complex IT environments - Change management is more difficult in complicated IT environments, where individual elements of our service delivery are bound by a large, complex web of dependencies. Effective configuration management is, therefore, vital to provide clarity around the potential impact of proposed changes.
• Poor documentation and knowledge management - Poor documentation within our IT environment makes change management a considerable challenge, as it can be difficult to assess the current state of the services in question. This can be overcome by introducing effective knowledge management practices across the organization, empowering change managers to make informed decisions.
• Compliance and security issues - Change management is highly constrained by regulatory considerations, including thoroughly vetting proposed changes to ensure their compliance with internal and external security, financial, and legal requirements.

While each of these can present additional workloads and considerations, they also further emphasize the importance of developing and implementing effective change management processes.

Best practices

ITIL v4 introduced a shift in focus from prescriptive processes to more flexible practices within ITSM service delivery.

As such, it does not offer a rigid structure for managing either change control or organizational change as constituent processes. Rather, the goal is to provide an approach that can be applied to unique processes that meet the needs of real-world service users.

At the same time, we can infer important best practices from ITIL’s core principles that are helpful for driving effective change management.

Modeling change data

From a technical perspective, the most important thing we can do to support change management is standardizing the data that underpins our workflows.

In the first instance, this is closely tied to our configuration management efforts. The key here is ensuring that we have the required attributes stored within our CMDB to reflect the potential areas where change could occur.

We should also pay special attention to our change request workflows, specifically how we can structure requests as data entities.

Gathering and storing request data within a defined, consistent schema is the first step to establishing effective, rules-based workflows across change control and management.

Classifying and prioritizing changes

Earlier, we saw that ITIL describes four distinct categories of changes based on their likely impact, associated risks, and required authorization processes. However, the more granular details of this are not prescribed.

In order to implement this framework in a real-world context, we must define the specific criteria that we’ll use to determine what’s a normal, standard, major, or emergency change.

This is totally contingent on our unique internal needs. We’ll likely draw on a range of factors here, including the impact of a change, the associated costs, the dependencies of the CI in question, and the importance of the related processes.

These factors will typically be weighted differently across different kinds of changes. For instance, with a new software release, we might mainly be concerned with the extent of the code change and the risks involved.

By contrast, categorizing changes relating to our hardware estate will generally be based largely on financial thresholds.

Defining controls based on change categories

As we alluded to earlier, one of the key characteristics of a successful change management practice is achieving alignment between how we categorize changes and the controls we put in place to authorize and govern them.

As well as the categories outlined above, we’ll typically treat changes differently based on the CI that they relate to. For instance, having distinct workflows for standard, normal, major, or emergency changes to network hardware, core service, end-user devices, or other assets.

Earlier, we discussed how we can define approval criteria and change authorities for various kinds of requests.

As part of our wider service management efforts, we’ll also need to specify the changes that specific colleagues are authorized to request, typically as part of our service catalog management practice.

Standardizing change workflows

With controls defined, it’s critical to put measures in place to ensure standardization and process adherence.

Our goal here is to make sure that consistent, established patterns are followed during change requests and implementation.

One of the key strategies we can leverage here is providing colleagues with workflow tools that are suitable to their needs, including request forms, monitoring dashboards, approval apps, knowledge bases, and more.

We’ll return to this idea shortly.

Integration with knowledge management and configuration management

As we said earlier, two of the other ITIL practices that intersect most closely with change management are configuration management and knowledge management. Respectively, these deal with information relating to our IT processes and the elements that contribute to them.

There are two specific types of integration here that we need to be concerned with.

The first is applying holistic thinking across our IT services in order to build the needs and logic of related ITIL practices into each area of our service delivery.

The second is actually integrating data and processes across related ITIL practices in order to maintain accuracy and consistency. For instance, using developments within our change management practice to trigger updates in our configuration management database.

Automating change controls

Lastly, we can achieve substantial efficiency improvements by implementing automations across our change management practices.

This can come in a few distinct forms. In some cases, we may be able to fully automate certain authorization controls. For instance, if the assessment criteria is a simple financial threshold, we could authorize change requests that are beneath this.

Even in situations where manual authorization is still required, we can greatly reduce the workload on the colleagues involved by automating simple tasks, like triggering automations when a new request needs their attention.

This also applies to basic administrative tasks, including those related to keeping our change management initiatives consistent with our configuration management database.

Tools for managing change

ITIL is focused on providing a playbook for delivering value through IT services, but it’s somewhat agnostic on the specific tools and capabilities that we need to have in place in order to facilitate this.

However, there are certain capabilities that almost every organization will require for effective change management.

The first thing we’ll need to account for is storing data. There are a few distinct approaches here, including a dedicated change management database, managing change within our configuration database, or combining the two in a federated system.

We’ll also need to furnish our colleagues with appropriate tools for interacting with this data.

The key to this is providing tools that account for different colleague’s roles within processes. For example, providing request forms for on-the-ground colleagues, along with admin tools for change authorities to review and approve these.

On top of these core capabilities we might also want to implement a range of other solutions, including leveraging automation tools or providing dedicated knowledge management capabilities within our change management practice.