At the end of the second world war, the inhabitants of several pacific islands thought that if they emulated the behaviours of the colonists and forces personnel they had been observing and interacting with, they […]
Most change requests get raised, authorised and implemented.
When I’ve had occasion to post-mortem a failed change for a new client, I’d usually expect to hear one of the following phrases:
- I didn’t know what I was supposed to be doing
- It shouldn’t have broken that, it was supposed to be totally unrelated…
- How was I to know the backups were running at the same time?
- Wait….I thought John was doing that reboot?
- We only overran because we had to back it out…
…all of which are avoidable.
I just read an article on an ITSM blog I stumbled across where the author briefly discusses the confusion that can arise when people talk about different types of change.
The author raises a valid point about operational change versus standard change etc. and this is a problem I’ve run into in the past.
So let me give you the way I solve it.
There are two things we need to define here:
- Attribute = how you describe a change in terms of priority, impact, type, category etc
- Process / Route To Production (R2P) = how you deal with a change which can be described by a combination of one or more attributes – eg. Normal change, operational change, standard change, emergency change, service request….