What is IT Change Management?

Change isn’t just inevitable, it’s necessary – especially if you want to adapt to meet shifting organizational needs and rising customer expectations. But IT changes come with their own set of risks. If you want to make continuous improvements to your services without disrupting your business operations, you need to have a standard process in place for dealing with changes.

In addition to minimizing the impact of disruptions to your services, Change Management has a number of benefits. With a solid Change Management process in place, you can:

• Implement changes more quickly
• Track the progress of changes to your IT infrastructure
• Communicate more transparently with stakeholders
• Easily trace the roll-out of any changes if something goes wrong
• Provide more accurate cost estimates for any proposed changes

IT Change Management shouldn’t be confused with Organizational Change Management. While IT Change Management concentrates on managing changes to IT systems and infrastructure, with the primary goals of minimizing disruption, mitigating risks, and ensuring compliance, Organizational Change Management (OCM) focuses on the human and process-related aspects of change within an organization.

In IT, a change is defined as any modification, addition, or removal that could have a direct or indirect effect on your IT services. These can be changes to your IT infrastructure, hardware, documents, processes and more.

If a change helps you improve your organization’s IT infrastructure, while keeping disruptions to a minimum, where do incidents and problems fit in?

Let’s look at the definitions. An incident is a single event in which one of your organization’s (internal) services isn’t performing as you’d like. Think of an employee’s laptop that won’t boot properly. This is where Incident Management would come into play.

A problem, on the other hand, is a recurring interruption to your IT services. Say you’ve just had lunch and return to over twenty incidents about a printer on the second floor that isn’t working. Together, these incidents form a problem about a defective printer. This is where your Problem Management process comes in.

Finally, to replace the printer with a new one, you’d need to implement a change. This is where your Change Management process would start.

In general, ITIL isn’t prescriptive when it comes to processes, but a typical IT Change Management process will include the following steps:

1. Submitting a formal Request for Change

If someone wants a change to be implemented, they first need to submit a Request for Change (RFC). An RFC contains all the information needed to approve a Change. The level of detail required here depends on the type of change and the expected impact of the change.

2. Reviewing the RFC

The person who takes ownership of the Change Management process then needs to review, categorize and prioritize all incoming requests for changes. Based on the RFC, the change owner can then choose to either move on to the next step and assess the change, reject the change, or ask for more information.

3. Assessing impact and analyzing risks

Now, you need to carry out an in-depth assessment of the proposed change and identify any potential associated risks. This is where a Change Advisory Board (CAB) could come in. At this stage, you should also consider factors like cost or any compliance requirements or restrictions, as well as the potential impact on your services.

4. Approving the proposed change

Once you’ve carried out a thorough assessment of the proposed change and its impact and identified any risks, it’s up to the relevant authorities to approve or reject the proposed change.

5. Planning and scheduling the change

As soon as a change gets approved, it’s time to go into planning mode. A group of relevant stakeholders should create a detailed planning, outlining the steps required to implement the change. This should include an overview of resources, a timeline, and roles and responsibilities. You then need to schedule the change, ideally during a time that will cause minimal disruption, such as during off-peak hours or a maintenance window.

In the ITIL (Information Technology Infrastructure Library) framework, Change – and Release Management is part of the Service Transition lifecycle stage. This is one of the five lifecycle stages of the ITIL framework. Service Transitions help your organization to plan and manage the change of state of a service in its lifecycle.

Standard changes

For these kinds of changes, the implementation process and the risks are known upfront. Standard changes are managed according to policies that an IT organization already has in place. An example of a standard IT change could be installing a new printer, or software on a laptop.

Normal changes

These changes have to go through a change process before they can be approved and implemented. If they are high-risk, a Change Advisory Board decides whether they will be implemented. A normal change could be moving a new development project into production or adding a new server.

Emergency changes

These are changes that must be performed as soon as possible. An example of an emergency change: fixing a security breach requiring a patch to many workstations.

The specific roles and responsibilities you need for a successful Change Management process will depend on your organization’s needs. But there are a few typical roles within a Change Management team:

1. Change Requestor

This is the person who requests or initiates a change.

2. Change Manager

The Change Manager is the owner of the entire Change Management process, with the authority to approve changes. For very important and impactful changes, the Change Manager may refer the authorization of changes to the Change Advisory Board (CAB).

3. Change Advisory Board (CAB)

A Change Advisory Board is a group of people who advise the Change Manager in assessing, prioritizing, and scheduling changes. The CAB is made up of representatives from throughout the IT organization. A CAB may also have a sub-group called the Emergency Change Advisory Board (ECAB), who make decisions regarding emergency changes.

Done right, IT Change Management can reduce the number of incoming incidents, while minimizing service disruptions and allowing your team to be more agile. Here are a few best practices for Change Management that every service desk should be aware of:

Create a communication plan

When implementing changes, you need to be clear in your communication – both with stakeholders and the wider organization. Keeping people in the organization in the loop about any planned changes should reduce the number of calls your service desk gets when a change is made.

Track the lifecycle of your changes

Keep an eye on your change throughout its entire lifecycle to ensure that it’s implemented according to the change plan. This also allows you to see how effective your change process is and helps you identify areas for improvement.

Embrace continual improvement

Better IT Change Management comes from learning and making adjustments along the way. Carry out post-implementation reviews (PIR) after a change has been implemented – examine what went well and what could have gone better and take steps to improve your change process the next time around.