Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
The Itil Community Forum: Forums
ITIL :: View topic - Acceptable Level of Exceptions, Rollbacks, etc.
Posted: Fri Sep 21, 2007 3:20 am Post subject: Acceptable Level of Exceptions, Rollbacks, etc.
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.
Joined: Feb 28, 2006 Posts: 411 Location: Coventry, England
Posted: Fri Sep 21, 2007 5:07 pm Post subject:
Hi EJ
our 'problem' changes tend to run at 2.4 - 4% so very similar to you, and our 'Emergency Changes run at about 10%.
Our process skews this stat on the high side because we reclassify 'Late Changes' as Emergency - This is due to the stress they place on the CM system - We encourage our techies to resist rushing in changes at the last minute because the PM group have poor planning - In reality the changes go in, but we give them a hard time!!!
When we were ignoring Standard Changes in our stats, the ratio of Basic to Emergency was about 4 - 1
Posted: Fri Jan 04, 2008 10:18 pm Post subject: Re: Acceptable Level of Exceptions, Rollbacks, etc.
ejdulcimer wrote:
Exceptions are RFC's requiring rollbacks, successfully implemented with issues, etc.
First of all I'd say that "implemented with issues" is Failed, but I am a harsh man!!
Based on many client conversations, Forrester believe that;
The average percentage of Emergency change is in the range of 12% - 18%.
The average percentage of Failed change is in the range of 5% - 9%.
However, for ‘World Class’ they advocate;
Keep the percentage of emergency change requests to less than 10%.
If the percentage of emergency changes is more than 10%, the operations/application development staff is making a mockery of the change control process. Require higher-level sign-off for emergency changes, and/or make the review process more painful.
Keep the percentage of failed change requests to less than 3%.
If more than 5% of changes are unsuccessful, your testing, quality assurance, and change control processes are ineffective and need to be revisited.
My organsiation is achieving <3% Failed, <1% Emergency, <12% Fault, and <5% Short Notice.
from experience I would side with the figures quoted by "Skinnera" and look to be "Best in Calss / World Class" with sub 10% Emergency Changes. You should fid this may have a positive effect on decreasing problem records too as a result of rushed / emergency changes. _________________ Mark O'Loughlin
ITSM / ITIL Consultant
Posted: Tue Jan 08, 2008 12:00 am Post subject: Re: Acceptable Level of Exceptions, Rollbacks, etc.
Skinnera wrote:
Keep the percentage of emergency change requests to less than 10%.
If the percentage of emergency changes is more than 10%, the operations/application development staff is making a mockery of the change control process. Require higher-level sign-off for emergency changes, and/or make the review process more painful.
My organsiation is achieving <3% Failed, <1% Emergency, <12% Fault, and <5% Short Notice.
18 months ago we were running at >15% Emergency Changes, which upon investigation was all about a misunderstanding in the field about what our definition of Emergency was (it's to prevent an imminent service impact or faliure).
In effect, the support teams thought that if it was 'urgent' to them, it was an emergency, and my team weren't challenging back when they were raised.
At the same time, we had >15% Short Notice Changes (normal, planned work that ddn't give our required lead time), and we addressed that by doing exactly what Forrester say in the last line above - we made it painful to get them authorised.
Every time a Short Notice Change was raised we referred the requestor to one of the 3 Technology Directors to gain their approval for it breaching the notice period (as opposed to technical sign off).
You'd be amazed (or not!) how many 'urgent, must do it NOW!' changes can actually wait if you have to go to a director and explain your bad planning...
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
