Change Management Scope and Cost Justification

This is a follow-up to Monday’s post about Change Management.

Scope

First of all, I’m going to discuss the typical scope of Change Management (CM) – the types of things that might be subject to a formal Change Management process. This might include Configuration Items such as:

  • Computer hardware, such as server and desktops
  • Operating systems and other server software such as database servers
  • Routers, bridges, hubs and other types of network infrastructure
  • Documentation, both internal documentation (how to restart your CRM system for example) and end-user documentation (such as user guides and training materials)
  • Application software

Recall I mentioned in the previous post that Configuration Management and Change Management are linked? Each supports the other, but there is also a relationship in content as well. If asked what types of thing should be put into the CMDB, I usually reply ‘Items that should be subject to Change Management’. It works the other way as well – ‘All of the Items in the CMDB should be subject to CM’.

There is one other useful concept of scope – production and development. Things that are in development are, of necessity, not subject to the same control as Items that are in production (and therefore have users). If you consider these kind of development Items are subject to project Change Management -–in effect, subject you your project management disciplines before going into production.

Cost/Benefits Justifications

It can be difficult to produce objective cost and benefits analysis for Change Management (no different really from many other ITSM disciplines). The reasons are obvious – it’s impossible to quantify the value of improvements you might identify in the future, or the costs of Incidents you’ll avoid. One thing you can be sure of is you’ll pick-up additional costs as you develop a CM process, create a Change Manager role, create a Change Advisory Board (CAB), and so on.

If you are asked to justify costs, here’s an approach you can take.

First of all, set some benchmarks for the costs of introducing Change Management – in much the same way you’d cost any other project. Estimate the number of hours that will be spent, assign typical hourly costs, apply any capital expenditure, and produce a cost estimate for establishing Change Management over something like a 2 month period. I’d limit myself to the costs of getting to the point where we have a CM process for the simple reason that those costs are more easily identifiable, and that the ‘running’ costs are likely to be moderate.

Next, examine your Incident records for Incidents that have been caused by Changes that have been executed incorrectly in some way – something I’m aware that might be somewhat easier to write about and describe than it is to do. Ideally you’ll have been flagging these at the point of resolution for some time, so the ‘set’ of Incidents you’ll work with is easy to come to.

For these Incidents, estimate a very rough cost. You can do this by using downtime as a guide, and looking at one of my previous posts about the costs of unavailability.

What you can then do is compare the costs of the problem with the costs of the cure. I’ve seen someone try to quantify (in monetary terms) the value of future improvements but have never supported this approach as you may as well use a random number generator – it’s not objective in any way.

I’ll continue these posts later - either this week or next.

Tags: 

Categories: