The Alternative to ITIL …

If I follow the social media ITIL seems to be over the hype-curve, with many people predicting its impending demise, often due to various reasons:

• The joint venture with Capita (AXELOS) will make it too commercial
• COBIT (or …) is better
• DevOps will replace it
• Cloud computing has made it obsolete
• BYOD has made it obsolete

In our MALC course we actually debate the relevance of ITIL, whereby I as the facilitator take the opposing view, often using the very reasons I’ve highlighted above. It is refreshing to go over to the ‘dark side’ and attack the ITIL framework for all its weaknesses (or heralding the benefits of those mentioned above). At one stage we nearly decided to quit the course and start doing COBIT Foundations instead!

But it also makes me realise all the good things about ITIL and how to actually, practically apply it. I will address the ‘negative’ reasons in reverse order, but first I think it is important that at the heart of all this we are talking about IT service management. Service management is all about delivering (IT as) a service to the customer: a fixed-price, black-box, repeatable, guaranteed, managed & measured value.

This immediately invalidates any reasoning that a new kind of technology (for instance Cloud, BYO) will replace ITIL. ITIL\service management is not about technology, but which processes (\activities) to follow to make sure the technology delivers the benefits (=value) they’re supposed to. So, whilst Cloud and BYOD may make it easier to manage the technology, it is still required to define business value, guarantee the design, transition this, operate it and measure to validate or improve.

Service management is also a ‘best practice’, of which my favourite definition is ‘common sense written down’. And common sense doesn’t really change, so any ‘movement’ or development (like DevOps, return-to-core, rightsize, … even Agile or Lean) can at best only marginally change our opinion of common sense, but not completely invalidate it. Thus they won’t replace ITIL, but provide a different perspective on the guidance it provides.

ITIL is nothing more than the best-known proponent of the IT service management best practice. It has been around for a long time (25 years+), is recognised globally and arguably is the most accepted of the methodologies (certainly in terms of people certified, tools sold and ‘implementation’ performed).

This does not mean ITIL is perfect (despite the nom-de-plum I’ve chosen, even I don’t believe that). I fully recognise the weaker points of ITIL: its generalisms, inconsistencies, less-than-complete or defined strategy processes, its lack of dealing with the real-world (although complimentary publications like the ABC of ICT, Planning to Implement Service Management etc., do a good job of that).

As a consultant (and trainer) it’s these imperfections that make ITIL such as rich source of work: it has to be understood and adapted before it will succeed!

But ITIL has a few things going for it that will make it hard to ‘usurp’ as the leading service management methodology:

· Its ‘completeness’
· Its ‘installed base’

ITIL (since v3) now covers a lifecycle, which means that it just about covers everything you want\need in an IT organisation. Sure, there are some glaring omission (organisation & risk management, or a better defined governance framework) but by-and-large everything is covered.

Many of the other framework focus on one particular element (PRINCE2 for project management, Agile for development, Lean Sigma for process improvement, ISO2700x for security management) which at best makes them complimentary to ITIL, not a replacement.

There are but a few other ‘complete’ frameworks out there. MOF (the Microsoft Operations Framework) is not vendor-neutral and Microsoft hardly has the right audience (too many techo’s, not enough business managers). Plus it is by-and-large based on ITIL anyway. ISO\IEC 20000 is also based on ITIL and its prescriptive nature makes it less friendly to adopt & adept (though together with the additional guidance that is being released it certainly provide a good source of content, perspective and ideas).

This leaves us with COBIT (OK, potentially TOGAF or USMBOK but this is not meant to be an exhaustive comparison). Without going in too much detail, I’d consider COBIT the biggest ‘competitor’ to ITIL. In many perspectives COBIT is better than ITIL (more consistent, contains better governance and risk, provides a quick start, has ‘default’ RACIs, …). In fact if I were to start with a greenfield organisation I might even consider using COBIT instead of ITIL … but, be honest, how often do we come across this.

And so, based on the installed base of ITIL-trained people in the market (including consultants), the number of ITIL-based tools deployed (and/or available) it is very hard to ignore ITIL as the premier service management methodology. Again, this does not mean ITIL is perfect and many of the other frameworks referred to in this blog can be used in conjunction with ITIL, but they’ll not replace it.

Thus the best alternative for ITIL is … an updated ITIL. Which bring us to our last argument: the new joint venture AXELOS who now owns ITIL. A great opportunity lies before them to invest in ITIL (and the other best practices in the portfolio) and bring an update to the market that includes lessons learned in the market, benefits from other methodologies but above all in a consistent package with supporting products (quick guides, implementation guidance, …).

Currently they’re making all the right noises, so I will remain cautiously optimistic that AXELOS will improve ITIL. However, there is a very real risk that AXELOS could instead be the death knell for ITIL too: if they overemphasise the commercial side or focus too much on the UK\home market they will restrict the use and global involvement of the community in the on-going development of these best practices.

In that case I might switch my allegiance to COBIT or USMBOK, but for now I’ll remain the ITIL Zealot.

the ITIL Zealot
July 2013

Common sense written down

Once again I find myself ‘improvising’ this blog, pushed by my self-imposed deadline of two articles a month (I was on holiday in January, hence the ‘lapse’ then). Extra pressure this time, as I've almost breached the threshold of 500 twitter-followers so perhaps this article will add those last few and get me across the line.

The title is my current favourite description of best practice: ‘Common sense written down’. I use this in my training courses, at the beginning. Not just because I need to explain the concept of best practice in the beginning (and the justification of ITIL), but also to take away any anxiety from the students … this is just going to be ‘common sense’. In fact I go as far as sometimes proclaiming that people will not actually learn anything (new) in the course, as hopefully they already possess common sense. Then again common sense isn't all that common, and in some cases (including in parts of ITIL) doesn't actually make sense!

This came to mind when I saw a twitter-discussion recently. It was started by Rob England (@theitskeptic) and a ‘review’ of a CSC Cheat Sheet (http://www.itskeptic.org/content/how-embarrassing-csc). In here it was recommended to start ITIL ‘with a manageable list of 10-15 carefully chosen subsets of the processes’. Rob’s comment was that ‘you are gonna have all of them, like it or not’. This was followed up by Stephen Mann (@stephenmann) who wondered how many organisations do more than 10 ITIL processes, and once again Rob responded with ‘how many DON’T do all (of them)?’

I am with Rob here: common sense is already in place (in most cases, there may be an exception or two) and thus you already DO ALL processes. Using ITIL doesn't mean doing more or less than you are currently doing but you can change and formalise your existing activities to be more aligned to the ITIL recommendations, terminology etc.

The word DO is perhaps wrong here, though not as wrong as the word IMPLEMENT. I have to admit that I too have been part of ITIL implementations, but over the years I've grown to detest this description. For one as it indicates ITIL is a goal and not a means but mostly as it implies a beginning and an end (as in a project). ITIL (or more generically ITSM, service management) is continuous: you did it before you knew ITIL, you’re doing it (better) after you've written some processes and you’ll have to keep doing it after (see also CSI).

We need to once and for all understand that ITIL is DESCRIPTIVE. It describes a perfect world, greenfield, best practice organisation and none of us will ever do everything, exactly as ITIL describes it. But that it not what it is there for!

The benefit of a best practice, of common sense written down, is that it allows you to verify that the activities you are performing are aligned with this best practice\common sense. Chances are you’ll find that you may not be doing all activities (or not all the time, or not as rigorous as required) or maybe you are doing too many. Thus a best practice like ITIL can help you to become more effective and efficient, not by dogmatically adopting everything it says, but by judiciously adopting your activities & practices (yes Rob, I’m ready to start that discussion) along the described theory.

One of my more recent analogies I use in training (I love analogies as it makes theory more palatable for the students) is that there are yet undiscovered tribes in the Amazonian rain-forest that are using ITIL Incident Management. Not that they would have ever heard of it, or have any procedures, but if something breaks, they’ll fix it!

They’ll notice it (logging), try a quick-fix (initial diagnosis), ask someone else to help (escalation) and end up with a temporary (workaround) or permanent (problem\known error\change) solution.

Writing things down, formalising things into process manuals and procedures (and work instructions and …) is often seen as the key to an ITIL implementation. It is also the ‘downfall’ of many ITIL implementations as it now becomes bureaucracy. I have put my thoughts on this down many times (for instance in http://itilzealot.blogspot.com.au/2012/11/process-for-process-sake.html) so in short: documentation helps to make a process repeatable, manageable and guaranteed (including the activities within). Whether and how much documentation you need depends on your current situation (are your actions already repeatable, manageable and guaranteed?), and the size\risk\complexity of your organisation.

DOING an ITIL process is not determined by whether or not you have formally implemented process manuals, staff training etc. but whether you are following common sense, preferably aligned with the best practice theory. So indeed, as per Rob’s comment: who DOESN’T do common sense (across all lifecycles, processes, …)?

the ITIL Zealot
January 2013