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 […]
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.
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….
1. High Level
Aligned to your release model, details the major stages of a release: plan, build, accept and deploy and how the lower level activities fit within that: scope, requirements, build & test, acceptance, implementation, early life support and also show checkpoints (scope finalisation, build completion) and show gateways which align to your other processes such as governance, Change Advisory Boards etc). It’s also worth showing which environment various activities take place.
Build a timeline. Start from the ‘go live’ checkpoint at day 0, work backwards (T-) and plot in the major stages for an average release type (you may need one per model) and then plot other activity: environment management (data refreshes, interface switching etc), comms plan and enough lower level activity.
This high level lets you see the whole picture and start identifying areas of contention. If you have release cycles which last for several weeks and which are implemented monthly, you can expect some overlap. Examine these areas of overlap, it’s not uncommon to find the same teams doing different activities at the same time. Does this work for you?