Sunday, 14 October 2012

Wither ITIL?

Established now as perhaps the de facto standard for service management operational processes and procedures, ITIL (Information Technology Infrastructure Library) is the default starting place when thinking about how we ‘do’ IT service. Notions such as Change, Incident, and Problem Management have all entered the IT lexicon as familiar disciplines which we pursue and in which we strive to excel.

ITIL is certainly based on sound principles, and – properly embraced and adopted – can bring real value to an IT function and hence to the business it supports. Having said that, I do wonder if we might have lost the plot a little bit…

I draw a parallel with Prince2, the similarly accepted default project management standard. Developed primarily as a tool with which to run large public sector projects, it occupies the kind of standing to which ITIL is now close. The problem with it, though, is that at a fundamental level it doesn’t work; it guarantees nothing. If Prince2 did exactly what it said on the tin, then why do so many projects adopting it still fail – and massive value public sector projects in the UK continue to do so spectacularly?

Looking at ITIL (and keeping Prince2 in mind), there are some obvious concerns about where we are with it today.

It’s getting more complex. ITIL started as a number of volumes (the ‘library’ in its title). The move from Version 2 to Version 3 has seen a significant increase in the numbers of books in the library, and an increase in the numbers of processes and procedures proposed by it. Proponents may argue that this is necessary to reflect the current IT world, to ensure better services etc. They may be right. They may not.

Has it become an intellectual exercise in its own right? This explosion of breadth and depth within ITIL could potentially be seen as becoming an intellectual exercise in its own right. ITIL has now an industry of its own. One can imagine the clamour to be part of ITIL v4 (should there be such a thing) where the numbers of volumes expands once again, the qualifications burgeon, the specialist consultants multiply…

An excuse, not a tool? Adopting ITIL guarantees nothing. Just like Prince2. Are we embracing ITIL more as an excuse than a tool? Does it allow us the opportunity to actually not think about the situations we face on the premise that ITIL will fix it? And if it’s not quite there, do we go further in our over-engineering to pursue an idealised vision of a ‘real world’ where simply nothing goes wrong? There are no silver bullets.

I think ITIL – or at least the principles behind it, rather than the ‘thing’ itself – offers true value. Indeed, adopting some of the underlying principles are essential in providing solid IT services. But have we lost our way in that the adoption of ITIL becomes the end in itself, rather than the true outcomes for which we strive – and for which ITIL may not be the best tool, or the only tool, or indeed the right tool. Are we asking ourselves the right questions? Maybe ITIL has some kind of shelf life – like an old movie actor known by everyone, yet everyone also knows they are past their sell-by date.

Heretical stuff.

I recently saw a job advertised where there was non-negotiable application criteria that demanded an ITIL qualification. Adoption of such a crude instrument could actually lead to the preferential recruitment of people with specific pieces of paper (qualifications) over those who have the real scars of battle in providing good quality IT services. What would you rather have, a soldier who had a diploma in rifle shooting, or the best marksman in the world minus the diploma?!

At the very least we owe it to ourselves to take a step back from our ITIL programme, processes, initiatives and metrics, and ask ourselves some fundamental questions.

·         What is important in IT in relation to our business context?

o   What do our customers actually care about – and what don’t they? You aren’t a Bank, so do you need security like Fort Knox?!

§  Do we really know what is important and fundamental to our Users? We need to ignore all ‘received wisdom’ on this one and just ask them. Make the questions as binary as possible.

§  Are there things we spend time and focus on which they don’t want, need, read etc. – because if there are, then maybe we should stop them. Our service proposition could get simpler!

§  What components of ITIL (and associated elements) currently in place could they actually live without?

o   What elements of IT for which we are responsible cause our customers pain and aggravation?

§  Again, do we really know? We may assume that we are failing them in some areas because our metrics tell us so – but they may not care.

§  Ask them what they would change if they had the chance – I guarantee that a significant proportion of what they suggest will be basic, non-ITIL, service fundamentals e.g. make it easier for me to get a new PC..!

·         What problems are we actually trying to solve? Do we know? We may think we do…

o   The output from asking the business about what is important to them will help – and any pain survey conducted certainly will! This should give us a starting list of what really matters.

o   What ‘internal’ IT problems are we trying to fix?

§  These should be easier to identify, right. After all, they’re right under our nose…

§  We should know where we take too long, where quality is poor, where performance (in all its guises!) is inadequate, and so on. The important thing here is not to start with an ITIL manual or list of ITIL processes, otherwise you’ll end up with a list predicated on ”Oh, we haven’t got one of those / aren’t doing that”.

o   Articulate the problems we are trying to solve – both business and IT – in simple language, and identify what will look different after we’re solved it.

·         What are the truly essential ITIL service components from an IT perspective?

o   What would happen if we stopped doing ‘X’?

§  This is tricky too. This is also where we need to be ruthless. But the bottom line is that by stopping doing one thing we might just free up our resources to fix something much more important.

§  For example, we ‘do’ Knowledge Management to a ‘level 2’ competency and our instinct tells us we need to get to level 3. But what if we stopped doing it altogether? What would we lose? And what would we save / free up?

o   What do we really need to do that we aren’t?

§  This is about core, bread-and-butter ITIL processes. Like Change Management. Not doing it? Shame on you! One you can’t live without, I’d suggest. But even then, even if you are doing it, is your approach appropriate to your need? Are you gilding the lily for the sake of it? What does ‘good enough’ look like – do you know?

Questions, questions, questions. But without questions, we don’t get to answers.

And here’s the rub. I suspect that, if we undertake such a review, if we strive to find out what is really important in the context of our ITIL-related, service provision processes, what we will actually find is that we need less ITIL than we thought – fewer processes / less complex ones – and more bread-and-butter management. We will expose weaknesses that cannot be addressed by adopting ITIL or for which ITIL has no solution. We will learn how to become that expert marksman, and use the diploma for target practice!

Whither ITIL? Well it’s going nowhere fast – and probably neither should it. But we should perhaps consider putting it back in its box and re-teach ourselves to recognise what we truly need to get done.

-*-

About the author / copyright

Ian Gouge is widely experienced in business-driven Information Technology, culminating in significant achievements majoring on organisational and process change, and with a proven track record in turning around / re-engineering IT functions. He possesses in-depth experience of change, transformation, IT delivery, customer and supplier engagement, and broad International exposure. Also the author of management books on the topics of IT Strategy and Project Management, the impact on IT of e-Business, and the IT Organisation.

This material is copyright of Ian Gouge © 2012. All rights reserved. Any similarity to actual IT or business organisations is entirely coincidental and unintentional.

Any redistribution or reproduction of part or all of the contents in any form is prohibited other than the following:

·         you may print or download to a local hard disk extracts for your personal and non-commercial use only;

·         you may copy the content to individual third parties for their personal and non-commercial use, but only if you acknowledge the author and blog as the source of the material.

You may not, except with express written permission from the author, distribute or commercially exploit the content. Nor may you transmit it or store it in any other website or other form of electronic retrieval system.

No comments:

Post a Comment