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 […]
Category: change management
The real problem with frequent emergency changes
Changes are decisions, balancing risk and reward. In the language of Decision Theory, they are classed as normative or prescriptive decisions (i.e. identifying the best decision to take) which rely on access to good information […]
What happens when you ignore service design and acceptance.
I recently discussed service support / operations on twitter with someone frustrated at being asked to provide support for a public cloud service he had very little ability to. Not technical capability, because he seemed capable enough, but access to the systems to do more fundamental fixes. We didn’t get far into the details, but it seemed he was being asked to deal with something which hadn’t been thought about when the service was provisioned.
This is sadly not an uncommon situation among support teams who often have no say in the choice of system/service, no time to get familiar with it, and no means of pushing back on critical gaps even if they do get a chance to see it beforehand. These are often gaps that a 5 year old could often spot, let alone experienced engineers but which seem to be frequently ignored by people whose shopping list only has one thing on it: functionality.
Change requests: get the basics right
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.
Here’s how you define change.
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….
Release Management amplifies the effects of your change process (good or bad)
Let’s generalise for a moment. Release management usually comes into effect in two significant circumstances:
1. When you want to bundle changes into a package
2. When you want to fully ‘transition’ a service into operation and deliver the associated support and knowledge etc
In both of these circumstances, the output of the release will be an amplification of the inputs, ie. the component changes.
Change and Release concepts part 2
In the previous post I mentioned about multiple layers of authorisation, here’s another example which was given to me by an ITIL trainer a few years ago. Take a commercial airline. A manager within that […]
Change & Release Concepts part 1
In a simplified view of the world, if you want to change something, you raise a change request, it gets approved, it gets built, it gets implemented. Wait – when does it get approved? Before […]
Introduction
This blog will show you how to implement change, release and configuration management. It’s broadly ITIL V3 aligned. It includes some concepts and tools that work for me, and may do for you with some […]
Change & Release Management 