itSMFA 2017 August Bulletin Bulletin - August - 2017 | Page 7

Top 3 Myths,
Mysteries, and Misconceptions
about ITIL
By Erika Flora
Since the beginning of time, the acronyms ITIL and ITSM have been plagued by myths, mysteries, and
misconceptions – some fair, some not. What follows is an overview of the three misconceptions I
hear most often, along with a little clarification of each. Let’s separate fact from fiction, eh?
1.
ITIL is too bureaucratic.
This is the single biggest misconception out there. It’s been
perpetuated by two things, one of which is the fault of those
writing the ITIL books, the other is the fault of those
implementing the concepts.
First, there are 25 ITIL processes described in the books, each
of which has a multitude of elements within it. This is one of
the many challenges involved in writing best practice books
that act as a framework. It’s not unique to ITIL; You’ll see the
same issue with the Project Management Body of Knowledge
(the PMBOK Guide) and the 45 project management processes
defined therein. When you write a book (or entire library, in
the case of ITIL) that lays out every single thing that every
different type of organization anywhere in the world could do,
you necessarily run the risk of people picking it up and
misreading the contents as must-dos. Those who set out to do
every little thing outlined in the ITIL books are destined to fail
– usually quickly and miserably.
In the PMBOK Guide’s defense, it states early on that you have
to tailor everything to the size and complexity of a project. It
wasn’t until very recently, with the publication of the
7 itSMF Bulletin—August 2017
ITIL Practitioner book (a mere ten years after version three
of the ITIL books was published), that ITIL added a similar
disclaimer. Namely, it advised readers to scale or limit
their implementation to include only essential processes -
and that’s exactly what you should do. It’s a shame this
concept wasn’t stressed as part of the ITIL books’ original
release.
This myth perpetuates on the implementation side, as
well, because many organizations try to implement all 25
processes, rather than introducing improvements using a
phased, lightweight approach. Avoid this by looking at the
ITIL books as ways to solve problems or reach goals –
nothing more. Think of them as handbooks or instruction
guides (when’s the last time you tried to make every
recipe in your new cookbook at the same time?). Another
thing to consider (and this may sound obvious but I’m
going for it): Only implement improvements on things that
need fixing. If it ain’t broke – or if it ain’t as broke as
something else – don’t fix it! Also keep in mind that you
don’t need a boatload of people to get it done, so if it does
need fixing, don’t let limited staff hold you back.