What is IT change management?

Change management—also known as change enablement or change coordination—is an IT practice designed to minimize risks (disruptions to IT services) while making changes to critical systems and services. A change is adding, modifying, or removing anything that could have a direct or indirect effect on services.

Change management ensures that standard procedures are used for efficient and prompt handling of all changes to IT infrastructure, whether it’s rolling out new services, managing existing ones, or resolving problems in the code. Effective change management provides context and transparency to avoid bottlenecks, while minimizing risk. 

For some teams, change management involves every aspect of change—from technology, people, and process to the impact on customers and systems. For others, change management is focused on the people and process side of change. ITIL 4 has drawn a distinction between change control and organizational change management practices.   

  • “The purpose of the organizational change management practice is to ensure that changes in an organization are smoothly and successfully implemented and that lasting benefits are achieved by managing the human aspects of the changes.” 
  • “The purpose of the change control practice is to maximize the number of successful service and product changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing the change schedule.” This is largely focused on ensuring that changes released into production don’t cause problems. 

Whether your team breaks out change management and change control under two definitions or only one, both are important to successful change.

Why is IT change management important?

Modern organizations have a couple of critical, and competing expectations for their IT team. First, they expect stable, reliable services that ensure the organization is productive and able to meet end-users expectations. Second, the IT team needs to implement regular service updates to enable the organization to adapt to constantly changing security, cost, and other business requirements.

Failure to do either can result in dire consequences. Inability to maintain reliable service can cause massive damage to productivity and costs. Many organizations report downtime costing more than $300,000 per hour, according to Gartner. For some web-based services, that number can be dramatically higher. At the same time, organizations that aren’t adapting for the future will become unable to keep pace with the speed of business and fall behind their competition. An over-resistance to change, could result in your best employees defecting to  work in places with less clunky systems or your end-users sending their support and dollars to other organizations that provide them more value. 

So, how are you supposed to manage these conflicting needs? A change management practice enables your organization to effectively accomplish changes by ensuring stability and mitigating risk all while shipping service updates that deliver rapid value to the organization and its stakeholders. Change management enables teams to provide a great experience to end users, deliver new services with agility, and show demonstrated value to the business. 

Change management helps accomplish change in the following ways: 

  • Establishing a framework to manage the change process 
  • Prioritizing necessary changes to properly allocate resources 
  • Involving necessary stakeholders from dev and IT for approvals 
  • Incorporating testing of changes, to avoid incidents
  • Streamlining and improving the flow of changes to deliver value more quickly 

Today, the stakes are even higher as the rise of software powered services has raised customer expectations and demand for always-on, high performing services. In an ever more dynamic environment, the work needed to manage service keeps growing, whether it involves rolling out new technologies, managing existing ones, or even modifying vendor contracts. Change management assures this can happen while mitigating the risk of impacting customers and stakeholders in a negative way. 

Types of change management

ITIL defines three types of changes:

Standard changes

Standard changes are low-risk, commonly repeated, and pre-approved. They’re performed frequently and follow a documented, approved process. 

For example, adding memory or storage is a standard change. Replacing a failing router with an identical working router is a standard change. Creating a new instance of a database is a standard change. 

All of these changes are common and follow a well-defined process. And because, presumably, that process has already gone through change management’s risk assessment and approval process once, it doesn’t need to go through the process again every time a router needs replacing. 

For many companies, standard changes are a prime opportunity for automation. Some companies report that as many as 70% of standard changes can be automated—freeing up their teams to focus on normal and emergency changes. 

Normal changes

Normal changes are non-emergency changes that don’t have a defined, pre-approved process. 

For example, upgrading to a new content management system is a normal change. Migrating to a new data center is a normal change. Performance improvements are normal changes. They’re not standard and repeatable. There are risks involved. But they’re also not emergencies. Which means they can go into the usual change management queue for risk assessment and approval.  

Some normal changes—like a data center switch—are high-risk and may require risk assessment and approval from a change advisory board (CAB). Others—like a website change—may be low-risk and can be approved on a quicker timeline by a designated change authority or via automated checks and peer review.

Emergency changes

These changes arise from an unexpected error or threat and need to be addressed immediately—usually to restore service for customers or employees or secure systems against a threat. 

For example, implementing a security patch is an emergency change. Dealing with a server outage is an emergency change. Resolving a major incident is an emergency change. 

The urgency of emergency changes means they need to be handled on a much tighter timeline because the risk of a lengthy review process is higher than the risks involved with resolving the issue quickly. 

What is a change advisory board (CAB)?

In most traditional IT organizations, a change advisory board (CAB) is tasked with assessing the risks of and approving (or not approving) each change. Typically, the CAB holds regularly scheduled meetings to review all proposed upcoming changes, pulling in experts as needed to explain, defend, or assess the change with them.

On one hand, change advisory boards may help reduce risk and raise the alert when a change simply won’t work for the company. On the other hand, they can also create a bottleneck—especially when they’re made up of people who aren’t technical experts. In many enterprises, the change advisory board (CAB) approval process is complex and time-consuming, which slows down the change process. 

Many IT teams are moving away from these approaches, or limiting them to only most riskiest changes. ITIL 4 encourages decentralizing your change authority into the business stakeholder or peer level. Instead of using a separate committee, build change control into your normal workflow with relevant stakeholders in your steering committees or weekly meetings. To avoid bottleneck situations, teams are often turning to automation, virtual checklists, and peer review as a nimbler and more collaborative alternative for all but the riskiest of changes.    

The change management process

For nimble, high-velocity teams, the change management process is shifting—away from lengthy reviews and non-technical stakeholder approvals and toward automated, collaborative processes between IT and development teams that increase agility while still balancing risk.

Here is a standard change management process, along with our recommendations to increase your speed to delivering value. 

Step  Best Practices

Change request - Someone requests a change and includes notes on possible risks, expected implementation, and affected systems.

Set up an intuitive self-service portal for stakeholders and IT staff to easily raise a standard change request. 

Assure that your development teams and IT teams can collaborate on the same platform for full context and transparency throughout the change request workflow. 

Change request review - A change manager or peer reviewer reviews the initial change request. How likely is it to be successful? Are the risks and rewards accurate? Is it worth making?

Use automation to auto-approve the change or kick off a brief approval process before the change gets implemented.

Change plan - The team creates a game plan for the change. They document expected outcomes, resources, timeline, testing requirements, and ways to roll back the change if needed.

Align stakeholders quickly with a change management kick-off.

Get teams on the same page with knowledge base templates to document your change plans. 

Change approval -The appropriate change manager, peer reviewer, or CAB reviews the plan and approves the change.

Streamline approvals with peer reviews. Fight siloes, with shared work tracking and documentation, so people can easily and asynchronously collaborate. 

Change implementation -The team ships the change, documenting procedures and results along the way.

Use automation to enable your processes and standards. Workflow automation can route and assign requests to the next authorized person based on your business rules.

Change closure - When appropriate, the change manager reviews and closes the change when appropriate. Their report should communicate whether the change was successful, timely, accurately estimated, within budget, etc.

Retain accessible knowledge base articles and tickets so teams can learn from previous work. Perhaps there are opportunities to automate similar change requests in the future.