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


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: deirdreqg18
New Today: 0
New Yesterday: 40
Overall: 231752

People Online:
Visitors: 127
Members: 0
Total: 127



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

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.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Change Categorization
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Change Categorization

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

Joined: Mar 06, 2007
Posts: 2
Location: Boise, ID

PostPosted: Wed Mar 07, 2007 8:45 am    Post subject: Change Categorization Reply with quote

A quick, generic definition or each change type used here is:

Major Change - Defined as a high risk, involving complex changes altering production systems and difficulty with backup/recovery in the event of an issue. Major changes require review and approval at the Change Advisory Board (CAB) meeting prior to implementation.

Minor Change - Defined as a low risk change, categorized by limited impact to production services, and the ability to adequately test prior to implementation and easily back-out/recover in the event of an issue. Minor changes require review and approval by the technology manager of the group performing the change.

Emergency Change - Requires immediate implementation to correct a disruption or outage of service. Since these changes must be implemented immediately, documentation and approval requirements must be met following implementation.

MAC (Move/Add/Change) Treated as a standard change which consists of a routine activity involving low risk and impact to production services and is performed on a recurring basis. To utilize the MAC, the process to perform the activity must be certified through the normal change process for a Major Change Order. Once certified, a MAC can be performed according the approved process and with the appropriate change record without additional approvals.

------------- Issue/Question ------------
Our metrics have reflected an emergency change (E-CO) rate in excess of 15%. This has caused great concern. While reviewing the content of some of the changes reported in an E-CO it seems as though we may benefit from defining an additional category. An example of a change reported as an E-CO which truly is NOT and could "fit" into an additional category may be: it is discovered a production server will run out of space prior to the CAB meeting (CAB is held once a week) and in an effort to be proactive, the space is added prior to CAB during an "off peak" time to alleviate the possibility of interrupting service at a less ideal time.

I am considering an "Urgent" category which would require approval from the Director of IT prior to implementation . The type of work fitting this could be:
* Work would be similar to the Major change category, but could not be planned in advance for to have review at the recent CAB meeting
* Has a high probability of causing "issues" if not implemented in a very timely manner (prior to the next CAB meeting)
* Was not a result of lack of planning

Does anyone use something similar to this or have any suggestions? Thanks much!
Back to top
View user's profile
Senior Itiler

Joined: Apr 10, 2006
Posts: 86
Location: Boise Idaho

PostPosted: Thu Mar 08, 2007 4:54 am    Post subject: Reply with quote

It almost appears trying to mix category vs priority and this may be what is clouding your %. If you were just wanting to add one additional category to your current, my recommendation would be:

Urgent - Minor or Major request that needs to be implemented immediately, outside of the normal release window (if one is defined). This request still requires the normal approvals prior to implementation into the production environment.

Update Emergency to reflect system down situation.

I think this would be the best approach given information provided. This way you would be able to seperate out your restoral of service (emergency) to unforseen(urgent) changes.

What you can also do on this is say once or twice a month review all those urgent requests for determination whether it was truely unforseen or a lack of planning. From there you can build your case for those teams or areas that seem to lack the ability to plan to help them do a better job Smile
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Senior Itiler

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

PostPosted: Thu Mar 08, 2007 11:01 pm    Post subject: Reply with quote

So we have Planned, Fault (to fix a service impact that already exists, has an Incident ref, etc), and Emergency (which is to prevent an imminent service impact, does not yet have an Incident ref).

Focussing on whether the Changes raised as Emergency actually fitted this definition got our rate down from 15% last July to 6% in Jan, to 1.6% now.
A lot of people were interchanging Fault & Emergency, and thinking that urgency = emergency...
Back to top
View user's profile Send e-mail

Joined: Jun 11, 2007
Posts: 6

PostPosted: Tue Jun 12, 2007 4:20 pm    Post subject: Reply with quote

Hi Ivy,
i think the Urgent Change
Changes that are vital to meeting business need but cannot conform to the normal change process, particularly lead time. They can be submitted to the Production Controller for an urgent review and will be scheduled to implement upon approval on the same day.

Emergency Change
Changes relate to an immediate resolution of a known production problem where outage of a system, application, network or other service component has occurred or is imminent.

Emergency change records can be entered after the changes are implemented; they must be opened, electronically approved and closed within 24 hours following the implementation of the changes.

The minimum change approval for an emergency change is verbal approval from the Data Center and System Operations Director, or delegate, and change approval must be obtained prior to implementation.
Back to top
View user's profile

Joined: Mar 21, 2006
Posts: 18

PostPosted: Tue Nov 13, 2007 12:37 pm    Post subject: Reply with quote

Within our ITSM tool, we relate changes to incidents/problems/etc. An Emergency change is performed where a Sev 1 or 2 incident exists (reactive to restore services) or where a Sev 1 or 2 problem exists (proactive to prevent an outage/etc). Essentially, the world is going to come to an end unless we act immediately.
We use the Urgent priority for those that don't meet lead times, but have a real business need, with the business' superintendent providing approval.
Back to top
View user's profile
Senior Itiler

Joined: Oct 12, 2007
Posts: 306
Location: Ireland

PostPosted: Tue Nov 13, 2007 7:56 pm    Post subject: Reply with quote


from my experience adding an "urgent" category anly allows for people to bypass the normal change process.
people will give you every excuse under the sun to claim that their change is "urgent" and before long the figures are again inaccurate as you will see a lot of "urgent" activity.

You could state that changes that are requried for proactive measures but will not result in system unavailability (as theyare to be done out of hours or during maintenance windows) are to be logged as normal changes. Chnage Management are to the informed and to seek approval outside of the CAB. This gives a definition to what you want to do without having to set up urgent category for changes. For each exception, clearly define it in the change management process.
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

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.