Why I Hate ITIL So Much – A Response to Greg Ferro

A recent hype on the blogosphere is an essay by Greg Ferro called “Why I Hate ITIL So Much,” in which he blames everything he can imagine on ITIL, PRINCE2, TOGAF and other industry frameworks. I found it quite entertaining when I got it sent to me and at the same time it was a long time since I had read so much nonsense. As you may have learned from my earlier articles on here, I am probably the last person to defend ITIL, but at least I think I know what I am talking about, so will try to counter his “arguments.”

Read Greg’s article first before you continue, it’s worth your five minutes.

The premise of the article is that Greg believes that ITIL causes the workflow to be segmented so that people need to work like machines; that ITIL prevents technological progress; that ITIL is all about control, scope and reporting; that its focus is only on deliverable and cost management; that ITIL causes poor communication and management practices.

 The first objection to his article is that the author does not come up with any tangible proof of what elements of ITIL exactly cause all these issues in the workplace. As a matter of fact, he exhibits so little knowledge of ITIL (not does his LinkedIn profile list any certification), that he probably really doesn’t know what ITIL is really about.

 The funniest example he gives is that of having worked in a project with over 25 ITIL/PRINCE2 Project Managers and only five engineers. And he blames ITIL for it. Believe me, I have been there (I was an engineer myself and have led large engineering organisations for many years), but how exactly does any ITIL process cause a mismatch between numbers of PMs and engineers? Not only does ITIL hardly speak about Project Management (apart from in the Transition Planning and Support process, where in fact a reference is made to PRINCE2), but it does not prescribe nor recommend a number of PMs or other functions to be present in the organisation whatsoever.

 His greatest complaint is about the formation of silos in companies. Again, I have been there, working for one of the greatest stove-piped companies there is. Which also happens to be a company that has no formal ITIL framework in place. As a matter of fact, I have been striving to remove the siloed structure of the company by trying to introduce cross-functional processes, with the help of ITIL as a framework. If there is anything that ITIL implementations should do, it is breaking down the Chinese walls between departments by streamlining processes between them.

 Greg is a fan of Cloud technology (even if Cloud is nothing more than the old ASP (Application Service Provider) + Mainframe (virtualisation) model) and claims Cloud will kill ITSM. As if Cloud infrastructures do not need to be designed, implemented and managed. As if changes made to the infrastructure do not need to be controlled to prevent outages for customers. And he claims public clouds are cheaper because they don’t use ITIL (as if) – so a reduction in hardware and management costs are not factors in cost reductions?

 His arguments go on for a while like this: blame ITIL for the deficiencies of today’s IT companies, even though there is nothing in ITIL that actually causes these deficiencies.

 If ITIL is to blame for anything, it should be for its lack of vision of the human factor – this is why I have written the series of articles about Integral ITSM on LinkedIn. There is a clear need to adapt ITSM to a company’s culture, to improve communication when implementing processes, to make sure people are motivated to change their behaviour by showing them the value of these new processes. All that needs to be taken into account when trying to implement an ITSM framework such as ITIL.

 And there is where we get to the real cause of Greg’s issue: ITIL gets blamed because it is stupid people who implement it. (And because the Foundation training sucks.) I have heard too many people say that whatever they do should be “ITIL-compliant,” whatever that means. ITIL is not prescriptive, it is a recommendation only. And not always a great recommendation (it was originally commissioned by Margaret Thatcher, after all), but one that needs to be adapted to the environment it is applied to. The real issue is that that happens too rarely.

 Greg in the meantime believes that everything will be solved by the newest hype in IT land, viz. DevOps. And he shows a lack of understanding of that concept as well, given that he seems to believe that DevOps gives engineers like himself full freedom to play around with their toys and that those engineers will assume the “responsibility” to deliver value. Instead, DevOps, as the name suggests (Development + Operations) is a philosophy (and nothing more) that wants to make sure there is more contact between developers and the people operating the services in order to make services work better for the end users. Or, as ITSkeptic.org puts it:

a philosophy, not a method, or framework, or body of knowledge, or *shudder* vendor's tool.
the philosophy of unifying Development and Operations at the culture, practice, and tool levels, to achieve accelerated and more frequent deployment of changes to Production.

He should realise that DevOps will probably restrain him more than ITIL ever did, given that he now has the responsibility to take the actual Operations phase into account in what he is doing. This is, by the way, exactly what ITIL promotes as well: Operations must be involved in the early phases of service design and service transition in order for them to be better able to manage the service.

 Greg, instead, behaves like a baby throwing his toys out of his pram when he cannot put something into production right away, because his technological innovation is limited by not having a change window approved. In fact, rather than classically blaming "the system" as an external cause of his discontent, he should realise that it is his own attitude that is holding him back. He is blind for the benefits that a good ITSM implementation, where possible in combination with other philosophies and frameworks such as DevOps and SCRUM, can have for his work environment. Instead he believes he can continue to be the local hero who saves the day based on technology without structure or organisation.