I have an ITIL course next week, which has made me start thinking about ITIL again. My experiences of ITIL have led me to the view that it's largely harmful; what am I missing?
Starting with the ad hominem, it arose from the civil service, which does not have a stellar record of IT delivery. Also, it has an institutional dislike of specialists, which I think informs some of the ITIL philosophy.
My first grumbles with ITIL are about jargon; it has a special word for all sorts of things which means you have to be ITIL trained to understand what people are going on about, which I don't think results in clear communication. Also, it insists on talking about "customers"; I think this is harmful because it sets a relationship up between IT and IT's customers, rather than treating colleagues as colleagues who work together in collaboration. It often seems to miss the opportunity for IT to provide some guidance into what the users of a particular service might need.
Then there's the procedural obsession - everything has to have its own Capital Letter Management Process. In my experience, this leads to a lot of process (and water-fall style setting plans in concrete) at the expense of anything that might be considered agile delivery or informal interaction between teams. While in theory ITIL lets you do continual service improvement, this often feels like an afterthought - there's too much weight of procedure to do anything like rapid iterations in collaboration with users. And there tends to be considerable procedural siloization between development and operations, which further makes any sort of rapid deployment / devopsy model difficult.
Finally, ITIL seems to result in organisations where everything has to be Managed and Approved by Management. So you have a Change Management Process which disenfranchises your IT experts, because before they can do anything they have to produce a pile of paperwork which goes to a Change Management Board (made up of management) who get to say yes or no to a proposal. The effect is that your IT experts don't feel trusted to do their jobs (because they aren't) and are disempowered to improve things - you can't scratch an itch quickly, because some remote bit of management has to weigh in before you can actually do anything.
Starting with the ad hominem, it arose from the civil service, which does not have a stellar record of IT delivery. Also, it has an institutional dislike of specialists, which I think informs some of the ITIL philosophy.
My first grumbles with ITIL are about jargon; it has a special word for all sorts of things which means you have to be ITIL trained to understand what people are going on about, which I don't think results in clear communication. Also, it insists on talking about "customers"; I think this is harmful because it sets a relationship up between IT and IT's customers, rather than treating colleagues as colleagues who work together in collaboration. It often seems to miss the opportunity for IT to provide some guidance into what the users of a particular service might need.
Then there's the procedural obsession - everything has to have its own Capital Letter Management Process. In my experience, this leads to a lot of process (and water-fall style setting plans in concrete) at the expense of anything that might be considered agile delivery or informal interaction between teams. While in theory ITIL lets you do continual service improvement, this often feels like an afterthought - there's too much weight of procedure to do anything like rapid iterations in collaboration with users. And there tends to be considerable procedural siloization between development and operations, which further makes any sort of rapid deployment / devopsy model difficult.
Finally, ITIL seems to result in organisations where everything has to be Managed and Approved by Management. So you have a Change Management Process which disenfranchises your IT experts, because before they can do anything they have to produce a pile of paperwork which goes to a Change Management Board (made up of management) who get to say yes or no to a proposal. The effect is that your IT experts don't feel trusted to do their jobs (because they aren't) and are disempowered to improve things - you can't scratch an itch quickly, because some remote bit of management has to weigh in before you can actually do anything.
There are 2 comments on this entry. (Reply.)