ITSM

How To Get Started With IT Change Management

February 6, 2020

How To Get Started With IT Change Management

Change doesn’t come easy for most. That is also true in the world of IT. While change management can be intimidating, it can produce valuable benefits to the organization when there’s a solid foundation for changes in place.

Generally, changes fall into two buckets: proactive to ensure the effectiveness of a new product or reactive if something doesn’t work properly.

At its core, ITIL change management involves communicating clearly to the people affected by the change, and reducing frustration while improving service quality. Following IT change management best practices allows IT departments to plan and implement changes with greater efficiency and lower risk.

Why is Change Management Important?

Think about the process of a business changing video conferencing software. That process will most likely entail uninstalling the current software, setting a time to install the new software, testing it to make sure it works, and fielding questions, concerns and possible issues with the new software. Chances are the IT department will be responsible for making sure the process is as seamless as possible end-to-end.

A great way for IT and other relevant departments to prepare for the transition is to put a change management plan in place. By putting together a plan of action, IT teams and key stakeholders can minimize the impact on employees and disruption of changes. Two crucial elements of any good plan are rollback and test plans. This help guarantees the change is carried out effectively, and in the event that the change doesn’t go as planned, provides an opportunity to reverse course.

Essentially, rollback plans can ensure the change won’t impact the businesses service lines. If the change causes issues, system admins can restore data from a backup. Test plans involve a group of people ensuring the change was successful after it goes into effect.

What is a Request for Change?

All change records come from somewhere. They’re usually created when an employee or a service technician submits what’s called a request for change (RFC). Organizations have different ways of submitting these requests, but a recommended best practice is to use the service catalog. This way, organizations can grant or deny access to different request forms depending on who the requester is. IT can then create change records based on those service catalog form submissions.

While IT pros are often responsible for implementing changes where the entire business is impacted, change requests can also be submitted by employees—changes that have little or no impact outside of that immediate employee. These smaller scale changes could include the installation of or access to new software, ordering a newer model laptop, or reconfiguring an office space.

Once upon a time in ITIL, all change requests, big or small, had to go through a change advisory board (CAB) or change process. Today’s ITIL best practice recommends that the CAB pre-approves these standard changes.

This allows employees to easily request the change through the service catalog—creating documentation around standard changes and removing unnecessary approval processes that more complex changes might require.

Best Practices for Change Requests

While not all changes are created equally, there are a handful of best practices that apply generally to changes–big and small–in an organization.

  • Develop a habit of documenting requests. This is a good practice for IT pros as well as employees because it allows them to see if the change they’re requesting is justified. It also helps them to consider the impact the change will make.
  • Create records for every change and tie them to a configuration management database (CMDB) to help service technicians identify what’s been approved and rejected when future changes are requested.
  • Categorize changes in order of priority. Determine the way a change is evaluated and implemented and help avoid change collision (overlapping changes occurring at the same time).
  • Ensure related changes are aligned to reduce the amount of time spent to implement the change, risk and disruption to employees.
  • Provide visibility to requesters into the status of a change in case more information is needed for certain approvals.

It’s also important to keep the seven R’s of the change management process top of mind:

  1. Who raised the change?
  2. What’s the reason for the change?
  3. What is the expected return for the change?
  4. What are the potential risks involved?
  5. What are the resources required to execute the change (and to clean up afterward)?
  6. Who is responsible for each aspect of the change?
  7. What is the relationship between this and other prior, contemporary, and potential changes?

An eighth and unofficial R of the change management process to consider is, what are the potential consequences of rejecting the change?

What Makes for a Good Change Record?

A good change record reduces potential frustration of unexpected changes and keeps track of a change’s lifecycle. When creating a change record, be sure to include devices, applications, or configuration items (CIs) that might be impacted by the change. This gives service techs insight to what’s expected to happen, when it will occur, and its timeframe. Audit trails of those who work on the change record can be easily identified in it as well.

Change Management in an ITSM Solution

An ITSM solution can make ITIL change management a much more streamlined process, providing structure to what can otherwise become messy. IT professionals can better manage the people and assets impacted, and the incidents that may arise when a change is implemented. By implementing an ITSM solution and following the change management best practices detailed above, organizations can be better equipped to plan for and efficiently execute changes across the organization.


Liz is a technical point of contact for SolarWinds Service Desk customers, providing expertise on ITSM best practices, APIs, integrations, and security. She's ITIL 4 certified and has never met a dog she didn't want to adopt.