Classification of Emergency Changes

Discussion on issues related directly or largely to ITIL problem management.
Post Reply
User avatar
Nizmo
Itiler
Itiler
Posts: 5
Joined: Sun Oct 13, 2013 8:00 pm

Wed Dec 18, 2013 5:31 am

I am trying to classify the emergency changes that took place within this year to determine if these emergency changes could have been prevented. I have come up with just 3 classification names and was wandering if there is more areas that I could include in this list.

List:
Insufficient Testing
Insufficient Planning
Incorrectly logged as a ERFC


User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Wed Dec 18, 2013 10:12 am

Nizmo,

I can provide you the following values -

Requester cant plan
Requester wont plan
Requester's plan was not based on reality
Requester is a complete (incomplete) idiot
WTF ?

However, while that is humorous (to me at least), the list of values for E CABs and why they are happening needs to be based on the situation in your organisation.

Look at the ECAB, look at the reason given.. if there is one. If not, start requiring one.
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
Nizmo
Itiler
Itiler
Posts: 5
Joined: Sun Oct 13, 2013 8:00 pm

Wed Dec 18, 2013 10:23 am

LOL - hit the nail on the head, thanks for the reply. Most of them comes down to poor planning or just shouldn't be considered as an emergency.
User avatar
Nuno
Itiler
Itiler
Posts: 8
Joined: Tue Jan 08, 2008 7:00 pm
Location: Lisbon

Thu Dec 19, 2013 9:40 am

Hi,

One way to minimize the changes is to ask several questions to ours "customers" in a way they begin to think if that change is really necessary.
Some examples:

- Why change
- Describe present state
- Describe future state
- What will change
- What will not change
- Risks during change process
...

You can have many classifications depending of your business.
Some examples:
Hardware
Application Software
System Software
Network
...

or generic:
Low: this change may be best made alongside others, such as when updating software packages, buying new hardware, etc.
Normal: This change should be made provided it does not get in the way of another, higher priority, change.
High: a change that should be made without delay, as it is associated with known errors that are significantly degrading service quality. The CAB should assess this change at its next meeting and take the relevant measures to enable a rapid solution.
Urgent: this problem has to be solved as it is causing an interruption or serious degradation to service. An urgent change triggers the so-called emergency change process, which we will deal with separately.

Regards
Nuno
Nuno Mendes Fernandes
Release Management (IPRC, SS, SD, ST, SO)
Post Reply