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