Is your organization planning to boost its IT service management (ITSM) maturity level by formally entering the world of change management? Why formally? All companies deal with change, but not all do so in a consistent and controlled way, i.e. with a formal change management capability. If you are, where do you start, and how demanding do you need to get with the change management processes that you wish to implement? This blog will attempt to provide some assistance in helping you along with your change management journey.

Why Change Management?

The purpose of change management is to improve the availability of IT services, especially the services that are critical for the ongoing welfare of the business.  And by introducing a formal change management capability, the adverse effect of failed changes – disruptions to the IT services – should be minimized. 

Doing nothing is not a viable option, as changes will always need to be made to the IT infrastructure; and thus a capability needs to be put into place to ensure that changes are made by the least disruptive means possible.

What is Change Management?

First off, let’s define what changes and change management are from an ITIL – the ITSM best practice framework –  perspective.

ITIL defines the following types of changes:

  • Standard change – a change to a service or infrastructure that is pre-authorized and has an accepted and established procedure to provide a specific change requirement.
  • Normal change – this change is raised by a request from the initiator – an individual or organizational group – that requires the change.
  • Emergency change – urgency is sometimes required and these should be designed carefully and tested before use if at all possible – or the impact of the emergency change may be greater than that of the original incident. Change details are often captured at a later date

This is how the different types of changes are used:

  • Standard – this low-risk change is pre-authorized so doesn’t need to go a Change Advisory Board (CAB) meeting for approval. Standard changes are routine things – like maintenance, minor DevOps releases, or weekly server reboots. The activities required to implement the change are well known and proven to work properly.
  • Normal – These are changes that are more infrequent, are broader in scope, or are touching a critical piece of infrastructure. These will all need to follow a defined change management process including approval.
  • Emergency – these changes are outside of a normal CAB review process. They may be used for things like a server reboot to clear an issue raised by event management or some sort of error that is affecting a service to a great degree. These do not go through CAB review but should go through a post-mortem review to make certain that the appropriate procedures were followed.

Normal Changes in More Detail

Normal change types are the heart and soul of change management activity. These types of changes should be far and away the majority of changes that are actively looked at and tracked. The number of the other two types should certainly need the minority of change management attention – as emergency changes should be minimal and standard changes shouldn’t need to get change approval once classified as a standard change model.  

A normal change should go through the following sequence of events:

  • Define the change that’s required.
  • Approve the effort to develop the change.
  • Develop the change – depending on the specific change, this may be code changes, planning a software implementation, or development of a solution to a problem, etc.
  • Test the change – this includes the back out plan in the unlikely event that the change fails for some reason.
  • Propose a scheduled start date/time for the change.
  • Review by the CAB – the CAB should evaluate the change request to:
    • Make certain that the proposed scheduled start date/time doesn’t adversely impact any other business critical functions or previously scheduled changes.
    • Determine if risks inherent in making the change are acceptable.
  • Implement on an agreed-upon start date/time within the allotted change time window.
  • Document the configuration item (CI) changes made in the configuration management database (CMDB).
  • Review the change after completion to make sure it meets the expectations, and that the incidents caused by this change are within acceptable limits.

These steps will need to be tweaked based upon organizational requirements, but they provide the backbone for a change management process.

Implementing Change Management

Where does one start when looking at change management? It can be very daunting at the outset, but these steps should help to get you started:

  • Identify people in the organization to be the process owner and change manager.
  • Design the change process. Things to think about include:
    1. Plan how changes will flow through the organization. Many process flow documents already exist that can be downloaded from the Internet, for example http://wiki.en.it-processmaps.com/index.php/Change_Management
    2. Determine what changes will be standard changes and will receive pre-approval.
    3. Decide if there will be an emergency change approval process and how the post–mortem on emergency changes will be handled.
    4. For failed normal changes, how will they be re-scheduled to assure a successful change?
    5. Not making the process a burden – if it is, then it won’t be implemented.
  • Start small with a particular group or particular type of change to make certain the process is working as desired.
  • Determine which change management key performance indicators (KPIs) are most important to your organization and then how they will be monitored.
  • Communicate the process and KPIs throughout the entire organization.
  • Monitor the change management process and improve (using continuous service improvement) where necessary to maintain and improve operations.

Example KPIs and Metrics for Change Management

Here are some KPIs for change management that might be of help – don’t just pick them up and use them, first you’ll need to understand which will help your organization to meet its goals best:

  • The number of changes implemented to services which met the customer’s agreed requirements, e.g. across quality/cost/time (expressed as a percentage of all changes).
  • Reduction in the number of disruptions to services, defects, and rework caused by inaccurate specification or poor/incomplete impact assessment of changes.
  • Reduction in the number of unauthorized changes.
  • Reduction in the backlog of changes.
  • Reduction in the number and percentage of unplanned changes and emergency fixes.
  • Change success rate – the percentage of changes deemed successful at review/number of requests for change (RFCs) approved.
  • Reduction in the number of changes where back-out is invoked.
  • Reduction in the number of failed changes.
  • Average time to implement based on urgency/priority/change type.
  • Incidents attributable to changes.
  • Percentage accuracy in change estimates

Change is here to stay in both the business and IT worlds. And not only is it here to stay, the pace of change continues to accelerate. Every IT department has some form of change management capability in place but, if yours is informal, your business would greatly benefit from implementing a more formal approach to managing change. It will reduce risk and the unwanted effects of badly implemented change, plus it might also speed things up.