For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
The Itil Community Forum: Forums
ITIL :: View topic - Emergency Change (The aftermath)
Posted: Fri Apr 01, 2011 3:16 pm Post subject: Emergency Change (The aftermath)
Hi all. I would like to get your thoughts on how an IT Group should handle an emergency change should be handled.
The emergency change that I am referring here is the change that needs to be implemented to continue with the IT Service (i.e. an incident has happened during a midnight batch run and upon diagnosis, the only way to resume the batch run is to apply a patch to resume the system) We are also assuming here that the emergency change has a go signal already.
so what do we do the next day? conduct PIR? re-test the change?
An emergenty change should go the same way as a standard change in tool. the only difference is the review and approval steps should get expedited. from review i mean pre implementation considerations to ensure the change will success in achieving its goal.
Obviously an E-change don't allow you to go in tool and wait till it processes and visits every corner, _________________ ------------------------------------------------------
ITIL V3 Certified --Intermediate level
Service Transition management.
Manage the change and change the management to an improvised tool
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Fri Apr 01, 2011 9:34 pm Post subject:
Tools should not even considered when doing a process
Tools are the last thing
What is the CM Policy in place.
It should define what are the actions for an Emergency Change
NOTE: Most Emergency changes are record retrospective -
This one is in response to an Incident so this should be dealt with both from a CM process as well as a IM process.
The SD mgr, the IM mgr, the application mgr, and the CM & RM Mgr should meet and dissect the decision making and the implementation as well as any consequences of the work
and ensure thatall documentation is up to date _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
we are still setting up our cm procedures here. I was thinking of creating some sort of emergency change evaluation form, where the "culprit" will be the one to fill it up. sort of a consequence of implementing a change.
(I know that emergency changes are inevitable, but I also dont want people raising up emergency changes just because its the faster way to implement a change. )
If I'm going with that direction, what should I put on the evaluation form?
It is a common practice wherein people want to hide their "poor planning" by pushing the IT team to implement changes as "emergency change".
You can define "qualifiers" for the "emergency change". Some example could be:
- Critical incident
- Regulatory change
- Corporate reputation/image etc.
Apart from other generic details, "Reason for the request" & "Reason for EMERGENCY (or why change couldn't be informed earlier)" - should be two fields in the evaluation form, that can be good area of interest.
Posted: Thu Apr 07, 2011 7:34 am Post subject: E-RFC implementation - One way of doing it
Sunny60in wrote:
It is a common practice wherein people want to hide their "poor planning" by pushing the IT team to implement changes as "emergency change".
You can define "qualifiers" for the "emergency change". Some example could be:
- Critical incident
- Regulatory change
- Corporate reputation/image etc.
Apart from other generic details, "Reason for the request" & "Reason for EMERGENCY (or why change couldn't be informed earlier)" - should be two fields in the evaluation form, that can be good area of interest.
I agree with Sunny's post where classifying the Emergency Change is critical to understanding how to handle it.
Earlier there was a post mentioning submitting a request for change after the "fix" was implemented to restore IT service. This is also a good practice since restoring service should always be paramount when considering the impact an incident has on a service. This is a good default way in responding. The next level up is identifying what can wait and what can't wait which is where a deeper understanding of the organization takes place.
The E-RFC process work a little more efficiently and effectively was introducing an integrated communication strategy where IM and CM and tools were considered during the design phase of delivering the Emergency Change procedure.
This was possible thanks to milestone initiatives listed below;
- Identifying, classifying, mapping CI's critical to the value chain of the organization. Which means meeting with a ton of people starting with the biz to understand the services they provide, then identifying the services they rely on as provided by IT then mapping those biz drivers and processes to IT services, then relating all infrastructure/application assets to those IT services then logging all that in a CMDB. The CMDB could be consolidated or distributed. There are strategic reasons for either but ours here is distributed for the wrong reasons... that's another story.
- Building a RASCI matrix and reviewing it with all stakeholders to get buy in. This took a lot longer than I though and is constantly referenced due to political disputes where someone is trying to pass the responsibility buck.
- Defining the requirements for emergency change process during core business hours vs after hours. You may not have to differentiate the approach during the day vs night if your corporate culture is a 24/7/365 and all participants listed on the RASCI are on call and local. Alternatives for us were:
1) Email notification and requests for ECAB review (Approve, Reject, Need More Info)
2) Quickly meet at a key approver's desk or grab a meeting room or dial into a conference line at a moments notice.
3) Restore service under IM pretenses then revisit the E-RFC process after the fact the next day during day time hours.
4) Mix of the above.
- Plan, design, build and deploy metrics into the process
- Report on those metrics consistently to the appropriate audience.
What helped me expand my horizons when working through this process was reading up on MOC, Management of Change where the people factor is discussed at great length. There's a lot of supporting material in this literature.
Other than that, Pink Elephant has a ton of free podcasts on iTunes which make a hell of a lot of sense and once again, have expanded my thoughts when working within the ITIL guidelines.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
