Introducing Change Management - Some Definitions

This is going to be the first in a series of posts about Change Management. I’m going to be writing for those that currently have either no Change Management process, or those that do but feel they could do things better. I’ll also be branching off from time to time to look at different aspects of the Serio tool.

Changes come about as ‘outputs’ from Incident Management or Problem Management – or quite often simply because we want to make improvements in our IT infrastructure to better serve the business.

Purpose of Change Management

The purpose of Change Management is:

  • to minimise the impact of Incidents upon the business that might occur through Change implementation
  • to have a standard, effective, repeatable way of assessing and managing the implementation of Changes to IT services and infrastructure
  • to seek business benefit and improvement

Your Change process will (most likely) have some of or all of the following:

  • an assessment of risk
  • an impact assessment
  • communication with business stakeholders and/or user communities
  • assessment of resource requirements
  • cost and benefit analysis
  • business opportunity assessment

Change Management and Configuration Management

I’ve blogged a lot about Configuration Management and the Configuration Management Data Base CMDB (search the blog for CMDB and you’ll find them). The two processes are linked. It’s something that I’ll probably come back to in more detail in later posts but if you consider for a moment something like an impact assessment, you need to ask yourself how you can do that without the level of detail and documentation that a CMDB provides. For instance, without a CMDB you may simply need to ask someone (usually a tech guru) about impact – but where does your tech guru get his information?

So, if you are thinking about implementing a Change Management process, you might also find you need to consider a Configuration Management process as well.

Prime Movers for a Change Management Process

My experience with customers has tended to show that the main driver for more formal procedures is a feeling that Changes cause too many Incidents – in other words, Changes are not planned carefully enough, tested enough, and are implemented too quickly.

It is a shame that this is a key driver because it makes it is easy to overlook Change as a vehicle for delivering business benefits, something I usually try to advise customers to ‘build-in’ to their process by having specific (usually small) focus groups that have as part of their remit to be outward looking and to be agents of innovation.

My next post will look at what should be covered by Change Management, and cost benefits/justification.