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.
To fix this, you need to go back to basics and look at the information you’re capturing when you ask someone to raise a change request; quite simply, it’s the “what, why, who, where, when and how” of doing a change.
There’s an important concept I want to relate this to, which is getting the right balance between stability and responsiveness. It’s a key concept in ITIL V3 Service Operations and one which Service Transition (especially change and release) are responsible for (if not always accountable).
Getting this balance right is usually a matter of making the right decisions given the available information, and the effects of that decision-making will be felt by your customer/client. Too cautious or risk-averse and you could sacrifice responsiveness…which means your customer loses their edge. Too far the other way and you’ll quickly run into chaotic systems and start playing catch-up (which is very resource intensive and lowers your overall through-put).
So as a change manager, or someone attending a Change Advisory Board (CAB), what is the information on which you should base your decisions? Usually this comes from one of three sources:
- The contents of the change record
- The person presenting the change and answering questions on it (was that a nervous tic when he said “it’s been fully tested, I swear….”?)
- Your colleagues / fellow CAB attendees / subject matter experts
The first and most important source of information here is the change record. This is more than just a descriptive form. At the risk of waxing poetical, this is the beginning of a contract. For some organisations and for some types of change it may only be a barely-formalised social contract, but for many more it also has significant legal implications – especially for financial organisations which have strict Segregation of Duty rules or other regulatory requirements governing the implementation of change to systems which store, generate or process sensitive data.
Change requests then must be accurate – for reasons of trust, legality and cost. They must be filled out to the best of the requestor’s knowledge and then fact-checked. In IT change management, this fact-checking is often performed by a peer or team leader / manager and is often called a ‘local approval’. This is a very practical quality check and filter, and one that I’d recommend for any organisation, especially those processing high volumes of change or particularly complex change.
Next, we have to consider the audience for the change request. Many change managers and analysts, although likely to pick up a decent amount of local knowledge, will be generalists when it comes to the systems and services for their customer. They have to be generalists, as part of the job is understanding the reach and scope of each change and bringing impacted parties into the decision process. Those other parties might be non-technical. So change requests should be understandable, with enough information so that people who aren’t familiar with the system can familiarise themselves with its contents at a glance. It’s fine to copy and paste a snippet of code or an extract from an error dump into a change request, but it should be accompanied by some explanation to give it context. These records may also be reviewed or audited many years into the future, so a decent explanation will add immense value here too.
We’ve covered accuracy and detail so the final component is….what do I put in a change request?
That’s actually fairly easy, and was mentioned at the start:
- What do you want to change?
- Why do you want to change it?
- Where do you want to do it?
- Who is going to do it?
- When do you want to do it (and how long will it take to do and to back out)?
- How is it going to be done (and undone if necessary)?
If you can get this consistently right, you’re over halfway there. And if you can get this information into a decent tool, and retrieve it and present it in a well-designed format, your decision makers will have everything they need to make the right decision for each change quickly and effectively. And this can only benefit your clients. Because if we don’t keep them in business, we won’t have a business either.