Infrastructure management is undergoing a transformation. ITIL can help manage conflicting demands like – “low cost but high service quality”, “ubiquitous access but enhanced security”?

« Musings on Change Management Metrics - Part 1 | Main | Your word versus mine »

Musings on Change Management Metrics - Part 2

In my earlier blog on Change Management metrics, I wrote about how several organizations use total number of Changes as a measure of the success of their Change Management process. Here, I would like to share with you some practices I have found useful in deciding what type of metrics to measure.

But again, be ready to answer more questions! Consider these for starters:

  • What level of process maturity are you at? If your Change Management is just taking off, consider more process measures and workload measures i.e. start by measuring activities. Do changes have back-out plans? Have they been tested? What is the break-up of the type of changes? And such metrics.
  • As your Change Management process matures, move towards more business-outcome / output measures or what I like to call "nirvana metrics". My personal favourite is the reduction in dollar (or whatever currency you use) impact of changes. Nothing more persuasive than showing the linkage to $. But continue to include measures from all three categories recommended by ITIL V3 - outcome, workload and process metrics.
  • And despite all this, what do you do if your leadership still insists on reviewing the total number of changes and using that as the basis for judging how well the process works? Well, here's one option - not a perfect solution but something that I have seen work well. While reporting on number of changes, break it down by:
    • Standard Changes as a % of the total number of changes - the higher this %, the better. Why? Standard Changes are pre-approved or perceived to be relatively safer changes whose impact is understood and approved. So, more the number of such changes, higher the chances of being able to understand impacts. And more importantly, build in a mechanism of progressing "routine" changes to standard changes. An easy pitfall is defining a bunch of standard changes at the outset while building out the Change process, but not reviewing these over time.
    • Emergency Changes as a % of the total number of changes - Monitor these very closely. If you can show a drop in your Emergency Changes, you have a very good chance of keeping your environment safe. I recently came across a report from Forrester (you may need a Forrester login to access this report) that suggests that the average percentage of changes that are emergency changes varies between 12% and 18% for most IT organizations. That's a good target to start with.

Is that it?

So, is this a comprehensive list of best practices for measuring your Change Management process? There's a lot more ...

Additionally, over the last year or so - Rohit Nand, a fellow blogger on this site, and I have developed a simple framework to help IT Service Management (ITSM) programs structure the way they measure and report. I am convinced that a structured approach to measuring and reporting is the backbone of any successful ITSM program. Keep a look out for that one ...

Meanwhile, what type of metrics do you measure? And what success are you having with your current measurements and reporting mechanism?

TrackBack

TrackBack URL for this entry:
http://www.infosysblogs.com/ITSM-service-matters-mt/mt-tb.fcgi/15

Comments

Excellent points Arvind. Would also like to know more on - recommended set of processes or best practices for covering the different activities that would be involved for making changes to an enterprise service.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)