Something other than Emergency

[RitaV]

We do not use Emergency Changes as stated in ITIL. We use it to report on changes to systems as a result of a business impacting outage (incident).

We use Expedites for last minute things to be schedule the same evening or in 3 hours. They go through the same approval flow as a normal change. At my previous employer, we did the same thing. They called them Critical changes.

How many of you use a fourth change type in your environment? How do distinguish between an Emergency and something that is just urgent to business.

[UKVIKING]

ITIL while it provides examples of type of classification is not restrictive

I used in one company 4 values

Emergency, Immediate, Normal and Standard

another , 3 - emergency, normal and standard

It all depends on how you classify them

When i did the 4, the difference was Emergency was fault oriented ie changes to restore service while Immediate were fixes that had to be progress quicker than the CAB cycle.

Some would call it emergencies but i separated these as there were way too many of the immediates as emergency - which some times came down to bad planning or poor planning
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Diarmid]

The categories are a convenience. Each must be very clearly defined as to its scope and applicability, but whether you have none (i.e. everything is just "change") or ten is a practical issue for managing work.

Less than two is probably difficult to manage in all but the smallest of organizations with relatively simple service provision, and after three or four, it begins to get too complex for effective management in all but the most disciplined of organizations (and even in them!).

As John said, ITIL provides no more than a practical suggestion, not a rule.
_________________
"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

[JAL]

Taking the view of Gartner we have implemented and split our MI as follows:

Normal
Standard
Emergency (Split, Proactive, Reactive and Non-Compliant)
Proactive - Change required ASAP to resolve an immient service risk/issue
Reactive - Normally under the guise of Incident Management and are generally raised retrospectivley
Non-Compliant - Changes which have valid justification / business case but cannot adhere to the stated Lead Times.

I must be clear that any change can be classified as an Emergency (STD or Normal), and this is not specific to a Change Process (i.e the flow of an RFC)

The Emegency 'Tag' if you like is flagged on the RFC within the worklflow tool itself and is therefore picked up on MI.

*Not to be confused with the Emrgency Change Process (POLICY)

[bennyp78]

I'm really interested to hear about how your processes build in a deterrent to just using the the immediate or non-compliant category of changes as an excuse for not planning properly. We have just Emergency, Normal and Standard changes.

We're in the middle of the biggest project our IT dept has ever embarked on. Delivery deadlines are aggressive to say the least and Snr Executives reputations are at stake. In a project this size the volume of changes are large and there's regular occurrences of the "failure to plan". Ordinarily I would just take a hard line and say "too bad, be better at planning next time". With so much at stake in this case that's just not possible. Clearly I have to consider an Immediate or Non-Complaint option but surely there has to be some kind of pain or consequences for the project manager that failed to plan? Without consequence I feel like the message being sent is "you have to plan changes effectively... unless you don't want to in which case I'll call an emergency CAB for you anyway..."

I'm not getting a lot of support in this area so understanding what happens in other organisations would really help me form ideas on what to propose to my manager.

Thanks in advance

[Diarmid]

Lack of planning increases risk.

Risk of change failure.
Risk of excessive costs (financial and resources).
Risk of disruption to other services.
Risk of change being implemented but not delivering what it was for.

Instead of being defensive about procedure, simply force the project to sign up to the risks (at the highest level) and then do what they want. Also report to the business that, for the duration of the project, all services are more at risk than usual and ask what is acceptable to them, and what they are prepared to pay to manage these risks.
_________________
"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

[ReleaseLeeds]

Personally I've introduced the concept of fast-track changes to manage changes that although are not critical to fixing high impact severity incidents are deemed urgent to the business.

I describe fast-track these as 'client critical' (the client decides if it's critical) rather than 'service critical' I define that these can observe a shorter release lifecycle to go life (therefore cut down but targetted system/user acceptance testing so represents more risk)

I separate these out from standard releases so that the number of emergency, and fast-track releases can be measured through KPIs, an improvement in Release Management can therefore be measured through a reduction in these types of changes.