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: EP45
New Today: 45
New Yesterday: 97
Overall: 142117

People Online:
Visitors: 50
Members: 1
Total: 51 .

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

About Emergency Change?

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


Joined: Oct 19, 2009
Posts: 9

PostPosted: Tue Jan 26, 2010 5:50 pm    Post subject: About Emergency Change? Reply with quote

Hi there,

Regarding the Emergency Change, my understanding is that it is an unplanned change which need to take immediate action to fix an identified problem. It is Emergency or not is very depend on the service impact or number of users affected. However, a different opinion is that Emergency of a change is depend on the CI, which means when u define a CI as a critical CI, if it is got problem say hardware issue, then its aligned change would be Emergency Change, another word, the Emergency of a change is aligned to the CI defined, which I think it is not correct. Since if i define a CI is critical say a server for a major biz site, if this server is down during the weekend which means not so many users are accessing it and need to change to another spare server, impact is not big, I don't think it would be an Emgergency Change...

Plz correct me if my consideration is incorrect, thanks.
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Tue Jan 26, 2010 6:33 pm    Post subject: Reply with quote

davidlet,

an emergency change is not unplanned, it simply requires very rapid planning and is willing to take more risk at that stage than would be normal because there is greater loss/risk in not attempting it.

Whoever your process authorises to perform emergency change, whatever consultation and notification processes you still require, making the change will still involve working out what to do and when and will make as much consideration as possible to the consequences to all services, and will do as much as it can to ensure regression is not only possible but practical.

As to aligning the decision to a CI because it is considered critical. I see how the concept may come about. Someone, being helpful and knowledgeable and experienced says "for example if a critical CI is down, then you may need to conduct an emergency change." And someone, lacking in experience and understanding and desperate for guiding rules (or just plain not listening) thinks "Ah! emergency changes are for when critical CIs fail." Et viola!

There is no formal link from critical CI to invoking emergency change. You are correct in maintaining that impact and risk and time are the critical factors. A failure in a critical CI may be suggestive and should surely prompt you to investigate further very rapidly. But that is all.
_________________
"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
Back to top
View user's profile Send e-mail
UKVIKING
Senior Itiler


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

PostPosted: Tue Jan 26, 2010 6:46 pm    Post subject: Reply with quote

ITIL says basically an emergency changes are those changes that are necessary to resolve an outstanding incident. This means that the E-CR is in support of the IM processs

Having said that, the actual answer is ......

it depends

The reason for that answer is that the following needs to be done

1 - the CM policy must clarify the defintions of the emergency change and what is its scope
2 - the IM policy should also refer to it
3 - the CM & IM process and procedures must do the required process flows and linkage for E-CR etc

Now, a E-CR still goes through the change request manageemnt workflow; however, this usually retrospective
Also a true E-CR usually can not be tested - but that reallly depends on the underlying environment that the e-cr is for

Also, the big conditiion is the service impacted.

If payroll is done on the 15th and 30th, and the application suffers a fault - before the checks are run on the 15th, then it is an emergency fix/change that is needed, but if the run had already happened and it is the 16th, then the solution is still URGENT but not CRITICAL

It is the Service that is being impacted by the incident and the degree of impact that should guide the use of emergency changes

This, as I have already said, should be defined in the CM Policy document

As to the way I do it, I classify emergency changes in 3 distinct way

production outage to critical systems - note production {projects are never emergency changes because the project is not live}
security vulnerabilities
financial impact (severe) or loss of business reputation (critical for companies)
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
davidlet
Newbie
Newbie


Joined: Oct 19, 2009
Posts: 9

PostPosted: Wed Jan 27, 2010 1:09 am    Post subject: Reply with quote

thanks so much for the detailed explanation, i guess i am cleared for this question...you guys are real experts!
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Wed Jan 27, 2010 1:23 am    Post subject: Reply with quote

So I guess this is an exam question or a work question
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
changeborg
Itiler


Joined: Jul 15, 2009
Posts: 40
Location: United States

PostPosted: Wed Jan 27, 2010 3:24 am    Post subject: Reply with quote

Wow you guys are hitting all of our topics that have come up since returning from the year end freeze period! I don't want to hyjack this thread but I believe this is on topic and felt it better to be here than a separate posting.

If you haven't been able to figure it out due to all of my posts, we are working to elevate our overall maturity on the process. We are also adopting v3 so this will go along way towards that goal. The E-CR topic is a discussion we are currently having amongst our team and some of the domains that interface with us.

Here's the underlying question I think. When you have an active incident, regardless of its severity; should the implementer of the change log an E-CR in advance if he has time to do? Or following the standards of IM, should he just fix the issue and log any changes made retrospectively?

My thinking on this is that when it is a Sev 1 or 2 type incident where you have to implement the fix quickly, then follow IM and log the change retrospectively. For any other severity of incident where you have time to do the necessary planning, coordination, testing and communication then you interface with change as an Urgent category of change and run through the eCAB if necessasry.

Of course we have further complications with outsourced providers managing incidents in those domains but that's another thread....

I'm sure John and the other regulars here will have some good feedback so thank you in advance!
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Wed Jan 27, 2010 4:14 am    Post subject: Reply with quote

Feedback first

take a microphone - hook it to your intercom system. Crank the volume to 300, turn the mic on and move it to speaker

that aside
ITIL is ITIL - v3 is no different from V2 for the purposes of implementing ITIL. If you are going for more maturity, work on the policy documents for CM, IM, PM and RM and CfM

In v2 this is service support, in v3, Service Operation and Transition - if i recall. The only real difference is the focus.

Remember ITIL is descriptive not prescriptive

Also, use CoBIT as well to help mature the CM process as well as the others. The aspects of CoBIT about RACI charts and objective helps a lot in gauge where you are.

Now to your issue

the answer is ... it depends.

What does your policy documents for IM and IM (MI) and CM say. If it does not, fix it so that it does.

Pragmatically, yes the immediate outage ones that need the change now now now or yesterday should go through the motions via email .or what ever ticket trace you have for IM. There MUST be a record of 1) the decision to do the Emergency change 2) the reason and person who said and 3) a statement that it meets the critieria for retroactive change

If it is NOT an immediate fix now blah blahblah, then it is NOT an Emergency Change. In ITIL V2, they break it into 4 categories - emergency, immediate, normal and standard. The emergency types should be only the must fix now damn the documents. while the immediate can be used for the others....

the big difference is Emergencies may not get tested before production deployment. while the immediate need to be - they are just fast tracked

The P-hex pieces of work should never be emergency changes. They can be Immediate so that you can differentiate from the true emergencies

And all others must be documented first because if you have the time to do the documentation, then it is NOT an emergency.... .grin

Prior Planning Prevents Piss Poor Performance = P Hex
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
changeborg
Itiler


Joined: Jul 15, 2009
Posts: 40
Location: United States

PostPosted: Wed Jan 27, 2010 6:01 am    Post subject: Reply with quote

P-Hex *wonders if I can somehow work that into our process documentation* Cool

From a maturity level, we have recently released our global standards on IM which was a long time coming. There is still more to do in that space to map out the relation to change and all the others but it's quickly evolving. The rest of the process streams are also under development and will be coming soon with the help of a formalized ITSM group and long awaited management buy-in.

Ultimately for us to mature, we must have process compliance but to get that we need to harden up the working in our doco. In our current state, we have no real consequences to speak of due to lack of management buy-in into penalties. They buy into the process publically but refuse to issue beat downs to any of their staff for breaking it. We are just starting a project to revisit 100% of our process doco and revise it using CobIT standards. We have already adopted it for other internal processes but due to limited staff, have not had time to convert / rewrite yet.

Part of our issue is a level of complexity that the former owners/authors of the change process built into it and our current owner(s) want to further implement. We currently have 3 categories of Emergency changes, Normal, Unplanned (Immediate) and we have some changes that are Pre-Approved. From my viewpoint, we should only have: Normal, Emergency (retrospective) and the Unplanned/immediate. Of course we will still have the pre-approved but I don't count that as a category as these are CI specific.

We are beginning work on mapping out things for 2010 and 2011 so advice now is helping us along the way.
Back to top
View user's profile
davidlet
Newbie
Newbie


Joined: Oct 19, 2009
Posts: 9

PostPosted: Wed Jan 27, 2010 1:43 pm    Post subject: Reply with quote

I totally agree with what John said...

BTW, John when you say Standard Change, Standard=Routined? In addition, for my better understandings, could u plz give me examples for Emergency Change and Immediate Change under ITSM frame? thanks in advance.
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Thu Jan 28, 2010 7:06 pm    Post subject: Reply with quote

davidlet

Why do you need examples ?

Are these questions part of studing for some exam or for reference to work

My question regardubg this has yet to be answered
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Jan 28, 2010 10:02 pm    Post subject: Reply with quote

I hope I don't shock anyone, but I have to agree with John.

Examples are meaningless. One company's emergency is another's routine event (well, almost).

It was the use of examples that led you up the cul de sac of <critical CI = emergency change>

Remember, in the ideal world you would not have categories like emergency. urgent, normal for change. You would simply have 'what needs to be done first and how much resource and effort does it require and merit.'

We have the categories to help simplify communications and focus minds. We define procedures to correspond to the categories. But in reality the edges of the categories are blurred and the boundaries of the procedures are flexible and the proper decision is always a judgement call, sometimes easy, sometimes hard.

By the way, don't put any of this thinking into your procedures or people will get either confused or exploitative. They must be clear and unequivocal to be effective.
_________________
"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
Back to top
View user's profile Send e-mail
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.