ITIL: Don't shoot the message

It seems to me that ITIL is often very badly done (zealous, anal, officious, misdirected, overblown, dogmatic, theoretical, detached...), and people's bad experience results in them blaming ITIL itself. I've recently seen the effect of ITIL on a neophyte and it was positive and enriching: new awareness, new models to help solve challenges, hope for order in the chaos, a resource to help.

I point the finger at book-carrying door-to-door consultants, hype-merchant analysts generating their own industry, and tub-thumping vendors selling out-of-the-box snake-oil to the credulous (yes they share the blame). Don't shoot the message, shoot the inept messengers. Discuss.

[Moved up from comment below:

Yes I think it is always someone's fault when ITIL fails:

  • The vendor oversells the tool or promises out-of-the-box process
  • The consultant preaches theory and transforms nothing
  • Management set unrealistic goals (e.g. "all the ITIL processes in 12 months" as Troy says), or don't fund the efforts, or don't provide other support, or lose interest
  • The work is handed to contractors whose measured deliverable is paper produced and project milestones passed
  • The buyer-practitioner ignores expertise or doesn't seek any at all and goes it alone
  • Everyone ignores the people aspects and changes nobody

We all agree ITIL isn't a formula or roadmap so by definition it can't lead us to failure. We walk there ourselves.]


RE: ITIL - Don't Shoot the Message

I've gotten great satisfaction when I've used ITIL to help people solve their business problems. When ITIL is implemented without first defining the business problems you are trying to solve, then it is a recipe for failure.

ITIL's greatest virtue is that it is a process oriented framework. Successful organizations have moved from a silo-based structure to an organization structured around business processes. ITIL just happens to describe processes to deliver IT services, even though ITIL could be used for the delivery of any kind of service.

ITIL is at its core simply a recommended way for IT to organize itself, around processes.

For a consultant, ITIL should just be another tool in their toolbox, along with business analysis and project management tools and techniques, business process design and re-design, Six Sigma, Lean, COBIT, and many others, to help businesses solve their unique business problems.

Those who espouse ITIL as dogma and the one right-way to do things, should be avoided at all costs.

ITIL is not a way to organise

Thanks Lee. I agree with you except for one pedantic point sorry. "ITIL is at its core simply a recommended way for IT to organize itself, around processes". No it isn't. ITIL describes how to operate, to execute, to behave, to measure, and to assign responsibility (though ITIL gets distinctly woolly about roles). Structuring an organisation around ITIL is generally a bad idea. So watch that word "organise".

Organizing is difficult

The right organization model is a very difficult question. Nokia used to be a model for strong process organization. There was local and process organization but the processes had the power and the company was very succesful. Then Jorma Ollila reorganized the company before he left. Now analysts are blaming the complex matrix organization for the corporations inability to answer to market demands. So, if the guy who led Nokia from obscurity to a world leader don't know how to organize his company, who knows?

Sometimes it can be useful to break silos but it is not so easy. When I recommended more internal cooperation a customer commented: We are a large organization, we just cannot talk with everone. That is quite true. A large organization has to be split in to parts, otherwise it will not be efficient. There has to be clear boundaries and there is no simple answer how this should be done.

I just read an excellent piece Managing the Support Staff Identity Crisis It says:

When businesses are small, they organize themselves into clear functional units, tapping experts in each respective function to make sure each unit excels. But as they grow, these businesses tend to reorganize toward a model of corporate accountability. Focused tightly on the bottom line, these companies don't know how to quantify the value of legacy functions, which often evolve into jobs that simply support those departments that drive the bottom line, such as sales...

Paradoxically, seeing themselves as overhead often causes support function employees to go on the defensive, attempting to prove their worth by becoming corporate bureaucrats who enforce sometimes meaningless rules in an attempt to affect the bottom line. This unfortunately leads them to regress into three successive pathologies: rule makers, naysayers, and innovation blockers.

Rather than try to contribute ideas, these employees create rules, regulations, and spreadsheets that enable them to prove that they play a role in the company's bottom line. But too often this basically means that they say no a lot, fixatedly nixing new initiatives, new equipment, or anything novel that would require significant expenditures...

More often than not, support staffers are unhappy about this role. They would rather identify themselves as necessary and important, not as innovation blockers.

The above article does NOT talk about IT or ITIL, its mainly about marketing and HR but it sounds quite familiar, doesn't it?

There are no easy and simple solutions to these questions. It is not only the CIO who would like to have a seat at the top table, marketing, HR, finace and other want there too. A lot dependes on the type of business and the actual circumstances what is the best role for IT in the company. Sometimes it can be important, even strategic, sometimes it is just a backoffice support function which can easily be outsourced.

It is impossible to create a best practise on how IT should be organized but it possible to have best practices for some technical operations. I read another excellent HBR piece about best practices, Avoid the 2 Pitfalls of Best Practices Again, it is not about IT or ITIL. What interested me most is that the concept of best practise is so different from how ITIL uses it. Instead of studying old texts, companies search best practices from the top performers.


organising the enterprise

Those who search best practices from the top performers should read The Halo Effect.

I worked for a company where I used to say we had a tidal organisational model. Every couple of years the tide came in, every couple of years it went out. National model of centralised functional teams. State-based model of distributed multi-functional teams. National model of centralised functional teams. State-based ...

We're way off topic here. The key point is that organising the enterprise is a business management issue, not a service management one.

It is good

I Liked the Halo Effect. Explains some things quite well. It does not mean that you cannot learn from what other companies do.

Skinner's Pigeons long as one also learns from those who do poorly, and base your actions on the differences between top performers and low performers. That was one of the conclusions of the Halo Effect for me: observing top performers alone tells us little. Another salient story is Skinner's Pigeons: we are very good at discerning causality where there isn't any.

Nobody here but us pigeons

Absolutly true, but we don't learn either of those lessons, which is the sad truth that both the halo effect and Skinner's pigeons teach us. I've spoken at length about the halo effect, as you know. What we need is a real world maturity model that recognises when we are falling victim to inadvertent self delusion. Take two examples based on the old Malcolm Baldrige award. Typically an immature organisation would massively overestimate their maturity, whilst a mature organisation would be overly self effacing. If you think you are a world class ITSM organisation then you aren't. If you panic everyday that you aren't a world class ITSM shop then you might just be one... and if not then at least you are being realistic about your baseline.

I don't know about pigeons, but keeping chickens I've discovered that if they keep making a fuss sooner or later you feed a bit like customers really.

James Finister

Don't panic, says the Guide

Panicing everyday is not healthy!

One of the main reasons I have been advocating three as the max number of questions in a survey is the halo effect. I used to do a lot of customer satisfaction surveys and sometimes people started arguing things like competence and skills are different things and we had to put questions of both in the survey. Unsuprisingly the correlation is something like 0.99, i.e. the extra question provides no information. I used to cut the number of questions first to 10 but even that was too much. Either the service is good or bad. If it is good, all the elements are good too and vice versa. Now I have realized that three questions is enough in most surveys. It makes the design of surveys much harder which is a good thing. Unfortunately people seem to think that designing surveys is a brainstorming session where the goal is to come up with the most stupid questions. I have even seen a couple of times surveys where they asked: "What is the maturity of your processes?" James' example explains that is a really stupid question.


Hmm, so it's always the people who fail


Yes, I have seen the enthusiasm too as I have been teaching ITIL for years but a lot of ITIL activities seem to fail. For example:

- setting up a CMDB is difficult, according to your numbers only 5% make it.
- a well working Problem Management process is unusual.
- there are not many IT organizations that can make Change Management happen as described in the books.
- etc.

According to ITIL fans, it is never the fault of the methodology, it's always the "zealous, anal, officious, misdirected, overblown, dogmatic, theoretical, detached..." people who did it.

A good practice model should not have such a high failure rate. In the 90's I started teaching help desk model according to Malcolm Fry's and Help Desk Institute's guidance. The failure rate was practically zero. It seems that a lot of the benefits ITIL brings are exactly the same as what the early adopters of the HDI model got 15 years ago (efficiency, more control, better and quicker solutions, satisfied customers, etc.).

Of course according to some people ITIL never fails, oob projects bring 341% ROI etc. If you ask the people in charge of the ITIL initiative, they usually say it was succesful but if you try to get some evidence, there is none. It is not unusual that the IT manager says that they have implemented several processes but knows only the SD numbers. The other processes seem to run without producing any data.


What's different?

OK I'm intrigued. What's different about the HDI guidance? Why does it work where ITIL doesn't?

And where do i get it? Which of the dozens of HDI books is "help desk model according to Malcolm Fry's and Help Desk Institute's guidance"?

Does it have to be a book?

The HDI model was just an example of a succesfull "best practice" which worked. Remember, that was in the 90's, before we knew about ITIL. Malcolms stuff was actually mid 80's when I started with this.

It was probably a combination of some books, presentation materials, surveys and articles. Well, I don't have the materials anymore, this is several companies later and they got lost somewhere. I did write a book myself but in Finnish, I think local HDI still sells it. Actually it was not that complicated. The basic ideas were quite simple. I remember one person telling me some time after our first help desk conference: "We did everything you told there and it worked fine". That is the point. You could explain it in one day and people could implement it succesfully.


the world has matured

I'm not buying it. I'm not buying that you were teaching anything different to ITIL. It might have been simpler but not different. In fact a fair bit of Malcolm's stuff ended up in ITIL as I recall.

There aren't two different kinds of service management, one that works and one that doesn't. SM is a reflection of how service business works. There may be variations in language and some subtle differences in concept but we're all describing the same animal.

ITIL has grown more advanced and complex as the world has matured. We're not running helpdesks to deal with calls any more. We're managing the services of an organisation, from demand to UCs, from cost allocation to continuity. We can't explain that in a day any more. As you know Aale, it takes a great deal of effort and skill and knowledge to transform any subset of ITSM these days. Hence more failures and hence more danger when it is executed badly. ITIL reflects the world, it doesn't (much) shape it. Or more precisely it overlays on whatever the world is doing at the time. Whether that overlay is helpful or not depends on those doing the draping.

Yes, exactly

Rob, you just got stuck in my example. The HDI model actually was not much different from ITIL. The point was that why it is always the practitioner's fault if it fails?

In my opinion ITIL is a) over complicated b) has serious errors. It is easy to fail. And ITIL does not relect the real world, many have commented that here. Today the reality of IT is very different from the picture painted by ITIL. There are always multiple providers and Business talks directly with them. The world has become more complex and that is why we need a simpler model to manage it. Simplicity has value.

There is also value in ITIL and the key is the idea of integrated processes. If the authors just had been able to recognize what is a process and what is not, if they understood what is the meaning of strategy, etc...

it is always someone's fault when ITIL fails

I agree that ITIL has errors (and I agree on the meanings of process and strategy). Any BOK has errors. That comes back to the abilities and knowledge of those using it, to realise errors are there and deal with them.

I agree that ITIL has become more complex. But much of that comes from integrating material which was always there but ignored. And all of it comes from reflecting the more complex world. COBIT is complex. ISO20000 is complex. USMBOK is complex. if there is a simpler model I look forward to it revolutionising IT management in the near future.

So yes i think it is always someone's fault when ITIL fails:

  • The vendor oversells the tool or promises out-of-the-box process
  • The consultant preaches theory and transforms nothing
  • Management set unrealistic goals (e.g. "all the ITIL processes in 12 months" as Troy says), or don't fund the efforts, or don't provide other support, or lose interest
  • The work is handed to contractors whose measured deliverables are paper produced and project milestones passed
  • The buyer-practitioner ignores expertise, or doesn't seek any at all and goes it alone
  • Everyone ignores the people aspects and changes nobody

We all agree ITIL isn't a formula or roadmap so by definition it can't lead us to failure. We walk there ourselves.

ITIL will look like 80's hairdo

There will be a simpler model. In a few years time the current ITIL structure will look just as sensible as 50's fins and 80's hairdo's.

In the ITSM Portal piece I argue that ITIL kills service innovation. The certification training industry has become a big drag on any best practice improvement. ITIL books contain stuff that was written in the 80's. These concepts are now written in stone by all the certifications. More and more practitioners are beginning to realize that there are two answers to many ITIL certification questions; the right one and the one which earns you a point. ITIL 3.1 authors have reported that they were prevented from fixing problems in the books as that would have been harmful for the training industry.

IT service management is far from ready, there should be a stream of innovations and new knowledge coming. I look at this site as one of those sources. I don't teach itil any more, I teach IT service management good practices, it does not stop me from using itil practices if they seem to be holding water. My model for the customer contact types comes actually from you Rob: I just renamed the classes to: order, problem and feedback. Castle ITIL does not need you as a defender but you are doing a big service to IT service management by keeping this site which has sometimes quite intelligent discussions.

There is nothing new in the failures. We had all those problems with the help desk model in the 90's. The 100% succes rate was true only for those who took the advice and did not believe the out-of-box promises. I suppose many vendors did not realize that there had been a development project before their involvment and when they saw the succesful result, they thought it was due mainly to their product. The local ARS Remedy vendor once told me, "I have realized that our implementations are much easier if you have been there first".


no defender

I'm no defender of Castle ITIL. You know that. We're talkign about ITIL the content here, not ITIL the movement. You've provoked a new blog post, thank-you.


Yes, Skep, it is someone's fault.. That's accountability.

ITIL, Consultants, Vendors, are always easy targets to blame, but ultimately if they are not being challenged to demonstrate experience, results, and outcomes, if statements aren't challenged and commitments not followed up on. Who's fault is that?

The best advice, and I know I have reiterated this before re: ITIL, or any other framework; Guidance for the wise, Rules for the foolish.

If the approach was to simplify things back to basics; customers, services, and simple (not perfect, not end game) processes that deliver those services and automation that actually automates the processes (for less cost than doing it manually) that deliver services to customers - that's business 101 isn't it? Yes, ITIL and others provide guidance to avoid efficiency and effectiveness errors that 'might' be made without them... But if more IT people thought like business people, unhindered by hype, emotion, fear, pride, and focus on what is expected from a business perspective, it would filter out a lot of the bullshit in the industry and begin to reduce the amount of failure that permeates the industry.

Great thread!

John M. Clark

I love the quote: "We all

I love the quote: "We all agree ITIL isn't a formula or roadmap so by definition it can't lead us to failure. We walk there ourselves." This and the memory of how much money has been wasted on so-called ITIL projects reminds me of a great quote from a well respected friend... "Money can't buy everything... but poverty can't buy anything."

My Best,


The International Foundation for Information Technology (IF4IT)
Open IT Standards & Best Practices

Just using as a guide

From my personal perspective.. and I must say I am still learning, but we're taking the ideas and concepts and working them to fit our environment.

So i agree with you, I do think that perhaps too many try to be too exact, too inflexible, it gets too unwieldy, crashes and burns. Your first paragraph states it well, it's a resource to help, and a place for a lot of people to start.

I would never force ITIL 100% over everything we do, as no one solution works for every single situation.

The Blame Game

Hi Rob,

I think many of us have found, throughout our careers, that it's far easier to criticize than it is to come up with the solutions. Criticizing is great, when done in a constructive manner and I agree we can all criticize the OGC, vendors and consumers, alike (and I've been on both the vendor and consumer side). However, we have to hand it to the OGC for not only trying but for acting. Their goals appeared to be commoditization, reuse and education of what should be conventional wisdom associated with particular areas of IT. While the material will never be perfect, as is the case with all solutions created by humans, the bright side is that the OGC have set a standard in how they've gone after identifying and addressing what they believe the issues to be. We can only hope that the OGC continues to improve their offerings and the standards by which they offer them.

As for the inept, I'd like to add that there are those people that are "not-so-inept," who are very intelligent, and that intentionally mutilate the message for their own benefit, whether they be vendor or implementer. In my opinion, these are the ones to really look out for.

My Best,

Frank Guerino

The International Foundation for Information Technology (IF4IT)
Open IT Standards & Best Practices

practical realism

I don't see me pointing any fingers at OGC in this post. I think you read something that wasn't there Frank.

I agree that the problems arise from those who are too smart as well as not smart enough. I think the best results are grounded in practical realism (not Realitsm) and a strong connection to what really benefits the organisation. Which is true of anything in business of course.


Hi Rob,

My apologies. I wasn't implying that you were pointing fingers at anyone and it certainly wasn't intended that way. I was just making the point that I see so many people blaming rather than trying to genuinely solve problems in the same spaces that the OGC tries to address. My biggest issues have not been the things we deem to be incorrect or incomplete with ITIL or even with those that you pointed to as the 'inept'. My own most challenging experiences have come when dealing with very intelligent people who've manipulated the intent of things like ITIL to meet their own personal agendas as opposed to having the genuine intent to improve their enterprises. In my opinion, they've been far more challenging than the 'inept,' especially when using things like blame as a tactic... whether it be blaming the OGC, the material, the vendors, etc.

I hope that clarifies.

My Best,


The International Foundation for Information Technology (IF4IT)
Open IT Standards & Best Practices

Syndicate content