We are in the process of creating our corporate wide change control process. One of the issues we are having is how to represent the emergency change process in our flow diagrams or if we need to show it. In our documentation we talk about an emergency change, what it is and how it is to be handled, but there is no defined flow it needs to go through. Basically we say an emergency change should try to follow a normal change as much as possible but they have the leeway to skip steps to resolve the issue quickly but then need to go back to complete the steps after the fact. Right now we do not have anything specific to an emergency change in our flow diagram which is causing issues with some people because they are expecting to see a flow for emergency changes.

What have your experience been? Do you have a flow diagram for emergency changes or do you just describe an emergency change, the leeway in completing the change and some of the rules they need to follow? If you do have a flow diagram for emergency changes, how different is it then your normal change?

I have a separate flow.
What you need is for people to know what an emergency change is (policy) and how it should be handled (process, work instruction etc)_________________DYbeach
ITIL V3 Release, Control & Validation,
ITIL V3 Operation SUpport & Analysis
PMI CAPM (R)

"In times of universal deceit, telling the truth will be a revolutionary act." George Orwell

If you don't have a formal process for emergency change, then you cannot control the quality of what happens under "emergency change".

Even if all the boxes were identical except for the added box to validate the emergency decision (and they won't be), there is benefit in separately documenting and following it as a specific process. Incorporating it all in one flow with lots of "is it an emergency?" decision boxes, may be logically possible, but it won't be easy to use. And easy to use is the other key (after maintaining control of quality).

The vital component in emergency change is risk. What is acceptable risk from not testing/validating/analysing/waiting for a specialist/etc at any point? Who authorizes this level of risk on this occasion?_________________"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

CMizikar - We have been in a similar state in that we mention it in our overall governance documentation however did not have a separate process/flow for it. Due to some recent issues within our global organization we are now circling back and creating unique documentation pertaining to Emergency changes and the supporting processes.

In hindsight, it should have been in place all along however the prior regime did not see the value in it all.

a change to restore an existing service from a service impacting incident
(major incident0
a change to close security vulnerabilities
a change for reasons to protect the reputation of the business (legal, etc)

and i have what is not an emergency

any work for any service that is NOT defined as in production and/or providing service_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

What about timing? A change that has to be implemented before the next CAB?
Change Manager has to be vigilant, though, for the inevitable "Dodgy Brothers CBF to raise one in time" category.
Genuine instances to occur from time to time, you just have to be alert for the Can Of Worms_________________DYbeach
ITIL V3 Release, Control & Validation,
ITIL V3 Operation SUpport & Analysis
PMI CAPM (R)

"In times of universal deceit, telling the truth will be a revolutionary act." George Orwell

I need to understand one aspect of Emergency change ..
Can an Emergency change be carried out without logging a change request (RFC) OR irrespective of the Impact/Urgency the change needs to be logged and approved before being carried out

The issue with the first option would be that most of the changes would not be logged since the situation is under control.

In the second case approvals could act as bottle necks for implementation.

I strongly believe that you need formal, as in auditable approval before any changes are performed.
Is a verbal approval auditable?
Nope
Do people 'forget' what they have said as opposed to what they have signed off on?
You bet your sweet bippy_________________DYbeach
ITIL V3 Release, Control & Validation,
ITIL V3 Operation SUpport & Analysis
PMI CAPM (R)

"In times of universal deceit, telling the truth will be a revolutionary act." George Orwell

For "lack of planning on somone's part"--sometimes the customer, sometimes us--we have Expedited changes.

Our Emergency change process and requirements are similar to John's. In this world where every manager has a blackberry, verbal approvals are followed up by an email blast._________________Ruth Mason
USA