Change Management - Defining the Process

This is another in my series of Change Management posts. The last one is here.

If you are trying to get your Change Management (CM) process ‘kick started’ you’ll probably be looking for help on getting started.

As always, if you are introducing a new ITSM process you’ll need a process owner – someone who has responsibility for the process itself, and its efficient running. This usually means a Change Manager. Having made your appointment, he or she will help to produce the basic steps in your CM process.

If you are sitting down to create a Change Management process for the first time, the best advice I can give you is to keep it simple. There seems to be something about flow charts that has an intoxicating effect on some people, to the extend that the basic Change Management process is a labyrinthine complex of twists, turns, loops and special cases. If this is what you’ve created I’d advise you to visit it again.

I’d expect to see some or all of the following

  • Initial analysis and filtering
  • Business case
  • Allocation of Priority and Initial Assessment
  • Creation of Impact Assessment, Back-out plans & Resource Estimates
  • Submission to Change Advisory Board (CAB) for authorisation, approval and comment. This is something I’m going to discuss in later posts.
  • Test Build or Implementation
  • Live Build or Implementation
  • Review
  • Update CMDB

Let’s take a look at some of these in more detail.

Creation of Impact Assessment, Back-out plans & Resource Estimates

This is a very valuable stage in any CM process. You simply examine the Change to see which services we offer to customers will be affected, or could be affected – in many cases you’ll be concerned with risk. The Back-Out plan is related to this – if things go horribly wrong, or at least don't behave as we expect, how can we roll-back or undo the Change quickly? It’s worth considering this early-on because it usually affects the things that technicians have to do prior to the Change.

In some organisations, I’ve seen these things produced during the CAB meeting. My personal preference is for as much as is possible to be produced prior to the CAB meeting for the simple reason it makes the meetings easier to chair, quicker, and less subject to diversions. You’ll certainly need this information during the CAB meeting however.

Business case

For Changes that are simply to make business improvement, you need a summary of the improvement you hope to make, along with any cost savings. If the Change is a response to one or more Incidents or Problems, you need information on the business effect (and ideally costs) of these.

Test Build

Some organisations (though by no means a majority) maintain Test Infrastructure – usually grouped together in a Test Server Room. This is where a copy, or mirror image, of live infrastructure and systems are kept – for the sole purpose of testing Changes before promotion to live systems. Although this is off my main subject, both enterprise level and desktop Changes can be handled in this way.

If you don’t have such a facility, it might still be possible (and is usually something worth doing) to perform testing on a platform specially created for the Change. In some organisations, depending on the nature of the Change, this takes the form of User Acceptance Testing.