Is your organization planning to boost your ITSM maturity level by entering the world of change management?  Where do you start and how demanding do you get with the change management processes that you implement?  This article will attempt to provide some assistance to help you along that journey.

Why Change Management?

The purpose of Change Management is to improve the availability of IT services.  These are the services that are critical for the welfare of the organization.  By entering into the process of Change Management, the effect of failed changes which would have caused a disruption to the IT service should be minimized.  Changes will always need to be made since the IT infrastructure cannot remain stagnant, so a process needs to be put into place to make changes in the least disruptive means possible. As the infrastructure grows change will be occurring at an increased pace.  Change management will help reduce the impact to critical services due to this increased volume of change.

What is Change Management?

First off, let’s define what Change Management is from an ITIL perspective. ITIL V3 defines the following types of changes in Service transition:

  • Standard – change to a service or infrastructure that is pre-authorized and has an accepted and established procedure to provide a specific change requirement
  • Normal – raised by a request from the initiator- individual or organizational group – that requires the change
  • Emergency – sometime required and 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. Details are often captured at a later date

This is how the 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 A/C maintenance, minor DevOps releases, or weekly server reboots. The activities required to implement the change are well known and proven to work properly. They can be entered manually or automatically from something like a DevOps tool
  • 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 the defined change management process including approval
  • Emergency – these changes are entered by the operations team in order to document a necessary change made 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 the appropriate procedures were followed.

All of these types of changes are critical to the all of the Service Management processes.  They all need to be entered into the ITSM tool and tracked.  For example, Service Operations needs to be able to relate incidents to changes that caused the incidents.  This allows Change Management to determine how successful the change was.

Normal Change types are the heart and soul of the change management process.   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 be in the minority in the ITSM tool but are not actively viewed except through a reporting tool.

A Normal type of change should go through the following sequence of events:

  • Define the change that is 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 develop of a solution to a problem, etc.
  • Test the change – this includes the back out plan in the unlikely event the change fails for some reason
  • Propose a scheduled start date/time for the change
  • Review by the Change Advisory Board (CAB) – the CAB should evaluate the change request
    • 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 agreed upon start date/time within the allotted change time window
  • Document the CI changes made in the CMDB
  • Review the change after completion to make sure it meets the expectations and the incidents caused by this change are within acceptable limits

These steps will need to be tweaked based upon organizational requirements but will provide a framework for a change management process.

Implementing Change Management

Where does one start when looking at this behemoth called change management? It can be very daunting at the beginning.  These steps should help get you started:

  • Identify someone in the organization to be the Change Manager
  • Design the change process. Things to think about:
    1. Plan how changes will flow through the organization. Many process flow documents exist that can be downloaded from the web. A particularly good site is http://wiki.en.it-processmaps.com/index.php/Change_Management
    2. Determine what changes will be standard changes and will receive pre-approval
    3. Will there be an Emergency change approval process?
    4. How will the post–mortem on emergency changes be handled?
    5. For failed normal changes, how will they be re-scheduled to assure a successful change?
    6. Don’t make the process a burden – 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 what Key Performance Indicators (KPIs) are the most important to the organization and then how they will be monitored
  • Communicate the process, the successes and KPIs throughout the entire organization
  • Monitor the change management process and improve (Continuous Service Improvement) where necessary to maintain and improve efficiencies

One consideration when starting the change management journey, is there a Configuration Management Database (CMDB) in place that has Configuration Items published in it? If not, consider creating a CMDB.  Be sure not to make the mistake of converting all of the defined Assets into Configurations Items.  Assets that are also Configuration Items should only be assets that are important enough to require active change management.  These should be business critical servers, network hardware, databases, backup servers, etc.  The CMDB should also include items like services the IT organization provides to the business that are critical to the organization.  This might be things like the online ordering system, email, organization web site, etc.  It should also include relationship information between the CIs.  For example, in order to provide the online order system service, it requires servers, network devices, databases, web services for credit card processing, etc.  These would be CI’s that are related to the service.

A CMDB provides the ability to track critical information for the CIs.  This can be used to detect unauthorized changes.  For example, if the version of the OS software on a server changed from what is documented in the CMDB without a change request – that would be an unauthorized change and should be investigated.

Key performance indicators and metrics for change management

Here are some key performance indicators for change management that might be interesting to track:

  • The number of changes implemented to services which met the customer’s agreed requirements, e.g. 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, poor or 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 (percentage of changes deemed successful at review/number of 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 estimate

Conclusion

Change is here to stay in the IT world.  Every IT department has some sort of change management processes in pace.  If they are currently informal, ad hoc type of processes the business will greatly benefit from implementing a more formal approach to managing the changes that are already occurring.

 

References:

ITIL – A guide to change management – ucisa