Change Management Categorization

Discuss and debate ITIL Change Management issues
Post Reply
User avatar
Posts: 2
Joined: Mon Jun 06, 2016 8:00 pm

Thu Jul 28, 2016 4:42 pm

We are currently in the process of defining our Change Management process and are trying to determine how we should categorize changes. The idea behind this is to find the lead/turnaround time for a change.

We originally separated the change types by levels but are having some issues separating it from Impact.
1. Emergency
2. Level 1
3. Level 2
4. Level 3

How should changes be categorized? Should it be linked to Impact or Priority?

Any ideas are appreciated.

User avatar
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Mon Sep 05, 2016 6:17 am

the usual terminology for changes are

Emergency, Normal, standard, minor, major, Fast Track, Retrospective

Emergency & Retrospective usually are the same. The difference is the retro change is written after the work is done. Emergency means there was time to think about and plan .. so to speak

Major and Minor indicate complexity

Fast Track, Normal, Standard usually associate time frames
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
Posts: 12
Joined: Mon Sep 05, 2016 8:00 pm
Location: Minnesota

Tue Sep 06, 2016 3:13 pm

In my company we have two levels

Change Types - ITIL types
* Normal
* Standard
* Emergency

Then similar to UKVIKING's comments for more classifications but we label them with IMPACT
* Low (no outage or low impact)
* Medium (small outage or moderate impact)
* High (long outage or high risk change due to various circumstances)
* Critical (unusually large outage or business mission critical functionality being impaired or touched)

I really like the idea of a Retrospective type though. We don't do them very often but its a great idea.

we used to have more changes types but it moved to generating to many questions about "What do I select for this scenario" so we narrowed it down and people seem to like it much better. Similar to the keep it simple stupid approach.

Over the years I've learned my companies behavior quite well and have made drastic improvements for CM to be accommodating but strict where it counts (basically cutting the fat). Having a bunch of change types I found to be "fat".
Post Reply