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: JSPL
New Today: 79
New Yesterday: 63
Overall: 139408

People Online:
Visitors: 50
Members: 0
Total: 50

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 Request - What is necessary?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Emergency Change Request - What is necessary?

 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
AndyW
Senior Itiler


Joined: Feb 14, 2008
Posts: 77

PostPosted: Thu Mar 20, 2008 6:26 pm    Post subject: Emergency Change Request - What is necessary? Reply with quote

Hi,
I'm currently working on our Emergency Change Request. The old one does not meet our requirements. It is to much packed with unnessary fields the user has to fill out.
Now I'm curious what do you think which information should definately be captured in Emergency Change Requests?

Cheers,
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Thu Mar 20, 2008 9:12 pm    Post subject: Reply with quote

It depends

The same basic information that is needed for any change is minimum

then the only other thing i would have is why is it an emergency

what is the justification for beign an emergency

also, dont write your policies based on what tool and tool fields

Write your policy on what information is needed

what is being done#
to what CI
why
back out
test
implementation
risk assess
impact analysis
initiators
priority
classification
date data
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


Joined: May 07, 2005
Posts: 121
Location: UK

PostPosted: Fri Mar 21, 2008 4:14 am    Post subject: Reply with quote

I agree with John - everything you'd have in a Planned Chnage you still need in an Emergency Change PLUS the justification for why it is an Emergency.

In my org we use the Emergency category for Changes that will prevent an imminent service outage, so it's really easy; what will break if we don't implement this Change?

We have a Short Notice Planned process for non-Emergency Changes (using the Emergency definition above) that need to go in with less notice than the standard process, and in that case the requestor has to ask one of the DRs of the CTO and get them to allow the breach of notice period.
Surprisingly the volume of SNP Changes plummeted after we introduced this rule... Wink
Back to top
View user's profile Send e-mail
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Sat Mar 22, 2008 2:30 pm    Post subject: Reply with quote

Most of Emergency RFCs in my company were indirectly originated from the customers. For example, they asked for an application upgrade that needed to be in place the next two days.

You know how hard it is to educate the customers. And since the CM process does not deal directly with the customers, we usually need help from the SLM to appeal the customers to regard our processes. But customers also have their reasons: late budget approval (this is the most case), etc.

Things like these are still our CM process's open items, and they surely affected our KPIs, regardless to whether it is in our control or not. Sad
Back to top
View user's profile
Skinnera
Senior Itiler


Joined: May 07, 2005
Posts: 121
Location: UK

PostPosted: Sun Mar 23, 2008 8:34 pm    Post subject: Reply with quote

asrilrm wrote:
Things like these are still our CM process's open items, and they surely affected our KPIs, regardless to whether it is in our control or not. Sad
So I think you need to rethink this statement; if you have no control over something, it cannot be your KPI...

It can certainly be a KPI for your organisation, but it surely doesn't reflect back on the CM team directly?

My dashboard shows a number of things, and only one of them is my KPI (you get 5 patronising points if you can tell me which one);

Changes Closed as Successful (targte 98%)
High Risk & High Impact Changes Closed as Successful (target 95%)
Changes Implemented between Change-related P1 Incidents (target 400)
Changes raised as Planned vs 'Unplanned' (target 87%)
Changes Closed within 120 hours (target 96%)
'Time to Handle' from Change Create Date/Time (target 5 hours)
Back to top
View user's profile Send e-mail
Diarmid
Senior Itiler


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

PostPosted: Sun Mar 23, 2008 9:46 pm    Post subject: Reply with quote

Hi Andy,

this is one of the great battlefields, human nature v best practice. whether deliberately, or through neglect or lack of foresight or through circumstances beyond reasonable control, things will happen and changes will be needed "yesterday".

The issues at stake are risk and the integrity of your management system and success in this area is more down to culture and attitudes than to process refinements.

Skinnera distinguished between Emergency and Short Notice Planned process (which I think of as Urgent) and this is vital to prevent everyone crying "emergency" when they are in a hurry. I think of emergency as akin to an emergency stop for the car. You absolutely have to do it because the consequences otherwise are dreadful, but you don't really know and don't have time to work out the consequences of doing it.

For everything less than "imminent service outage" (whatever best defines emergency for your customer organization) you have to assess the risks, however rapidly you can do that:

- risk/cost of not making the change (including the time factor)
- risk/cost of change failing including the time factor)
- cost of making the change (including disruption and resources)

And then you have to manage those risks and costs. I.e. change planning, change testing. So, however urgent, your Urgent Change Process must ensure that management is retained by someone with those capabilities and that person has to take the time to get all the right information and skills in place.

In short, you follow the Change Procedure, but you establish a priority level that gets the resources ahead of the queue (or through the night, if that is what is needed) and you focus exclusively on that urgent requirement until it is all under control and going ahead.

So the second part of Skinnera's system comes into play; approval (for all this messing with priorities and taking shortcuts) is at a high level. This exposes the request justification to scrutiny.

How you implement this and to what levels you delegate "Urgent" authority depends on how your organization works and how maturely staff and managment understand the essence of good service management.

It has to be established that emergency and urgent changes are serious matters and not a way of circumventing processes or your system will be leaky. So review and report of all emergency and urgent changes (and their justification) should come under explicit scrutiny from senior management (and customers in most cases, if not all), possibly at Service Review boards.
_________________
"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
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Sun Mar 23, 2008 9:52 pm    Post subject: Reply with quote

What I meant was the "Number of Emergency Changes".
We had high percentage of rush RFCs in a month, most of them were due to rush service requests from the customers.
We have already put effort on reducing it, including appealing our customers
And you know what the management comments on this? "You were unsuccessful on selling the concept"
Oh dear ...
Back to top
View user's profile
OhioScott
Itiler


Joined: Oct 29, 2007
Posts: 26

PostPosted: Tue Mar 25, 2008 4:27 am    Post subject: Reply with quote

Our organization defined Emergency Change as any change required either due to a loss of or eminient loss of service capability to critical configuration items (which were identified).

Under this situation the change is often implemented without benefit of testing or at least to a degree of testing expected and documentation made after the fact with assessment focusing on whether the Emergency was justified.

Our documentation was more focused towards the justification of the Emergency and potential impacts in order to monitor potential incidents as a result of the change with little or no documentation on test plans or backout plans. Again a case by case basis.

Urgent Changes were those changes that needed to be excelerated for immediate review and authorization due to some justification but were still required to follow the change process otherwise unless they applied for a specific exception or waiver from some activity of the process.
Back to top
View user's profile
Skinnera
Senior Itiler


Joined: May 07, 2005
Posts: 121
Location: UK

PostPosted: Wed Mar 26, 2008 7:51 am    Post subject: Reply with quote

asrilrm wrote:
What I meant was the "Number of Emergency Changes".
We had high percentage of rush RFCs in a month, most of them were due to rush service requests from the customers.
We have already put effort on reducing it, including appealing our customers
And you know what the management comments on this? "You were unsuccessful on selling the concept"
Oh dear ...
So that was exactly the reason I implemented the processes I did - almost 20% of RFCs were being classed as 'Emergency', when in reality they were anything but.

So, make it clear what the Emergency definition is; empower (and expect) your team to challenge every one that comes in against your definition; ensure that your normal notice period is well communicated and explained; finally, make it painful for the customers to get their RFC's signed off - it's their problem not yours.

BTW - we now have less than 2% of RFCs classed as Emergency Very Happy
Back to top
View user's profile Send e-mail
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Wed Mar 26, 2008 10:43 am    Post subject: Reply with quote

Skinnera,

That's a good achievement, congrats. Cool
About your way of empowering the team and "unleashing hell to the customers", I wish I could do that in my company.
I mean, I'm sick and tired arguing with customers and our CRM on their back, if you know what I mean.

Anyway it was a good idea.
Thanks

Cheers,
Asril[/i]
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.