Acceptable Level of Exceptions, Rollbacks, etc.

[ejdulcimer]

Good day everyone! We have a somewhat mature Change Management process in place and our CAB looks weekly at RFC's reporting exceptions. In the last 3 months, we've implemented ~500 RFC's and 15 have reported exceptions. Exceptions are RFC's requiring rollbacks, successfully implemented with issues, etc.

What I would like to find out is what other organizations feel about an acceptable level of exceptions. I don't believe there's anything in the ITIL literature about that....I could be wrong.....but I can't recall any specific numbers. The only figure I ever saw was a goal of 5% or less for emergency RFC's.

And while we're at it, what do you find is your percentage of Emergency RFC's? We see on average about 20% of submitted RFC's classed as Emergency. This is probably way up there by comparison to other organizations......but I'd like to get a feel for what your organization is finding out in this area.

Thanks in advance for all your responses!

[itsm_stephen]

I was just at the annual ITSMF USA conference in Charlotte where I also attended a class on ISO 20000 and we actually did talk about (at one of the sessions as well as in the ISO 20000 class) about the Change Management process.

In general, what I got out of the session and class was that there is no 'defined' percentage to meet there is really only the concern that you have a defined policy (and procedures, roles, training..etc) to 'deal' with Change and roll backs and have a PIR.

Also, I have heard that the best way to conduct a PIR is not in the theme of a "throat to choke" (ie, who made the mistake and why!) but more in the theme of what can we learn about our process, about our environment because of this failed change. You need to consistently look for ways to improve your quality to the business at an agreed upon cost to the business.

And that last part is key. What is an agreed upon cost in your business may not be in mine - which means our targets can be, and probably should be, different. How we go about meeting those targets however are probably not so different (hence the 'good practices' of ITIL and the standard of ISO).

My company however actually does not conduct PIR's at all and does not really track the number of successful to failed changes or emergency changes for any particular purpose. They are tracked (somewhat) but again, for no real purpose.

We do not have an ITSM program here. Sadly...



But I have a questions for you!!!!!!

You do have an ITSM program (or at least a strong Change Management program, and I am going to assume a decent Configuration Management program) - did you (your company) take a baseline before implementing your Change/Config programs? Did you figure in any costs to how much it was costing you to have 'poor' Change/Config programs? Did you track how much you have spent on getting your Change/Config programs to the level at which they are at now? Do you know if it was 'worth' it? Can you provide evidence ROI? Did you track everything from new positions (Change Manager? SLA Manager?), training (ITIL, or in house on the new/improved processes), to technology (new Change or Config software) to even time (meeting minutes spent at the CAB and PIR?) spent going through the process and time spent auditing the process (you do audit right? How do you know people are 'following' the process properly?)?

If you have any (or even better all) of that type of information that would be great. The problem I have is that my company does not want to institute a ITSM program until I can have clear proof of ROI in the expenditure. And it cannot be theoretical, so the marketing crap will not suffice.

Anyway, hopefully my answer was at least somewhat helpful and I look forward to your response.

Thanks,

Stephen