How many ITIL experts does it take to change a light bulb? Well, let’s add ‘em up: one to write the strategy, one to design the light bulb exchange service (LES, because we need another acronym), one to transition that service into live use, one to put the LES into operation, and one to (oh, yes) continually improve the LES. But we seem to have forgotten that we also need someone to actually put the light bulb in the socket.
Some will no doubt think this is heresy, but the fact is that ITIL is a process framework. It is not prescriptive (in either ITIL v3 or ITIL 2011, but more on that later), and the books do not actually provide a method for designing services; rather, they provide the (presumably) required processes. The difference is subtle but important, and it is not just splitting hairs.
To keep going with the light bulb analogy, someone needs to know how to change the light bulb (the procedures, the instructions, etc.), not just the processes that exist to govern the overall management structure. But processes are not enough. (In ITIL v3, Majid Iqbal, the author of Service Strategy, pointed out that the intersection between service strategy and service design required some kind of method. He later proposed one, incidentally, arguing that such a method required design to specification and fitness for purpose/warranty. These latter concepts were introduced without substantiating a specific design method.)
Furthermore, ITIL v3 (and ITIL 2011), more so than other versions, is, for the most part, an expression of the authors’ opinions, rather than a debated body of knowledge. That is not a criticism, just a fact. ITIL v1 was overseen by a man with a vision, but it was executed by many, many people, who may not have fully realized that vision. Likewise, ITIL v2 is a body of additional knowledge provided by multiple contributors.
Over the years, ITIL has been lauded and vilified in equal measure. Most of the criticism is unjustified. As is most of the praise. What right do I have to make this statement? As much as anyone else who has been involved with ITIL since the beginning, since being recruited to the ITIL team by its creator, Dr. John Stewart, the man with the vision. John’s objective was to stimulate thought, not create a cult of ITIL, where its templates are considered to be scripture, where “implementing ITIL” becomes a goal in itself, or where you can become an “expert” by passing exams based on a syllabus that is, in turn, based on a narrow viewpoint.
Guidance and Dogma
ITIL was created to be a guide, a documented approach to improving the management of IT infrastructures that could be adopted, adapted, and improved. It was not dogma and none of the iterations (up to and including ITIL 2011) have come close to the depth of the ITIL v1 books. This leads to another point I’ve already hinted at: ITIL v2 was intended to augment ITIL v1, not replace it. Its purpose was to review how the ITIL v1 books had been used, add new ideas or concepts, and unite the process views around a process model, which, in itself, represented a few years of effort and covered some forty-odd pages of detailed models written in the IDEF method. (It’s worth noting that this model started with strategy and ended with operations; ITIL v3 did not originate that lifecycle.)
ITIL v3 does not cover everything you need to know and, as with the other versions, it is not something that you can implement. However, none of this is intended to nail the ITIL v3 books (and the ITIL 2011 update) in an ITIL-shaped coffin. Indeed, much of the prescriptive detail remains valid. As an example, look at the capacity management process. John rejected fifteen versions of the ITIL v1 book until he was satisfied that the book was a fully documented, prescriptive guide (this is also true of availability and cost management, to name but two). In the first iteration, these processes were presented as best practices, not commandments. Useful additions were made in Service Delivery (ITIL v2), though little changed in the ITIL v3 edition. The real issue here is that ITIL v3 represents the entirety of capacity
management guidance.
Talk to any practicing capacity managers (particularly ones who have been around for a while) and ask them what they think of ITIL v3…
Improving the Situation
To begin with, let’s start with the novel idea that ITIL is not a bible, that qualifications do not necessarily translate into expertise, and that all organizations are different, meaning that it is pointless, as well as dangerous, to assume that any of the ITIL guidance, especially templates, can be applied without due diligence. Let’s also make the (radical?) assumption that ITIL is not a best practice outside of the specific domain in which it was created: infrastructure and operations. Much of the confusion surrounding ITIL (and, frankly, the downright abuse of ITIL) has arisen from the misplaced intentions of those who, for whatever reason, have promoted ITIL as a software tool specification, an organizational change mantra, a means of improving applications development, or, worse, a best practice for another domain of expertise. There are myriad useful standards and frameworks. Some are specific, like COBIT, COBOL, SSADM, and PRINCE2, while others are more generically applicable, like USMBOK, ASL, CMM, and eSCM. All have their place; ITIL is not the Lord of the Frameworks.
So let’s ditch the whole idea that you can implement ITIL. You can’t. You never could. There is no independent, or even credible, method or service that could even certify that you have implemented ITIL. If you want to validate your service management improvement project, look to ISO/IEC 20000. It is often recommended that you ensure your suppliers are certified in ISO 20000, not ITIL. Instead, ITIL is more commonly classified as a government good practice that can be used to improve the quality of a service or project, or the governance or management of service portfolios.
Ian Clayton, another ITIL veteran, recommends that his customers implement nothing; instead, the first thing they should do is remind themselves what business they are in, who they serve, and how they can help their customers be successful. Use the light bulb analogy; think about why you need light—and the light bulb—in the first place and you can easily understand why a customer might be upset when there are no lights!
A good next step would be to write a business case (from scratch) that documents how you will use good practices to improve the business, not just IT. Businesses have little interest in incident management (unless, like the police or health services, you have an incident response team, though ITIL is not much use in either case, not without specific and careful interpretation), and even less in CMDBs or CMSs. They also don’t much care for strategies that have no relevance to what they do. Remember, IT is an enabler, and since the business foots the bill for IT, IT better get used to it. Make sure any business benefits are predicated on making IT services more reliable.
Next, identify and document how much you expect to spend (including training and internal improvement projects) and how much you expect to save. A CMS/CMDB is meaningless unless it contributes to the bottom line, whether in demonstrably more-reliable services (downtime is expensive) or quicker response to change requests (and, it follows, more-reliable implementation of changes). When you do this, be sure to communicate in terms the business understands.
Also, it’s worth initiating a program that addresses the inefficiencies involved in designing business services. Identify and document the business benefits and cost savings (since maintenance and change are very costly) that will promote a business case that brings together the right people to design services—not just IT services. Keep in mind that changing a password is not a business service, nor is building a cloud platform or, indeed, provisioning a server. Think innovatively. The best person to talk about a business service is likely to be the person who uses the service: a clerk processing an insurance claim, or a blind or deaf person who relies on online communication.
Designing better services is an enterprise undertaking, and while ITIL can provide much of the framework for the touch points, it is not a software lifecycle, nor, indeed, does it offer much in the way of an agile development method. But it will help you interface with these important lifecycles and explain, for example, why agile development should not be too agile if you want to ensure you have built reliable service.
To wrap up our analogy, it is important to understand that being an expert in ITIL is not necessarily the same thing as being expert in ITSM. One question to ask is, “Why do we need the light bulb in the first place?” An expert will consider this before spending time and money providing a solution that may well be a best practice, but may not be the service the customer actually needed. Standards and regulations play a part here, too: what if what you really need is a qualified electrician? After all, maybe the problem is the socket and the light bulb is just fine. Perhaps the most novel idea is to remind ourselves that customer satisfaction comes first, not ITIL, or “implementing ITIL” or ITSM, or even becoming an expert in anything. What we do is and should be tied to the end result: the right amount of light at the right time, when and where it is needed most.
Brian Johnson joined CA Technologies in 2004. Before that, he was the director of product development for Pink Elephant and a senior civil servant with the Office of Government Commerce. Brian was also a member of the team that created ITIL. Working for the forerunner of the OGC, the Central Computer and Telecommunications Agency, he authored many of the first ITIL books and founded the first ITIL user group, which became itSMF. Brian has authored or coauthored more than twenty titles on ITIL, project management, and related subjects, and he is an international public speaker. But no matter where he is or what he’s doing, he’d rather be playing football.