Emergency or not - Change Requests

#itil4 #changemanagment

Some concepts have changed between ITIL V3 and ITIL 4. However, the definition of a change remains the same- a change is ‘the addition, modification, or removal of anything that could have an effect on IT services. changes are needed in any situation, right from the regular Operations and Maintenance activities to making a change due to legal compliances to reacting to a real-world catastrophe. As suggested in ITIL, a change request, the formal communication or record which seeks a change to one or more configuration items, can be of three types – standard, normal, and Emergency. An Emergency change is a change that must be introduced or implemented as soon as possible. Quite often, Emergency changes will arise because of the need to resolve major incidents. By nature, Emergency changes also carry the highest amount of risk as the team might not have enough time to test the solution effectively. Every service delivery manager will tell you instances of incidents arising out of implementing Emergency changes. Hence when a change Manager is dealing with the approval of an Emergency change, an important question that needs to be satisfactorily answered is the benefits of implementing the proposed solution as soon as possible vs waiting for the next release window to implement the change.

Of course, different organisations may have slightly different ways of interpreting the definition and activities related to an Emergency change – some might want the change requestor to raise the Emergency change request a few hours before implementing the solution and have an Emergency change Advisory Board approval in place while other organisations might be okay with the change Requestor raising the Emergency change request a few hours after the solution has been implemented successfully. Based on my experience and observations, I believe that the Emergency change Request should be raised before implementation and a minimal set of approvals should be there where the risks are understood and signed off by the Application Owner and Business Owner along with the Service Delivery Manager; afterall ECAB is not mentioned in ITIL4 Practice document

The other point that I have to mention concerning Emergency changes is how many Emergency change Requests can you raise as a team or platform. While ITIL is always suggestive, there is no clear guidance on the ratio of Emergency changes with respect to overall changes in a quarter or month. Based on my observations, I usually suggest having the ratio in single digits i.e. less than 10%. You have to keep in mind that a high number of Emergency changes might be because of the following factors:

-?????????Incorrect definition of an Emergency change request

-?????????changes being submitted as Emergency only because the change requestor did not have enough Lead time left to submit on time

-?????????An application is witnessing a higher number of outages during a peak period

A few tips to keep in mind regarding Emergency changes:

-?????????Question the change’s Emergency status as a change Manager or change Authority. Understand the actual impact on the business if the change is not implemented. You might also want to have business as well as IT input to this question

-?????????Has the solution been implemented before i.e. restarting a server when infrastructure levels breach a certain baseline? If the solution has been implemented before, this reduces the overall risk of the change being implemented and there is a substantially lesser chance of an incident arising out of implementing the Emergency change

-?????????Clear activities, roles and responsibilities should be defined on how to handle an Emergency change. When such a change is raised, time is of the essence and no time should be wasted in trying to figure out who should do what after the RFC has been raised

And to end on a lighter note, an increase in Emergency changes also means spending precious hours on a weekend during your weekly offs. That itself should serve as an incentive for a lot of Service Management teams to avoid Emergency changes as much as possible.

Let me know your experiences with handling Emergency changes.