A Beginner’s Guide to ITIL Change Management

Technology evolves rapidly, so Information Technology (IT) systems require regular maintenance and updates. Executing these changes is a key IT task, but performed incorrectly, and a system can stop functioning.

ITIL, the Information Technology Infrastructure Library, provides a framework to implement technical changes. It’s among the many IT best practices that ITIL defines. The UK government established ITIL in the 1980s, and it became a widely-adopted standard for managing an IT organization.

The ITIL framework that addresses technical changes is called change enablement. It’s sometimes referred to as a change control, or if you’re using ITIL v3, change management.

Overview: What is ITIL change management?

Change management is the set of processes that oversee an addition, modification, or removal of any component of an IT system. Its goal is to ensure system changes occur with minimal disruption and maximum efficiency.

ITIL defines three types of changes: standard, normal, and emergency.

• Standard changes: These are pre-approved, low-risk, and regularly repeated changes. An example of a standard change is replacing a broken router with an identical unit. Standard changes are common, and follow a well-defined workflow.
• Normal changes: Any non-emergency change requiring authorization and a defined process falls under this category. The implementation of new IT help desk software is considered a normal change. If associated costs or risks are high, the change requires a risk assessment and approval from the applicable stakeholders.
• Emergency changes: An emergency is any change that warrants immediate attention due to the potential for significant business loss. These changes typically arise when an IT system is not functioning as intended, called a bug. The emphasis is on quick remediation to minimize any impact to system users.

Even change management experiences change. To avoid confusion with organizational change management, ITIL renamed this process change enablement under ITIL version 4 in 2019.

Not only that, ITIL v4 moves away from the previous prescriptive steps of a change management process to an approach that encourages flexibility and efficiency, incorporating the principles of agile project management.

How your business can benefit from change management

Why spend time implementing this process? ITIL change management delivers several boons to your organization.

1. Reliable IT systems

IT systems reliability is paramount. Most businesses depend on technology, and if that technology fails, a company can lose revenue, staff productivity, or even customers. With proper change management protocols in place, your system updates avoid issues, while building user confidence in your systems.

2. Improved understanding of change implications

Every change involves benefits and possible downsides. Change management processes allow an IT team to assess a change to understand the implications.

The IT team and the entire company can make the appropriate decisions about changes, particularly those that have a significant impact on the organization, such as the costs and benefits of upgrading to a new software platform.

3. Proper priority to changes

Some changes must happen quickly without unnecessary bureaucracy. Others require stakeholder approval, especially if costs or risks are high.

A change management process allows an organization to execute changes with the appropriate level of oversight while enabling the IT team to maintain or evolve its services in a timely manner to maintain the company’s competitive edge.

The ITIL change management process

Because ITIL v4’s change management process is more about general best practices than specific workflows, you’ll find an overall structure below. Use what makes sense for your organization.

Process 1: Change request

Every change to a company’s technology incurs costs, such as the IT team’s time and resource allocation, and risks of system issues. The larger and more impactful the change, the higher your costs and risks.

That’s why ITIL employs three change types.

• Standard changes, because of their low-risk nature, occur as a routine part of IT operations. If your IT team uses a continuous integration (CI) model, where automation processes software code changes instantly, CI falls under the standard changes umbrella.
• Normal and emergency changes can inject significant risk of system failure, so these changes require a change request. The ITIL change request is a formal application outlining the nature and scope of the change such as the affected systems, potential risks, costs, and the benefits.

This change request is submitted to an individual, called the change manager, or to a group responsible for reviewing the request and making a decision whether to approve or reject it.

Process 2: Change request assessment

The change manager oversees the change management process. Depending on the frequency and volume of change requests, the change manager is a dedicated position or a member of the IT team assigned the role.

The change manager authorizes small, low-risk changes. Other change requests go to a group responsible for reviewing them and making a decision. Usually this group involves the team responsible for implementing the change, such as software developers.

Extensive and costly or high-risk asks, like the purchase of new accounting software, are reviewed by a committee with the authority to approve change requests called a change advisory board (CAB), consisting of cross-functional company stakeholders. The CAB only reviews non-emergency changes.

If a change request is an emergency, time is of the essence. Low risk emergencies can be resolved without a formal review process. Higher risk emergencies require some formal review by the IT team to evaluate potential solutions, but this review process is streamlined compared to what’s needed for a CAB.

Process 3: Change planning

Approved change requests undergo a planning phase. This planning varies based on the approach your organization uses to implement projects.

• For projects requiring extensive upfront planning, use a formal IT project plan that outlines timelines, resources, budgets, and testing requirements.
• For IT teams employing an agile framework such as scrum or kanban, the work is broken down into individual tasks, prioritized, and scheduled for completion in phases called iterations or sprints.

Emergency changes also require a simplified change management plan. The IT team must decide who will build and implement the emergency fix, timing for its roll out, and any necessary internal and external communication.

Process 4: Change build

This process involves the steps for building the required changes. If your company sells software products, software code changes occur at this point. If you’re using a software or hardware component from a third party, execute the steps for setting up that component and integrating it with your existing systems.

Standard changes follow predefined workflows such as CI. Normal changes follow a project plan or the team’s agile approach. Emergencies require the team to prioritize the completion of changes to fix the issue.

Change management doesn’t manage the build process. That occurs through the execution methodology your team adopted, such as agile or waterfall. Instead, change management is about ensuring the build happens on time based on the type of change.

Process 5: Change deployment

Change deployment goes hand-in-hand with ITIL release management processes. The change manager ensures changes are properly developed, tested, and signed off before the IT team schedules and launches those changes under release management.

Standard changes typically don’t require a formal release management process. When the change is ready, it’s executed.

Normal and emergency changes are higher risk, so must undergo structured release management, where the IT team plans, schedules, and deploys the changes following the release management process.

This ensures risks are kept to a minimum and contingency plans are in place in case something goes wrong during the deployment.

Process 6: Change optimization and closure

Once changes are live, the change manager formally closes out the change request and follows up with stakeholders on the results.

One other key component is change optimization. This concept involves the IT team reviewing the entire change management process in the context of the recently completed change to determine where they can improve. The goal is to increase team effectiveness as well as the quality of the outcomes.

How ITIL change management compares to other ITIL processes

Several ITIL processes combine with change management to create a holistic IT solution. Change management focuses on the overall process of introducing IT system changes. It partners with service request management, incident management, problem management, and release management processes.

• Service request management: IT teams employ a process for system users to request changes or help called service request management. Change requests come through this channel.
• Incident management: Any issues that arise within IT systems, such as a software bug, are called incidents in IT nomenclature. Severe incidents create the need to execute an emergency change.
• Problem management: A systemic issue with your company’s technology falls under the ITIL problem management category. These may be emergencies, but usually fall under the normal change umbrella.
• Release management: As the set of processes for releasing changes into IT systems, release management acts as a sub-process of change management. Changes approved through the change management process undergo release management.

A last word about ITIL change management

With the widespread adoption of agile methodologies, IT teams must remain flexible to adapt to the fast rate of change. The change management process is about unlocking that flexibility while managing risk to IT systems.

When implementing change management principles, review the project execution approach the IT organization currently employs. Is it agile? Is it more rigid? How may it need to evolve to support the needs of your business? Let these factors be your guide to implementing a successful change management process.