The Trouble with Change
2 Dec 2020Following on from my last piece on governance in service delivery, I’d like to dig a little deeper into the practices and processes of change enablement. Of all the processes in an organisation, change enablement is the most emotive. It’s probably the area I get asked most to ‘fix’ because everyone hates change – apparently!
It’s easy to see why – there’s often a huge change request to complete, with 10 pre-approval signatures required, (all hard-to-get-hold-of senior managers, of course). And that’s before you’ve even got to Change Advisory Board (CAB), who can’t see your minor change for 3 weeks, unless you’ve got a bullying manager supporting you. When you finally get to CAB, there’s hours of debate, sharp intakes of breath and grinding teeth, as your change is ultimately rejected and sent around the loop again. Perhaps it would just be easier to ignore the process and just get on with the job?
If that – or any part of that – is your experience of change enablement, let me suggest that your organisation is not doing it well. There’s a better, lighter way…
I first saw the seeds of change sown (no pun intended) back when ITILv3 came out. The message was clear – change (management, as it was then) should enable change to happen. It should enable the business – however it can – to implement successful changes, whilst managing risk to an acceptable level.
This has been reenforced further in ITIL4 with the practice’s purpose clearly articulated as ‘maximising the number of successful service and product changes, by ensuring the risks have been properly assessed.’
I think what’s interesting with change enablement, is that the practice hasn’t really altered much since it was first published. A change follows the basic steps of registration, assessment, authorisation, planning, implementation, review and closure. What is changing, is the recommendation around the size of changes, who authorises them, and how they move through the process. In a modern, digital organisation where hundreds of changes may be happening simultaneously, the practice cannot unify all the changes into one big picture. So, what do we need to do?
Looking at the ITIL4 purpose statement, the key words – and the ones that are usually misconstrued or missed – are ‘ensuring the risks have been properly assessed’. So many organisations over-govern their changes, unnecessarily bogging down the CAB and the Change Enablement function. I’d like to look at a couple of ways to alleviate this potential bottleneck and the associated frustrations.
Standard Changes
How many changes does your organisation implement that are genuinely novel? Operationally at least, I would hazard a guess that it’s relatively few. And the more a change is undertaken, the more confident the implementation teams become, and importantly, the more predictable the outcome. Predictable outcomes and well understood activities, supplemented with checklists and templates constitute a standard change.
When the documentation for a standard change is initially created or modified, it undergoes a full risk assessment, through the change process. However, once agreed, authorisation for the implementation of the standard change comes from the agreed delegated authority – pretty much whoever you want in the organisation. No CAB, and usually with minimal (or no) management approval. Where automation is available, there will be no tiresome bottlenecks as an entire change can be selected, and (assuming appropriate authorisation) implemented at the click of a button or two.
If you haven’t got a fistful of standard changes implemented in your organisation for routine tasks like fulfilling service requests, maintaining your infrastructure, software updates and routine testing then you’re missing a trick and more importantly, potentially throttling the throughput of changes. Go forth and standardise!
Interestingly, standard changes also have value beyond routine – they can be used in incident management too. What? But you said understood risk and predictable outcomes! Here’s the thing, many incident resolutions do have predictable outcomes, either through documented workarounds or permanent fixes. Similarly, standard, documented responses to disaster situations can help an organisation decrease uncertainty in that extreme situation.
Standard changes can be utilised for quite large pieces of work as well. It’s back to the risk, and predictability of outcome. I once heard that a large corporation we all know used to have a ‘standard change’ for buying out smaller organisations. Whether this is true or not, I don’t know, but theoretically I don’t see an issue. ‘We’ve done this many times, the steps are well documented, the outcome is predictable, the risk is low (or at least within tolerance) and the delegated authority is defined’ … why not?
Change Models
In addition to standard changes, I also encourage you to look at change models (again an initial concept of ITILv3, driven home further in ITIL4). When a change isn’t an ‘emergency’ change (responding to a time-driven incident) or a ‘standard’ change as described above, ITIL defines it as a ‘normal’ change (inventive nomenclature, I know)!
A change model is ‘a repeatable approach to the management of a particular type of change’, providing guidance for handling those normal changes. It doesn’t have the predictable outcome and detailed work instructions of a standard change, but there’s enough familiarity of the change type to build a model for the next time it is undertaken.
Based on our experience of previous iterations of this type of change, which team is best placed to develop it? Who should assess the change? Are the associated risks enough to warrant CAB’s visibility and assessment? What testing needs to be undertaken? What were the issues we encountered (if any) that we need to be aware of? Over time, a very useful model can be built up to fast-track the change.
The change model usually takes the form of defined procedures, including defined roles for the assessment, authorisation and ongoing control of the change. The implication is that for many changes, the required assessment and authority can be defined somewhere other than CAB. Again, risk is the key factor – if the risk is acceptable and the change is, for example, contained within a service or product, then do you really need to go to CAB? Less is more, as they say.
Change Deconstruction
A relatively recent way of thinking in change enablement, derived from the iterative approach of the Agile methodology is change deconstruction. The practice suggests that it may be possible to limit a change’s potential risk by deconstructing it into simpler iterations, each of which is below an agreed risk-level threshold. This can limit the risk of the change and make it easier to control and manage, along with other potential benefits of reducing costs, and speeding up the change cycle. In a market where speed and output are defining factors, change deconstruction makes a lot sense. I will flag up though that risk is a key factor and governance cannot be ignored. I recently worked somewhere that insisted that they were extremely ‘Agile’ and therefore there was no need to use a change process at all! It’s no good being first to market if your service isn’t robust enough to deliver outcomes.
Summary
Change Enablement (previously Change Management, and even further back Change Control) is often perceived, and implemented as an unwieldy, bureaucratic process, forming a bottleneck in fulfilling business requirements. Experience suggests that by delegating changes to appropriate levels, according to the risk they pose, the perceived bottleneck the change process can be alleviated.
Couple this with defining standard changes and change models and you can increase throughput, whilst managing the associated risks appropriately. Further, if you can deconstruct larger changes into smaller, iterative, and more manageable changes you can increase the rate of change, reduce costs and improve customer satisfaction with the change practice.
