After
my generic, personal introduction, I thought that this time I get down to the
bottom of my love (or perhaps better put: reference) for ITIL. Before we get
anywhere we need to properly define what ITIL is and what it isn’t. ITIL
is, when all the smoke and mirrors are taken away, a set of 5 books. Nothing
more, nothing less.
Nothing more: it is only 5 books and their combined size,
impressive or daunting as it may be, is limited to 1,500 pages (give or take a
few). Now your combined volume of procedures, contracts, work instructions,
agreements, job descriptions, manuals etc.etc. could easily outstrip this. Thus
the first logical conclusion must be that you will need MORE than ITIL.
Back
to it being (only) 5 books. These books are the same for everyone and every
organisation in the world. As such they need to be generic enough to be
applicable to everyone and every organisation in the world, which by extension
means that they are not specifically written for you and your organisation.
Everyone and every environment has its own challenges with different people,
cultures, infrastructure, supporting tools, legacy contracts, customer
satisfaction, politics, … Once again the only conclusion we can make is that
you will need MORE than ITIL (or rather a DIFFERENT ITIL).So, as much as we want, there is no easy ITIL ‘implementation’ (I might get back to my aversion of the word implementation in a future blog), a silver bullet or a setup.exe. The only thing for it is to follow the long and winding road toservice management heaven (see my previous, first blog on this topic).
At
the end of the day, ITIL excels at telling you WHAT to do (as do many other
frameworks, once again a topic for future blogs). The WHAT in ITIL is (mostly)
splendidly described in processes, activities, documents, CSFs\KPIs, functions
etc.etc. But, we’re all after the HOW to do it.
Before
we can get to it, I think it is very important to recognise that ITIL does
explain to us WHY all these things (the WHATs) are necessary. But this is not
always explicitly done and one really needs to not only look for it, and be
open to it (hence perhaps the analogy with religion). The WHY is why (hahaha, a
double-entendre) we have blogs, the itSMF and (good, well-delivered) training. Personally
I see that as my role as a consultant, trainer and now blogger: to (further)
explain the WHAT and WHY of ITIL. As only once you realise the WHY (and the
WHAT), you can figure HOW (in your specific environment\situation) you can
‘implement’ ITIL.
My standard explanation of this is to use the business case as an example (as it works for both ITIL, but also for project management such as PRINCE2). ITIL\PRINCE2 explain that one needs a business case for each project\change proposal and even give a template of what should be in this business case. They even provide an objective (the WHY!) which for the business case to be a decision-making tool for the stakeholders.
So when I put a pool in my garden a few years ago, I most definitely had a business case, which explained to the stakeholder (my wife and myself) the reason, benefits, costs, time & risks. Based on this we could make the decision to go ahead with the pool, but … none of this was actually on paper. In fact of all the 34 defined PRINCE2 Management Products (i.e. documents) we only had 2: a budget in a spreadsheet and my calendar in Outlook. You are not going to get away with this kind of documentation if you are managing a multi-year, multi-million-dollar project across multiple business units and involving multiple suppliers.
The WHAT and WHY are the same (like in ITIL), and understanding these determine the specific, tailored HOW
for your project\organisation\service management process\... This
leads almost seamlessly into the use of documentation & bureaucracy in
ITIL, but I’ll leave that for the next blog.
the ITIL Zealot
May
2012
