Top ITIL Myths
Page 1 of 1
Many IT organizations attempting to increase service levels, decrease costs and improve security look to the ITIL framework for guidance. ITIL, or the IT Infrastructure Library, is widely accepted as the world's leading compilation of IT best practices.
A large and increasing number of organizations rely on ITIL. In the U.S., organizations such as Procter & Gamble, Caterpillar, State Farm and Boeing have shared how they have incorporated aspects of ITIL and IT Service Management into their IT management strategies. However, many misconceptions still exist about ITIL, which sometimes confound even long-time IT practitioners. Here are some of the top ITIL myths and misconceptions, as well as their corresponding realities.
Myth #1: All I need to do is read all those ITIL books.
In many ways, this is one of the most disenchanting myths. Ideally, IT practitioners would finally have their silver bullet to help solve their biggest challenges. The fact that ITIL does not provide a cure-all is probably not a surprise, but understanding why helps clarify how ITIL can and cannot help.
ITIL is a compilation of IT best practices, provided without prioritization or any prescriptive structure. ITIL provides a framework and catalog of IT operational processes, distilled from thousands of man-years of experience.
But even now, ITIL is still not in a form where you can simply distribute the ITIL volumes to your entire IT organization and expect everyone to know what issues to tackle first and what everyone's role should be. However, experienced IT practitioners who have built their own playbook of lessons learned from their own disasters or near-disasters are likely to love reading the ITIL volumes -- they will see in the ITIL reflections of their own belief systems and management practices, and recognize the wealth of the hard-won lessons and processes contributed by other IT practitioners that they can add to their playbook. With these expectations, ITIL can be a tremendous wealth of useful information.
Myth #2: ITIL tells you where to start.
One of the first shocks IT practitioners may receive when researching ITIL is just how big it is. They will discover that ITIL spans seven volumes -- and if they continue to dig, they will find another 34 ITIL volumes that are no longer in print but available for purchase on three CD-ROM sets. Understandably, many find this overwhelming and abandon their ITIL investigation.
Of those who do become proficient in the ITIL framework, many remain very frustrated about where to start implementing ITIL. We recall working with an IT director who embarrassedly admitted that after reading more than 50 presentations on ITIL implementations, he still was at a loss at where to start. Worse, he wasn't sure whether bringing in an external consultant for a risk assessment would achieve his IT process improvement objectives. He is not alone in his frustration.
Kevin Behr, chief technology officer of IP Services, said, "If someone is hearing voices in their head, hopefully you can do more than just pointing them to the library and telling them to read lots of books. Because ITIL is not prescriptive, many find themselves asking what they're supposed to do first."
Happily, you do not need to know all of ITIL to get benefits from it, nor do you need to understand it all to get value. To get started with ITIL, many IT practitioners will start with existing process areas that they already have and want to improve. Most commonly, these will be the key process areas at the core of almost any IT operation: change and configuration management.
In ITIL, these areas are covered as part of the Service Support volume, more popularly known as the "Blue Book." In addition to change and configuration management, the Service Support volume also contains sections covering incident management, problem management and release management processes.
You can go here to order the Service Support ITIL volume or view information on the other ITIL volumes.
Some ITIL purists may argue that the full value of ITIL cannot be realized without a fully accurate service catalog, a centralized service desk, and a comprehensive configuration management database. However, most organizations will benefit from improving their existing operational processes before tackling a full service view of IT, which typically will require an executive-level sponsor for organization-wide change.
Myth #3: Because ITIL is just a bunch of books, it must be inexpensive.
After being stunned by the number of ITIL volumes, many are then shocked by the price of the books. Regardless of supplier, the average price of most ITIL volumes is approximately $104, depending on the exchange rate between the U.S. dollar and the British Pound., Buying a complete set of the seven ITIL volumes will cost approximately $728, which may price it out of the range of many those merely casually interested in ITIL. Buying hundreds of copies of books for the entire IT staff potentially becomes cost-prohibitive.
Many have started their ITIL journey with the "itSMF Handbook," an 85-page booklet providing an overview of the key ITIL process areas. This handbook is a great compilation of information, and contains many of the invaluable ITIL process diagrams and terminology guides.
Myth #4: Change management is just for developers. Another challenge facing IT practitioners is ITIL process terminology sounds very similar to that used in software development. For example, for decades software developers have used terms such as "change and configuration management" to articulate how code changes are versioned, coordinated, reviewed, and released. These are well-documented disciplines described in the Capability Maturity Model, developed by the Software Engineering Institute in the 1980s.
However, as many IT practitioners can painfully attest, you can have world-class developers using world-class change and configuration management, but still have horrendous service levels because of poor coordination with IT operations. Changes and updates made by developers may fail, resulting in large amounts of "break/fix" fire-fighting, finger-pointing, and a continuing non-productive relationship between IT operations and R&D.
International Data Corp. says that 78% of all downtime is caused by changes made by duly authorized IT personnel. In order to achieve high availability and reliability, production changes must be managed. Without it, you have extremely little ability to achieve any predictable level of service. There are many places where changes come from, of which software development is only one -- other changes come from patches, maintenance releases, outage remediation and hackers.
An IT operations group is very fortunate when they can work with a mature R&D organization that has good change management processes in place. In these situations, the R&D team will work the IT operations release management and change management teams to coordinate and orchestrate how software releases are deployed into production.
ITIL is a fantastic collection of best practices, and can help IT practitioners improve their game. However, the myths we explored show that ITIL is just like any tool: how well it works depends on the skill and dedication of the practitioner using it. At the core of IT operations are change and configuration management processes -- because of its descriptive nature, those diving into ITIL without being willing to study how their own processes map to ITIL will most likely be disappointed in the results.
For those who want a more prescriptive approach to ITIL, the IT Process Institute is working on a methodology known as "Visible Ops" to help IT practitioners start their process improvement journey. We will write more about this in a future article, but more information can be found at http://www.itpi.org.
Gene Kim is the chief technology officer and co-founder of Tripwire, Inc. He can be reached at email@example.com. George Spafford is an IT process consultant with more than 12 years of experience in business, information technology and project management. He can be reached at firstname.lastname@example.org.