All the rituals but no results: cargo cult change management

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 would receive the same benefits (western cargo consignments). These were some of the best known cargo cults of the pacific islands (though the origin of ‘cargo cult’ precedes WW2) – a story that would be a curious footnote consigned to history, if it weren’t a practice alive and well in IT Ops departments today. In this article, I’ll look at some of the most common change management activities that are followed rote, and yet never seem to deliver the benefits that change management promises.

The Ritual Of The Holy CAB

People congregate once a week, confused about whether they really need to be there, often resentful of the waste of time, unclear as to their role, or whether it’s an approval or advisory board (and if the latter, who really ‘approves’ the change?).
If you’re lucky, or if someone really needs a favour, there may be doughnuts present at this ritual, but the usual props are an agenda, a conference phone and laptops/tablets used surreptitiously to check emails on.

 8-step change overhaul plan

Firstly, pause the CAB if it’s become a rubber stamping exercise. Work out who is the decision authority for changes (which can be the change manager) and do the following:
  1. Aggressively review and update the standard change list to remove trivial changes form the normal change approval route and create some process volume headroom
  2. Aggressively define and reinforce the emergency change approval route to reduce instances of interruption and create mental headroom
  3. Revisit step 1 to see what changes were masquerading as emergency for reasons of lead time when they could actually become standard
  4. Consider a new category of minor-normal changes that don’t have to go to CAB or can have an offline/electronic approval (or maybe have a 2-step approval of a technical suitability peer-review plus a scheduling approval from the change team)
  5. Consider devolving change approval to automated test and deployment tools with a periodic compliance review
  6. Re-establish the CAB to deal with the big/impactful stuff. Keep the attendee list as short as possible.
  7. Coach attendees to present changes following a script to include what the change is, why it’s necessary, when they want to do it, what the risks and impacted systems/services are, how they’ve mitigated them etc
  8. Iterate and fine-tune 4,5 and 6 to control the volume of change going to CAB

 

The Summoning (of the overworked change assessor)

The most impressive change assessor list I’ve seen had assessment tasks being sent out to 31 different roles and teams and was to de-rack an old dev server which had been powered off for the last year.
Requests to conduct assessment tasks should be value-add activities. But change management have to be responsible with these interruptions. Sending to a blanket list of assessors and expecting them to determine applicability should be the exception, not the rule. If the requestor and the change manager really don’t know who needs to assess, then ok, but in most cases a good change manager will be enough of technology generalist to have a reasonable idea, and if they can’t determine who this is from sparse information provided, then there’s a data quality issue that also needs resolving.

How to fix?

Work out if a peer-review would be more valuable than a tenuous link to a probably-uninterested third party – some local accountability is often a very positive driving force on change quality.
Remove irrelevant templated assessors, and start again with your own list, adding them in per-change until you have confidence changes are going to the right people.

Standard Change Indulgences 

The worst standard change definition I’ve ever seen is “Update a field in a table” with no bounds or constraints. Needless to say, it was the most popular change used by two orders of magnitude, only a few % of which were actually for the original intended purpose.
Standard changes should be clear and specific, if you want to define an activity in a number of situations then either create several standard changes, or a single standard change with parameters. Parameterising standard changes is a good habit to get into anyway.

Implementing The Five Thousand

Three week implementation windows are rarely appropriate, especially for the reboot of a single server. As I wrote in another article (external link), it’s usually ok to give an estimated implementation window for early change requests and then firm this up as you get resources lined up, but implementation dates must be meaningful, otherwise on the panicked 3am call where you’re trying to work out what went wrong, you have no idea exactly when someone actually did reboot that firewall.
Here’s an excellent related article by Rob England Challenging the operational rites