How to reduce the number of emergency changes

By ITIL® from Experience©

In some organizations, emergency changes1 are routine. People are so busy handling these so called emergencies that they have no time to plan. This lack of planning often causes more emergency Request For Change (RFC) to be raised. An endless cycle.

The following are suggestions to reduce the number of emergency or urgent changes.

1. Write a definition of what is a true emergency change for the organization. Have this definition approved by senior IT management and the CIO (see What does it mean to have CIO and management support).
2. Prepare a checklist of specific criterion that must be met for an RFC to be classified as an emergency change. Make this checklist available for people to self-assess their change before submitting an RFC. Some of the ideas below can be part of that checklist.
3. Have people complete a one page form to justify the need for this emergency change (i.e. business case).
4. Develop and use a change priority matrix. ITIL® Service Transition provides an example of Change Priorities in Table 4.6 (2007 and 2011 Edition).
5. Have and enforce policies such as:
   • Emergency changes will be considered if it prevents a release from being deployed.
   • An Emergency change can only be used to fix incidents and not service requests (see Does an emergency change need an incident).
   • Emergency changes are only allowed to resolve an outage, a serious disruption or a Major Incident.
6. Review the normal Change Management process to see if its procedure or policies could be causing emergency changes. For example, one organization had a policy that stated that all RFCs had to be submitted to the Change Manager two weeks prior to the Change Advisory Board (CAB) meeting (i.e. “lead time”). As a result people were raising emergency changes to address business needs and operational issues that could not wait fourteen days for an approval.
7. Get people into the habit of logging the RFC in the ITSM tool as soon as they know that a change is required. Even though it may not yet be ready for approval as some details are still unknown, early visibility of a change helps prevent last minute surprises.
8. Implement or increase the number of standard changes (see How to implement Standard Changes).
9. Develop a quarterly schedule of upcoming deployments, releases and changes. In itself, it will not reduce the number of emergencies. However, this will trigger people to look at the next three months which may entice them to plan and do some work before the last minute.
10. As a last resort, have each emergency RFC approved by the CIO (see Do we need CIO support to succeed). People will be reluctant to expose their lack of planning or failure to prevent an emergency change.

Finally, do not forget to communicate these process modifications to people (see We need a simple Communication Plan that will be actioned).

Last updated on: 2015-10-28

Related:

• What level should the Change Manager position be to have the authority to reject RFCs
• Is a server reboot a change
• Should a Problem be opened for every Major Incident
• How to reduce the number of incidents caused by user training
• How does it work when an incident requires a change
• How to continuously improve the ITIL Change Management Process

More Change Management Answers

From Around the Web:

• Emergency Change Control measures

Category: ITIL Process > Change Management

Disclaimer

Copyright 2014-2015 - ITIL® from Experience© - D.Matte