ITIL to take the pain out of change management

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.

The origins of ITIL

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.

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.

Email Alerts

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree to receive emails regarding relevant products and special offers from TechTarget and its partners. You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

It can be tempting to stray from the security roadmap security professionals have put in place when data breaches like the Sony and Anthem breaches are all over the news. But experts say it's crucial to stick to the security basics.

The Open Data Platform has arrived, but not all Hadoop vendors are on board. The initiative, aimed at boosting interoperability, formed a backdrop for discussion at the Strata + Hadoop World 2015 conference.