"A change," they say, "is as good as a rest."
Well,"they" have obviously never faced the riddle of the critical production system failure first thing on a Monday morning.
Perhaps you will know this story: Key business system generating the wrong numbers; someone thinks a tiny change was made over the weekend within a database. No-one knows who, no-one knows what. The company is losing money by the minute…
If I were to ever meet"them", I would tell them that a change is not, in fact, anything like a rest. Change is more like stubbing your bare toe on a cold morning. It hurts like hell.
70-80% of service interruptions are caused by changes being made
Within the IT world, change is inevitable. We have the constant release of security patches, hot fixes, service packs, new versions, changes to code, hardware replacements, configuration changes, modifications to reference data – the list goes on.
How much exactly does change hurt an organisation? Well, 70-80% of service interruptions are caused by changes being made. I’m going to repeat that (partly because it’s a staggering statistic and partly because I’m paid by the word), 70-80% of the pain is caused by changes.
So change equates to risk, and risk is not something that any business likes to encourage.
Change is also unavoidable – unless you’re happy with a 640x480 monochrome display and DBASE II as your strategic data platform of choice. So changing nothing is not an option either.
Read more on ITIL and change management
- How change management fits in an ITIL methodology
- Change management: Make sure everyone is in tune
- ITIL implementation: Using ITIL best practices
- Fortifying the ITIL framework for IT and the business
The origins of ITIL
Back in the 1980s, the UK government, realising that organisations were becoming increasingly dependent on their IT systems, had some folks look into the whole subject of managing IT services.
What they saw was various organisations (both public and private sector) experiencing essentially the same service management pains, but independently dreaming up and implementing their own best practices as a result.
The folks looking at service management therefore distilled the shared experiences of all these organisations into a single unified set of best practices – an accumulated wisdom for service management.
The best practices were named ITIL (pronounced Aye-Till) – the Information Technology Infrastructure Library. Among these practices was a heap of good advice for systematically managing change, and thereby crucially minimising its associated risk.
The word "Library" in the moniker comes from the fact that ITIL was first published in a series of 30-odd reference books. Thankfully, over the years, the books comprising the infrastructure library have gradually been condensed into just five volumes.
So what does ITIL tell us about managing change? Well actually, a great deal of it is common sense.
Proposed changes are formally detailed as requests within a change management system for consideration.
Change requests are reviewed at a change advisory board (CAB) – a group of interested parties who meet regularly to assess all upcoming scheduled changes.
The CAB is chaired by the change manager (CM); and present will be service owners, IT workers from various disciplines, representatives from the business, and the person making the change request in the first place.
The CAB is not concerned with getting into the technical nitty-gritty of the changes; it is about mitigating risk by asking sensible questions such as:
- Has the change been fully tested?
- Is another change happening at the same time which is incompatible?
- What post-implementation checks will take place to ensure the change was successful?
- Is there an adequate reversion plan?
- Is sufficient staffing in place if everything goes horribly wrong?
ITIL is not a compliance-based regulation, not an enterprise certification - it is an aspiration for organisations to move towards
ITIL is a business aspiration
ITIL is an aspiration for organisations to move towards. It is not a compliance-based regulation, nor an enterprise certification. There is no ITIL awarding body to visit your organisation, hand over a certificate, and warmly shake your CEO’s hand as he proudly has his photo taken for Computer Weekly.
Additionally, there is no ITIL secret police ready to break down your door in the middle of the night because you raised a change request without the necessary documentation attached.
That said, by implementing the ITIL principles, organisations can make considerable progress towards achieving some recognised enterprise certifications which have similar foundations to ITIL – such as ISO/IEC 20000.
ITIL cannot be achieved by any one individual. It is no use making one person responsible for implementing ITIL within an organisation, because that person will undoubtedly fail.
The value of ITIL must be recognised at the very top of the organisation, and a firm resolution to embrace its principles into the company culture must run down from the highest echelons of management.
Only with this kind of corporate buy-in does ITIL stand any chance of being successfully implemented and adhered to. This may not be an easy thing, but the rewards are vast – as any organisation that has experienced the pain of a stubbed toe on a cold Monday morning will agree.
Andy Hogg (pictured) is a freelance consultant specialising in Microsoft SQL Server and associated technologies.