Five reasons ITIL Version 3 is not "Best Practice"
Over a year ago, the IT Skeptic argued that ITIL is not best practice. Now Version 3 is upon us, has anything changed?
Back then I said best practice is one of those terms where the meaning gets gradually eroded by constant misuse, especially by vendors, analysts and consultants—the phrase gains currency and pretty soon everyone uses it.
By now, “best-practice” has been so abused perhaps it does only mean “we wrote down a way of doing it." But ITIL is two decades old so let us assume that when ITIL was first created they really meant best-practice.
OGC [still] defines best-practice as “Proven activity or processes that have been successfully used by multiple organisations. ITIL is an example of best-practice.”
This strikes me as evasive: What has this to do with “best”?
The itSMF has in the past defined best-practice as “the best identified approach to a situation based upon observation from effective organisations in similar business circumstances.”
Now itSMF have wimped out to something just as limp-wristed: "A Best Practice approach means seeking out ideas and experiences from those who have undertaken similar activities in the past, determining which of these practices are relevant to your situation, testing them out to see if they work, before incorporating the proven practices in your own documented processes."
What do "relevant", "if they work" and "proven" have to do with best?
Wikipedia (the Skeptic’s favourite source of the Zeitgeist) defines best-practice as “a management idea which asserts that there is a technique, method, process, activity, incentive or reward that is more effective at delivering a particular outcome than any other technique, method, process, etc.”
Yes, that is what "best” means, isn’t it? “More … than any other …”. Calling something best-practice is (or was) a brave statement. It led with the chin. “This is superlative. There is no better way of doing it.”
So why are OGC's and itSMF's definitions nowadays so wimpy? Because ITIL isn’t best-practice. It is good practice. It is generally accepted practice. But it isn’t "best."
There are good arguments why ITIL is not the ultimate approach to IT operations:
- It is still improving. Optimal process does not need a refresh.
- We could not know if it were the best, as we have no objective measure of efficacy of ITIL against any other approach.
- ITIL is not based on any rigorous research so there is no proof of efficacy, and there can be no evidence-based process of optimising it.
- ITIL is designed, created, edited and reviewed by individuals, acting as a committee. Although they are highly knowledgeable, experienced professionals, they are still people with opinions and personal biases, and they still need to reach a consensus among several diverse positions. It is hard to imagine this process ever reaching the best result (something about design of camels comes to mind).
- Even if ITIL were best, it is best as defined by a narrow group of people drawn from consulting firms and a university, all from the Western European culture and all working with major corporations.
![Syndicate content](../misc/feed.png "Comments for \"Five reasons ITIL Version 3 is not "Best Practice"\""){kind=small}
Made in New Zealand 
Comments
Don't know enough to KNOW ITIL is or isn't, but...
I don't profess to know conclusively that ITIL is or isn't best practice. I do know that based on personal experience it's close enough. :-)
I do disagree with the 5 reasons given that ITIL isn't.
(1) Yes, ITIL is still improving and that's a good thing. Best practice has to evolve to meet changing market and industry conditions. If it doesn't, it soon ceases to be best practice. In our industry, Moore's Law rules; we use the technology we deliver to manage the technology we deliver. Deming said it a long time ago: "It is not necessary to change. Survival is not mandatory."
(3) David Cannon delivered a seminar I attended at the local ISMF LIG. He said that for the Service Operation volume (he's one of the authors), they interviewed and/or visited more than 60 companies over a 2 year period to gather information for the book. What was included in the book was based on patterns from that research. If what you're seeking is a double blind study, I agree. However, I'd want to know how you propose to conduct such a study.
Would I like to know the companies involved? Yes (I do know at least 2), but as I understand it, anonymity was part of the agreement.
(4) See #3. the books might have been written by a small group, but that doesn't mean the authors and reviewers were the only ones involved. I know from experience having worked on several books (1 as development editor and featured author -- about a long dead operating system), that it IS possible, even desirable, to have a small team actually write the book, but collect information and experience from a much wider audience.
If you're faulting process, I disagree. If you're suggesting the team did it in isolation, again, disagree.
(5) Last time I checked the author list of the core volumes, only 1 was from a university (Carnegie Mellon), and also connected with SEI (for those who don't know, http://www.sei.cmu.edu/). So, it's hard to imaging too many better people to be involved with the Service Strategy book.
Having consultants involved isn't a bad thing! :-) I am an IT consultant, specializing in what today we call IT Service Management, though it wasn't called that when I went independent more than 25 years ago. As such I see more diversity in IT organizations than the average employee. Today I get hired both as a consultant and instructor because of the experience. So... :-)
NOTE: I am NOT claiming that ITIL is or isn't best practice. I disagree with the reasoning, not necessarily the premise. Based on my experience, I believe ITIL V3 is close enough -- and I'm open minded enough to accept an alternative if someone can conclusively demonstrate it to be so in a wide variety of situations and organizations. For now, ITIL V3 is a closer match to what I believe good practice should.
David
best practice
I did say "a" university. It remains true that "all from the Western European culture and all working with major corporations" is true (we can argue for ever as to whether Majid counts as Western or Asian - see comments above). Looking across all the credited contributors, there is sod all representation from small organisations who can't afford the expensive consultants who wrote the books and therefore aren't in their personal networks. There is very little representation from Asians unless you count Aussies as Asians. I'd say government representation looks low.
How many of Cannon's secret contributors were NOT North American we'll never know. What kind of data he gathered we'll never know (was it a friendly chat with "the ITIL guy from HP" or was it serious research into practices?)
My thinking has evolved to now suggest that ITIL is an amalgam of best practice, good practice, generally accepted practice amongst one group, and blue-sky-this-might-be-a-good-idea-once-somebody-proves-it-works practice, with no warning labels to indicate which is which.
And of course ITIL is utterly confused as to whether it is best practice or not.
Finally I think you've successfully argued that anything that was best practice in 2006 is unlikely to be so in 2010 :)
Descriptive framework for ITSM
After a nights sleep... :-)
I think you're attempting to make ITIL something it isn't. You're not alone, too many people are nit picking details ignoring the bigger picture.
ITIL as amalgam or ITIL confused or...
Organizations that "do" ITIL don't get it. The goal is ITSM, not ITIL. Since ITIL is descriptive, not proscriptive, that makes some of the details (and potential confusion or perceived inconsistencies) less important.
I've come to believe that what we need is an understanding of "enough" detail, not all of it. To get bogged down in detail is to lose sight of the overall goal (ITSM). Within limits I think that's one of the benefits of the lifecycle focus it changes the focus from processes (which were easy to take apart) to lifecycle, a very different concept.
David
Horrible, damaging advice - look away!
HEADLINE: "An unproven solution was involved today on Main Street in a hit and run with an undefined problem"
Anyway, I wanted to make a short point here. Too many professionals, claiming ITIL, PMP, Six Sigma and ISO qualifications, are giving horrible advice, no dangerous advice to the unwashed in the form of 'implementing ITIL'. Linkedin is full of this and I have spent another week trying to remove sharp objects from the room.
Why do our own peers insist on recommending that punters implement a process, an ITIL 'process' no less, to address a problem (seldom offered or defined), and then continue with a starting process and a 'logical' sequence? Why?
Processes solve nothing. In fact implementing a process without due care and attention should be a felony in our profession. Many seemingly highly qualified consultants are acting like Scout Leaders, lighting fires in a crowded parched forest with hand grenades wearing a blindfold.
Am I off the reservation here? The #1 skill we all should be taught at school (after breathing and playing the proper football) - is how to define a problem and its impact upon stakeholders - giving us a reason and accelerant for change (improvement).
If 60 companies were canvassed for the Service Operations book they were likely in search of a solution too - I doubt they had the answers because Problem Management remains largely as per Version 2 - and lacking vital concepts and know-how. We also saw Problem Management remain there rather be moved to CSI - where it likely would make more sense alongside the Six Sigma speak and improvement initiative...
Stop offering advice to folks that throws an unproven solution at an undefined problem. As they did teach me at school - 'Stop, Look, Listen' - oh that was for crossing the road... seems to fit though.
Expert doesn't mean qualified to be a consultant
I have some very simple rules I've taught other consultants (and I've operated by them from the beginning).
1. It's not about the technology! If the only way the client can discuss the problem is tool- or technology-based, they don't understand their problem. Similarly, if the "consultant" starts with the notion that a tool (or langauge, or some other technical solution) is the correct starting point, the consultant doesn't get it and is likely to do more harm than good.
2. Understand the context of the problem for the business. What does it mean to the business? What is the impact? What is the urgency? Any doubts about this area, see rule 1.
3. Don't try to treat symptoms, instead discover and solve the real problem.
Corollary to rule 3: The real problem has a business/people basis. If You think it's about tools or not about people or business, go back and review rules 1 & 2.
4. Don't jump to conclusions about people. (You can draw your own conclusions about this rule. I'm not going to elaborate on it :-))
5. If you can't resolve rules 1 through 4, don't accept the contract. Walk away!
* * *
There are 4 simple requirements to have a process:
- It's done on behalf of a customer
- It's designed to produce a specific outcome (for the customer)
- It's triggered by something with specific inputs
- It's measurable with known and published metrics to gauge success delivering outcomes.
These requirements come right out of ITIL. I add 2 more. There has to be appropriate governance and the process has to be designed to be improved.
Without these you don't have a process, you have a joke!
* * *
I can't (won't) speak for anyone else. Implementing isolated ITIL processes is a mistake. ITIL processes are designed to fit into a service lifecycle. Implementing processes without lifecycle considerations is foolish at best.
EDIT: I'm not suggesting that adopting one or more ITIL processes to solve a business problem can't be done. Rather, the mistake is in ignoring lifecycle issues. Don't adopt a process in such a way that it can only function as a soft silo (that was one of the problems with V2). Adopt the process in such a way that if/when related lifecycle processes make business sense, everything can be put together as seamlessly as possible. The concept I'm suggesting is similar to designed software to be both testable and easily changed. It's easier and cheaper to plan for lifecycle transitions, communication, cooperation, etc., than it is to retrofit later.
***
I've run into too many "experts" (and I use the term advisedly) that think certification or some other pedigree of knowledge makes them a good consultant. There's also the category of people who jump to conclusions without listening to get the full story. To both I say: NUTS! I've spent too much time cleaning up the messes left by these clowns!
David
don't see how it applies
I completely agree with what you say but I don't see how it applies to the prior comments - I think David is the first to define the solution in terms of the business requirement
Yes I often have to redirect people who say "we're going to do incident first". ITIL doesn't break conveniently into chunks. In fact that simple piece of advice saves them so much grief and expense I really need to start charging for it. (If you are reading this Nathan...)
If you think LinkedIn has mixed advice, try the Yahoo groups some time, or itilcommunity.com. Squirmingly bad.
Thank you
Rob,
Thank you for your comments and defense. Much appreciated.
David
Interesting times... :-)
OK, "a" university it is! :-) Even so, if I had to pick one university to be involved in ITIL it would probably be CME because of their long connection to the SEI.
It was a rather in-depth discussion with David Cannon, but I don't recall that we specifically discussed research methods.
The thing that bothered me about ITIL V2 (though I admit I didn't recognize it until I saw V3) was that it totally overlooked the life cycle concept. I KNOW from years in s/w development that life cycles exist. So, my gut reaction to V2 was that it missed the mark with respect to best practice. I thought it was a step in the right direction, but seriously lacking.
No, I didn't argue or suggest anything about time frames. I merely said that best practice had to evolve to match changing market spaces. I'm also not suggesting there will or won't be a V4, despite official statement that there won't be (frankly, I think that idea was a bit premature).
ITIL V3 scales in ways that V2 didn't (couldn't) because of the life cycle concept. This means incremental updates will probably do, until the overall change hits some tipping point such that a new refresh is required. I have NO idea when that might be. It will depend on what happens to development processes and how they're used to integrate IT with business. For example, what will happen as mashups and cloud computing become more mainstream. Combine that with whatever traction SaaS (Software as a Service) might gain and...
What was the old Chinese Curse... Something about "May you live in interesting times." It's NOT boring. :-)
David
How about "growing practice"?
Skep,
May not be best practice, but Computerworld reports that adoption is growing:
http://www.techworld.com/news/index.cfm?RSS&NewsID=10838
The article wasn't exactly flattering, but then again, it's representative of what real people (versus talking heads) are saying.
kengon
Do you trust those figures
THose figures for v3 adoption and traing seem very high to me - I wonder if the questions were somewhat ambiguous. 31% clainming to be using v3, but only 10% saying they like the lifecycle approach - doesn't add up to me. And that figure of under 10% liking the lifecycle approach should be really worrying somebody.
Faith in Numbers...
James,
Of course I trust those numbers; after all, I read it in *Computerworld*!!! LOL
OK, OK. On a more serious note, I was not as impressed with the numbers themselves, as I was with the candid comments (or shall I say commentary) that made it into the body of the article.
I also believe you're right. If it were my product that was being represented like that, I'd be sweating bullets (and wondering when I'd be getting fired). I'm thankful it's not!
kengon
Is it really a practice?
This topic - "best or not", has been already discussed, and all the arguments already known. But I'd like to point to the other word of "best practice" phrase - is ITIL really a practice?
Do all those trainers on ITIL Foundation or ITIL Manager or whatever - do they really have any real-life experience in IT Service Management? How many ITIL trainers do you know who implemented processes they so enthusiastic about? Capacity management, anyone?
They present a theory in which they (I hope honeslty) believe. In this case they can use any cliche they like - "best practice", "descriptive not prescriptive", "management framework", "collective experience", "coherent approach", "de facto standard" and so on.
It's just what they've been told.
A proportion of them
Well when I was a trainer I certainly had real life experience of service management, having been lucky enough to have spent the early years of my career in a very professional mainframe shop. In addition, like many trainers, if I wasn't training I was implementing ITIL with clients. Generally though the majority of trainers seem to have a bias towards the old service support processes, rather than the service delivery side of things, and there are a proportion of trainers out there who do seem lacking in real world experience.
Is it theory though? It might be to individual trainers, but when I look back at that mainframe shop we were doing most of what was in ITIL v2 22 years ago. The only major area we weren't doing well was financial managment.
My personal view is that v3 has shifted more towards theory
As a trainer I certainly do
As a trainer I certainly do have many years practical experience and still carry out assignments in the real world implementing what I preach. My experience makes me a better trainer, and my trainer makes me a better implementer. Like James, much of my earlier experience was in mainframe shops, doing most of what I later found out was in ITIL V2 (but after all, ITIL came out of existing good practices). Yes, my experience is biassed towards SS, with my SD experience mostly Service Level Management and some IT Service Continuity Management. But there have never been that many actual Capacity/Availability managers out there - these were just aspects of people's jobs, not jobs in themselves.
There is an issue with inexperienced trainers - more of an issue I think, is the lack of practical experience of those who write the books!
Liz Gallacher
Freelance Trainer and Consultant
does 'best' really matter?
I'm not sure this debate about 'best' or 'good' really matters. If a body of 'knowledge' is published, I can decide what's 'best', what's 'good' and what's not relevant for me.
Frankly, if you're up to your ass in alligators 'halfway decent' may be a significant improvement. If I can rally the troops around a 'vision' and get everyone pulling the rope in the same direction I may not care if it's the 'best'....in fact, ongoing debate about "what's best" only makes belief in the vision more difficult.
'Would you tell me, please, which way I ought to go from here?'
'That depends a good deal on where you want to get to,' said the Cat.
'I don't much care where --' said Alice.
'Then it doesn't matter which way you go,' said the Cat.
'--so long as I get somewhere,' Alice added as an explanation.
Lewis Carroll, Alice's Adventures in Wonderland
Of course we don't want to be road kill, but I'd rather risk grazing a few trees than getting run over. Improvement only happens when you DO SOMETHING.
John M. Worthington
MyServiceMonitor, LLC
ahem...don't they call it good practice now?
Not to disagree, but the trend I see in V3 is more around ITIL provides good practice. You can then use these practices to develop your own organizational aligned best practice.
If everyone uses a best practice in multiple verticals with varying needs, does it not become by definition an average, or baseline. Thats how I use ITIL, as a yardstick and as a compass, to identify what is working well, identify any gaps, then aligning to the drivers in the organization, (business, government, or otherwise) develop solutions to manage the gap.
Best practice means
"Best practice means looking like everyone else"
Mark Di Somma
Wikipedia says ....
... Best Practice is a management idea which asserts that there is a technique, method, process, activity, incentive or reward that is more effective at delivering a particular outcome than any other technique, method, process, etc. The idea is that with proper processes, checks, and testing, a desired outcome can be delivered with fewer problems and unforeseen complications. Best practices can also be defined as the most efficient (least amount of effort) and effective (best results) way of accomplishing a task, based on repeatable procedures that have proven themselves over time for large numbers of people. No where in the article is ITIL mentioned.
You can find plenty other
You can find plenty other Class-B versions:
- "Best practices are good practices that have worked well elsewhere. They are proven and have produced successful results." GSA Office of Policy.
- "Best practices are those that have been shown to produce superior results, have been selected by a systematic process and are judged as exemplary, good, or successfully demonstrated." American Productivity and Quality Center
- "Best practices are systematic processes that have been demonstrated and validated to yield competitive advantage for organizations that employ them." American Management Association
And you'll find others from Gartner, Oxford Dictionary and so on.
Along with the Wikipedia definition, it seems impossible to define "best practice" without creating a tautology or being trite or specious. Deming himself bristled at the term - for many of the reasons demonstrated by the Wikipedia* definition.
This is likely why v3 initiated a shift away from 'best practice' to 'good practices'.
(*Far too much trust is placed on sources like Wikipedia. I eagerly await the day where the ITSkeptic evolves away from provincial topics like this thread and into the bigger, more meaningful IT issues such as "Wikipedia: can't trust it" or "Net neutrality: keeping the telcos honest" or "IT Management and the Manson family: coincidence or consequence?")
This blog will diversify
In the past the IT Skeptic has examined such topics as Web 2.0, call centres , VOIP and open source. I'd like to do more but ITIL and itSMF provide such fertile fields. Something to do with what they sprinkle on them...
Elsewhere I've also looked at topics as diverse as geeks, technological complexity, mindless faith in computers, professional mediocrity, corporate "training", and today's topic: best practice.
The blog will diversify in 2008... promise.
BTW, my V3 books are at work right now so I can't do a review of use (abuse?) of the term best practice, but the new itSMF V3 Introduction pocket book cannot be accused of shying away from it.
ITIL on Wiki
Your use of Wikipedia in the article prompted me to think about the possibilities that might be opened up if itSMF were to make the ITIL books available for Wiki style editing by ITSM practitioners. Would that not be a way of achieving part of their limp-wristed definition of best practice - "seeking out ideas and experiences from those who have undertaken similar activities in the past"?
The results would certainly address at least 3 of your 5 arguments.
But of course OGC and all the rest might not be so sympathetic...
It has been done
It has been tried unsuccessfully a number of times: OpenITIL, the ITIL Open Guide and the ITIL Wiki, not to mention Wikipedia itself
IT Service Management Institute has a forum
Ian Clayton (IT Service Management Institute) has his Forum for discussing the IT Service Management Body of Knowledge. Not a Wiki exactly. But, within certain obvious limits the most open discussion of IT Service Management of which I'm aware.
Based upon the ITSMBOK, but comparisons to ITIL, CobiT, ITAMBOK and others are inevitable.
Isn't it so that for 1) we
Isn't it so that for 1) we can say that optimality is not something that doesn't need a change. Isn't it something ITIL is all about - constant change, etc. Business is changing, new opportunities present themselves, shouldn't the best practice (optimal way of doing things) change, when the things, needed to be done, change?
For 5) I must say that ITIL is becoming quite popular in Asia as well, for instance. Some of the parts of ITIL, including PDCA, are not foreign to modern Asian society.
I don't think 2) and 3) are relevant at all. On the other hand, I totally agree with 4), although I cannot propose a better way of getting things done - too much chefs can ruin the meal, you know.
on what grounds
Hi Kaimar, and thanks for commenting.
I agree (1) is a bit wobbly, but on what grounds do you dismiss (2) and (3)?
As for (5), in the past I have mainly looked at the cultural fit of ITIL from a national or ethnic point of view, but I think there is an even more important cultural mis-match: with organisations that are collaborative/touchy-feely/soft cultures. They see ITIL as a blunt instrument: hard-edged, number-driven, confrontational, personally threatening.
Hmm ... Number (2) is
Hmm ...
Number (2) is something like "we are not sure breathing is the most efficient way to acquire oxygen and we have no way to compare it to other methods". If ITIL has survived, and it has, with no other relevant methodologies on the same level to compare it to, doesn't it show it's the best? Survival of the fittest, etc. It's as with science, we have the best model known to man at all times, although it might prove to be totally ridiculous when more is known (in 10, 50, 1000 years).
In number (3) - evidence can be seen even without 'rigorous research'. If you experience once that method A doesn't really work for you, will you continue using it or will you try to improve/change the method? Or ... if you see that method A is inefficient (too costly, too time demanding, etc.) you should try to improve it. Will you conduct research on this or just use your experience, depends on you (and the resources available).
For (5) I don't think ITIL must act as a blunt instrument at all times. It might make sense to use the blunt instrument on some organizations, where the softness is not an asset, but a threat, to improve the overall efficiency. For the others, ITIL is not a standard - it doesn't have to be implemented (100%). You can choose what to take into use and what not to. If the hard edges don't suit company X, there is plenty of good practice, still, that can be learned and made use of.