Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
· Home
· Content
· Feedback
· News
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: nathanandrews
New Today: 2
New Yesterday: 34
Overall: 231540

People Online:
Visitors: 103
Members: 1
Total: 104 .



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.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

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.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Acceptable Number Of Emergency RFCs?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Acceptable Number Of Emergency RFCs?

Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message

Joined: Aug 24, 2010
Posts: 5

PostPosted: Wed Aug 25, 2010 12:08 am    Post subject: Acceptable Number Of Emergency RFCs? Reply with quote

We all know that emergency/late notice RFCs are a bad thing and depending on your industry and environment will vary as a percentage of all changes, but generally speaking, is there a percentage figure above which alarm bells would start ringing? How high would your emergency change percentage figure have to go to cause alarm bells or OLA breach?

In a financial/nuclear environment the OLA may be no more than 2% to be emergency RFCs but in fast changing consumer led market a figure of 20% might be acceptable. Constant improvement should be drive down the number of emergency changes but eventually an acceptable figure will emerge. My environment has to be responsive to markets and business need and is somewhere between these 2 figures.

I'd be interested to understand how people have set their acceptable emergency RFCs thresholds.
Back to top
View user's profile
Senior Itiler

Joined: Oct 26, 2007
Posts: 295
Location: Calgary, Canada

PostPosted: Wed Aug 25, 2010 1:45 am    Post subject: Reply with quote

Hmm... it's a good question I think. First, though, I'd like to point out that there is a difference, at least there should be, between truly emergency and late notice RFCs. (you know, failure to plan on your part is not a problem of mine type of thing)

Anyway... I can share what we did with one company who used to struggle with a high volume of emergency changes. It was a long process because many other areas had to be involved, not just the change mngt process.

We looked at all the emergency change tickets for the previous 2 years to get an idea of frequency. With some investigative work we've figured out how much it has cost company to manage those emergency changes (overtime, off hours, equipment replacement, third party consulting, etc). The figure was fairly high. Through additional investigative work we have identified changes that were caused by poor training, improper execution of the procedures, circumventing process, etc... basically, all the preventable once. At this point we have arrived at a number that we started to use as a bench mark for the following year, with the improvements implemented in the trouble areas noted above. That gave us the breach number to at least monitor, but it should be reviewed every 6 months. I don't know how the company has progressed and whether they are holding up to that benchmark (no longer our client) but that's just an approach we took.

So to answer you question, I guess, it's probably hard to pick a number from somewhere because you wouldn't know whether it applies to your organization or not. Best is to do your own investigation and come to an agreed upon starting point and adjust from there on.

Hope this helps.
Back to top
View user's profile
Senior Itiler

Joined: Mar 04, 2008
Posts: 1894
Location: Helensburgh

PostPosted: Wed Aug 25, 2010 1:50 am    Post subject: Reply with quote

I would think that the acceptable figure would be at the point where the cost of reducing it outweighs the cost of tolerating it. I don't think dealing in percentages has any value here.

I don't fully understand the reference to OLA. Changes can come from a wide range of sources, many of whom will not be party to an OLA (e.g. customers, service management).

How does an OLA make meaningful commitments about emergency/late changes? Is it that your internal units don't raise change requests until after they have done the preparatory/development work. If so, then that is your issue: work done prior to change approval.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail

Joined: Sep 15, 2006
Posts: 22

PostPosted: Mon Oct 04, 2010 10:52 pm    Post subject: Reply with quote

I would suggest:

Define what you regard as a 'True' Emergency Change:

e.g. as a result of either Service Loss, Imminent Service Loss, Possible Service Loss, Unacceptable Service Degradation, Security Vulnerability.

Then measure the 'true' value of these over the last 12 months and work like hell to reduce it. I have seen forum posters saying 0% is the only acceptable level of Emergency Change but in my opinion this is not practical as you will always have CI failure, Security Advisories etc.

As a personal guide if you over 15% I'd worry and not sleep much, over 10% I'd worry, under 10% there is still room for improvement, under 5% keep trying to reduce it but it will get harder to do.

Urgent Changes i.e. those that are simply submitted too late by a PM (poor planning!) and because of project deadlines cannot wait until the next scheduled CAB should be dealt with in other ways. Hint: Senior Management. Twisted Evil
Back to top
View user's profile Send e-mail
Senior Itiler

Joined: Feb 26, 2009
Posts: 118
Location: Geneva

PostPosted: Tue Oct 05, 2010 1:10 am    Post subject: Reply with quote

Just to chip in:

Reviewing the emergency change with the requestor's management has proven very successful, when done with the correct approach, as they ofter have knowledge about the change / service etc that we do not.
Back to top
View user's profile

Joined: Aug 24, 2010
Posts: 5

PostPosted: Wed Oct 13, 2010 6:55 pm    Post subject: Reply with quote

Thanks for all your comments, it's always assuring to see that other people's views are not too far away from your own.
On a slightly different point when producing statitics, do you include standard (routine or pre-approved) changes when calculating the emergency percentage figure?
For example if you perform 100 changes a week, 30 standard, 5 emergency and 65 normal (via CABs) would the emergency figure be 5%(5 out of 100) or 7.1% (5 out of 70)?
I suppose to some degree it depends what you want your figures to show.
Back to top
View user's profile
Senior Itiler

Joined: Sep 16, 2006
Posts: 3597
Location: London, UK

PostPosted: Wed Oct 13, 2010 7:46 pm    Post subject: Reply with quote


The default answer from the Forum is

It depends

you did answer the question

It actually depends on how you want to report the data

Personally, I would break up the Emergency Changes by areas and show them against the grand total of changes for that area

For example

You are dealing with a specific application - Peoplesoft - for one
In a month, you have 200 changes - 120 are data fixes, 80 are code fixes
of the 120 d/f, 10 are emergency d/f while of the 80 2 are emergency changes

what does that tell you as a CM.. not much directly but you can infer that the education for the data input users is weak or the instructions are not clear as there are way to many d/f to correct data.
I can also infer that the code for this particular application is retty mature - ie all of the bugs worked out

If I had a chart for the application that showed the number of code fixes - both non and emergency increase after a new release and then drop off slowly, then I can infer that the testing of the new version is poor
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management All times are GMT + 10 Hours
Page 1 of 1

Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003

Forums ©


Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.