Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: ErvinLeffz
New Today: 62
New Yesterday: 73
Overall: 150112

People Online:
Visitors: 46
Members: 1
Total: 47 .

Languages
Select Interface Language:


Major ITIL Portals
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

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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)
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Emergency Change (The aftermath)

 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
janilo
Newbie
Newbie


Joined: Feb 23, 2011
Posts: 2

PostPosted: Fri Apr 01, 2011 3:16 pm    Post subject: Emergency Change (The aftermath) Reply with quote

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?

Thanks in advance. Smile
Back to top
View user's profile
sumituprit
Newbie
Newbie


Joined: Jun 28, 2010
Posts: 9

PostPosted: Fri Apr 01, 2011 8:27 pm    Post subject: Reply with quote

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
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3321
Location: London, UK

PostPosted: Fri Apr 01, 2011 9:34 pm    Post subject: Reply with quote

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
Back to top
View user's profile
janilo
Newbie
Newbie


Joined: Feb 23, 2011
Posts: 2

PostPosted: Wed Apr 06, 2011 3:28 pm    Post subject: Reply with quote

Thanks for the inputs John.

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?

Thanks
Back to top
View user's profile
Sunny60in
Newbie
Newbie


Joined: Jul 09, 2009
Posts: 15

PostPosted: Thu Apr 07, 2011 5:05 am    Post subject: Reply with quote

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.
Back to top
View user's profile
TomG
Newbie
Newbie


Joined: Apr 06, 2011
Posts: 3

PostPosted: Thu Apr 07, 2011 7:34 am    Post subject: E-RFC implementation - One way of doing it Reply with quote

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.

Hope this helps. It has for me.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.