To register for an Internet.com membership to receive newsletters and white papers, use the Register button ABOVE.
To participate in the message forums BELOW, click here
I enjoyed your article on ITIL as a 'Best Practice'. I too have wondered about this in the past and felt it important to have a clear picture of how it is defined. Unfortunately your web-site doesn't have a section below for replies - I think it would be a useful addition.
In reply to your useful analysis, I'd make a few points. ITIL has always had continuous service improvement as the basis of 'best practice' - organisations that do this do better than those that don't - so, properly, ITIL itself is a continuously evolving 'best practice'. You're confusing 'best practice' now with 'best practice' over time, two quite different matters. There was a 'best practice' of making glass several centuries ago - it was a carefully guarded secret in Venice. The best way of making glass today is quite different!
You say that Asia is 'experimenting' with ITIL and service management, and that ITIL is euro-centric. My book 'Metrics for IT Service Management' was reviewed (as part of the process of establishing it as 'Best Practice') by people from all over the globe, including Asia. In fact the book was a result of work that I did with Samsung in Seoul in South Korea - so, in this case, Asia was part of the cutting edge in the definition of 'Best Practice' world wide! Samsung's board of directors had selected ITIL because they, after an exhaustive search, had decided that it was the best practice available for Service Management. I know that is only anecdote, but, since this started over three years ago, I think it a little unfair to describe Asia as 'experimenting' with ITIL - Samsung is quite a big company!
It is also worth pointing out that MOF is simply Microsoft's practical implementation of ITIL for some of their software. It seems a bit unfair to criticise ITIL because it isn't an ITIL implementation.
I agree that more rigour needs to be added to ITIL. It has been a practical and pragmetic matter to date. I'm working with the itSMF to create a Journal of IT Service Management that can host peer-reviewed academic research into Service Management and ITIL. I believe that this will provide the foundation required to establish that it is the 'best practice' in particular fields. At the moment we have to rely on the fact that there are no known better methods!
Just for the record, I'm the South African representative on the itSMF committee for publications, the IPESC, though this reply is all my own opinion.
Thankyou Peter for the thoughtful feedback, much better than an incoherent and illiterate response I had recently. Amazing some of the people one finds in our supposedly learned and professional industry... a topic for the IT Skeptic another day.
I understand that "best" is a moving target over time. The glass industry can measure the outcome of their processes. They have tangible metrics such as durability, clarity, cost of manufacture, and number of sales. Considerable research is conducted to close the feedback loop to ensure the practices are moving towards best and that best is getting better over time. And at any point in history best can be defined by numbers, or at least supported by numbers - as there will still be subjective interpretations, and differing bests for differing situations.
ITIL has few tangible metrics to close the loop and almost zero research into those metrics. So I contend that "best" can not be measured and isn't being measured, so the "best" claim is unsupportable. Your idea of a Journal of Service Mangement is exactly what we need to help address that problem - I commend it greatly.
My second contention is that it can't be best simply as a consequence of the process by which it is created. Your book is - with all due respect - an example of the problem, in that the theoretical foundation is derived from your personal experience and the personal experience of the set of people you used as contributors and reviewers. It is the Cathedral model not the Bazaar model (http://www.catb.org/~esr/writings/ca...hedral-bazaar/). And your Journal is what we need to help address that problem too.
My final contention is that using the term 'best" is a bad idea anyway, as it sets unrealistic expectations and sounds pretentious.
On the topic of Asia, I too was in Korea, in 2003, talking to Samsung among others. Small world, innit? I too am Southern hemisphere based, and have a number of colleagues who have been into Asia more often than I. My general impression from them is that the region is less advanced than UK, Europe, Australasia or the USA. Being involved in itSMF I can use the maturity of their itSMF chapters as another metric for the region's advancement. On the basis of those measures, I stand by my assertion that the jury is still out on ITIL in Asia.
I lived, worked and travelled in Asia for several years in the 90s, and have a pretty good understanding of the Cantonese, Han, Singaporean, Indian (north and south), Thai, Karen, Burmese, Filipino and Indonesian cultures. The IT Skeptic is sceptical about whether ITIL will succeed in some of those cultures due to its fornal nature, and its emphasis on accountability, ownership and management by measurement - all of which are anathema to many Asian cultures. Like other Western systems I think it will appear to be implemented on the surface while an entirely different system is in actual effect under the covers, whose existence will only become clear when he results are not as expected.
Of course generalisations such as these don't hold true across the whole region, nor across all companies in a country, nor across all individuals within a company. There are extremely formal and process-centric companies such as Shell who operate very successfully across the region. The Japanese and Koreans have often led not followed in terms of process, at least in some manufacturing industries, automotive being the obvious example.
But broadly, I think ITIL will only be a general success in Asia as a highly modified, localised version ... if at all.
ITIL has few tangible metrics to close the loop and almost zero research into those metrics. So I contend that "best" can not be measured and isn't being measured, so the "best" claim is unsupportable. Your idea of a Journal of Service Mangement is exactly what we need to help address that problem - I commend it greatly.
My second contention is that it can't be best simply as a consequence of the process by which it is created. Your book is - with all due respect - an example of the problem, in that the theoretical foundation is derived from your personal experience and the personal experience of the set of people you used as contributors and reviewers. It is the Cathedral model not the Bazaar model (http://www.catb.org/~esr/writings/ca...hedral-bazaar/). And your Journal is what we need to help address that problem too.
My final contention is that using the term 'best" is a bad idea anyway, as it sets unrealistic expectations and sounds pretentious.
.
I'd think that 'perfect practice' would indeed be a bad idea and pretentious. 'Best' only means, as I've said, the best currently known, which is very different. I think you're reading 'best' as 'perfect' and that is why you, understandably, object to it.
I'm a strong believer in the bazaar model myself - and have been since the early eighties when I, and a friend of mine, produced an APL interpreter over a few months sporadice work.
I think that the metrics that I've produced are far more a bazaar model production than you imagine! It is necessary to agree on metrics in order to benchmark them and, indeed, in order to do research into their effectiveness. The ones I have produced are intended as a starting point - not an end point - something that I make clear in the book. The ITIL Continuous Improvement Process necessarily will discard those metrics that aren't useful and include new metrics that are. I'm working with various groups to set up a benchmarking project that will test these metrics in the fire. That, to my mind, is more the bazaar than the cathedral model. The problem, until the book came out, was that there wasn't even an Aunt Sally to shy improvements or objections against.
I take your point about the Asian model. I'll also be very interested to see how that market develops over time. Just as I'm fascinated to see how the current banking investment frenzy into China will melt down. It is possible to take a strong position about the inevitability of ITIL not taking off or the Chinese economy melting down - but reality is likely to be more interesting than either...
Youy are dead right: Asia is always more interesting than anything we can imagine
I still can't agree about "best" though. Here's what i wrote in the past on this:
I have a concern with the word “Best”. This is an emotive and judgemental term that to me implies several things:
• nothing else is better
• anything else is worse (so by subtle inference there is something wrong with you if you choose to do anything else)
• someone has evaluated it to determine it is best (so by inference it can be measured)
It is clear that is not what “Best” is supposed to mean. It is intended to mean “industry accepted” and “best identified”. The fact remains that the word “Best” means something else.
Youy are dead right: Asia is always more interesting than anything we can imagine
I still can't agree about "best" though. Here's what i wrote in the past on this:
I have a concern with the word “Best”. This is an emotive and judgemental term that to me implies several things:
• nothing else is better
• anything else is worse (so by subtle inference there is something wrong with you if you choose to do anything else)
• someone has evaluated it to determine it is best (so by inference it can be measured)
It is clear that is not what “Best” is supposed to mean. It is intended to mean “industry accepted” and “best identified”. The fact remains that the word “Best” means something else.
That was a quick response! Ex Asia semper aliquid novi, I suppose..
What do you think would be the best substitute for the term 'best practice'?
I haven't got my OED on-line where I am at the moment, otherwise I'd be able to post a definition of 'best' that I think you'd find would be a satisfactory part of the phrase. I'll look it up later in the week.
Omigosh!! Someone better alert OGC! Because they are under the illusion that ITIL is best practice. The title of the red book is "Best Practice for Service Delivery" and the blue book "Best Practice for Service Support"
The OGC website front page says "ITIL® provides a cohesive set of best practice, drawn from the public and private sectors internationally. "
So does the itSMF!! The IT Service Management pocket book authored by Ivor McFarlane and Colin Rudd, who ought to know, and published by the itSMF, starts out with "The advice contained within this guide ... is ... based on ITIL best practice".
Let them know and hopefully it is not too late to fix it in version 3
Exactly. It is a set of best practices, but by themselves they are just methodologies. And of course, each application of these methodologies will always be different from company to company as each company is different from the next. Let me put it like this.. -- beware, sometimes my analogies can be far-fetched -- ITIL by itself is like a blueprint, lets say for a ship. It may say, put the rudder in the back so you can properly steer the boat; and place the bridge strategically so you can see where you're going.. but it doesn't tell you what materials to use or how to glue it together. And while we both may have built this "ITIL boat", if you will, mine may crash and yours may not because each of us "put it into practice" differently. I have been in the IT for 8 years and have unfortunately experienced working for the Titanic of ITIL boats because although the methodologies by themselves make a whole lot of sense, my company didn't put them into practice in a way that made sense.
...if you will, mine may crash and yours may not because each of us "put it into practice" differently.
This is a wonderful quote. Unfortunately, experience is showing that the majority of the boats crash. Just about every enterprise we walk into is having severe problems with the implementation of ITIL. They're all finding the same things...
The cost to implement is very high.
The time to implement is very long.
The complexity of understanding how to implement is very high
The ITIL framework, itself, is loaded with gaps, conflicts/inconsistencies, and flaws.
As ITIL grows, it becomes a major moving target that the typical enterprise will never be able to keep up with.
It's funny how if everyone tries to implement ITIL, themselves, they end up with totally different ships. Yet, if you break down how they manage "product" (i.e. Product Management), they virtually all do the same things, in order to stay competitive. Maybe, one of the key issues with ITIL is that it only worries about the back end of the boat (i.e. production support & production operations), without any mention or understanding of the rest of the boat (i.e. Design, Implementation/Building, Deployment/Distribution, Installation, Instantiation, Execution, Verification, Promotion/Rejection to and from one environment to another, managing Incidents Defects, and Risks in all environment, not just production, etc.)? If you look at the big picture, ITIL seems pretty weak, doesn't it?
I don't necessarily have a problem with ITIL being called a "best practice", as many companies are starting to flock to it, in some way, shape or form, making it a defacto set of best practices because of it.
However, anyone that looks at the bigger picture of running IT like a business, which is the primary premise of ITIL, will see that ITIL is nowhere near what it takes to run yourself like a business. If anything, it sometimes deters from doing so effectively.
There's simply a fine balance between what to take away as useful and what to avoid.
A primary example is "terminology". ITIL's terminology, for the most part is very useful because it gets everyone speaking the same language. Where it fails is when it's inconsistent with its own terminology. (Asset Management is the process of managing Assets... Incident Management is the process of managing incidents... Service Management is running yourself like a busines. I don't know about you but I think something's wrong, here????)
Another example, the idea of a DSL and the processes to manage it are useful. ITIL's specification of what a DSL is and how to manage it will get you into severe trouble.
Another example of a weak point in ITIL is the concept of Configuration Management. Configuration Management, when done properly, is not really a stand-alone process. It's a symptomatic side effect of proper design, proper building/implementing, proper deployement/distribution, proper installation, proper instantiation, proper execution, etc. Having dedicated Configuration Manager, if you can afford one, is not a bad idea, if his/her job is nothing more than to make sure that proper configurations are all in place. However, to say that Configuration Management is a "process" or discipline that needs dedicated headcount is confusing, weak, and downright misleading... causing many enterprises to go down some ugly roads (or build ships that sink).
To get back to the point, though, the bigger issue is not so much that ITIL is being considered as a set of best practices so much as it is that many of the recommendations in the best practices are weak, inconsistent, missing, and sometimes flat out wrong. While ITIL consistently recommends process maturity and constant optimization for improvement, the OGC does not seem to consistently follow these practices for their own best practices, leaving everyone in this boat building limbo.
Because ITIL really is so vague and has so many issues, what I believe all of this really comes down to is that enterprises should not be taking on the implementation of ITIL, themselves. If you haven't done it before and you go out and certify your people in Foundations, Practitioners, or even Masters, it will be no better than you're having read books and being certified on the theory of boat building but having no real experience in the implementation of boat building. In other words, leave boat building to the professional boat builders... If you haven't put in your time as an apprentice, don't touch the tools.
When you buy the ITIL books (or COBIT or ASL or FITS or RUP or ...) you buy blueprints and sheet steel, not a boat.
Get the right people, and get your people right. (And if you can't change your people, change your people).
Then work out your process for attacking process (the shipbuilding techniques, training, shipyard admin, the project plan ...)
Then look at what kind of boat you have now (because even if it is a dugout canoe, you DO have one now) and what it needs to get it to the ship on the blueprints
Then (and only then) work out what technology you need to buy (buy the engines and the sonar, don't try to make them on a lathe)
When you buy the ITIL books (or COBIT or ASL or FITS or RUP or ...) you buy blueprints and sheet steel, not a boat.
I'd venture to say that this is highly optimistic. Blueprints are usually rather complete drawings that you can follow, in detail to build what you're end goal is.
ITIL is nowhere near a set of blueprints. It's nothing more than a set of "phrases". Things like...
You need a boat.
This thing in the back is called a rudder and every one needs a rudder.
You should have a sail.
A good rudder helps you steer the boat.
etc.
There is nothing wrong about these statements but they're far from telling you exactly how to build the boat and what to use to build it. A real blueprint tells you the exact measurements, how things plug together, what materials to use, etc.
What's worse is that there is no understanding of the cost of the boat your building. Anyone that has truly gone down the road of implementing ITIL themselves usually realizes how extremely expensive it is. Trying to align your organization, your people, your roles, your information, etc. along the lines of ITIL is a very complicated, time consuming and expensive effort. And, to top it off, most enterprises get it wrong (or let's say... at very least get it "very incomplete").
I honestly believe that if you want to run yourself like a business, you will need a lot more than ITIL. And, to do it right, you will actually have to intentionally ignore pieces of ITIL, which would lead you very much astray if you followed them.
Oooh now I strongly disagree. the red and blue books alone amount to 700 pages of detailed process documentation. With the other core books and the dozen complementary books there are several thousand pages. I find them very useful and use large chunks as are. other parts need minor changes before use, much as I would move a few doors and bulkheads around building a boat.
This is an extraordinarily detailed body of process knowledge. Please point us to the equivalent body for each of the other Product Management disciplines.
When I was developing a Multi-vendor service management process for a customer of a previous employer, I looked for something that would enable me to identify, at a high level, the key criteria that would assist in mapping various service providers' existing processes to each other. My organisation was the key outsource services provider so I went looking internally first, this helped me to understand the key process sets (as I called them) the customer needed. This was where I stumbled across ITIL - my organisation stated that its Service Managment processes were ITIL based. This is a term I liked.
I did my research on ITIL and discovered that it was indeed a way to assist in the standardisation of processes across providers. Instead of having to map all processes to my employer's processes which were Commercial Secrets - like how many ways can you really mix up Problems and Incidents and call them Secrets.
By using ITIL Service Management and Service Delivery process descriptions and flows I was able to cross reference any process to this base. I was not interested in the day to day work plans - thes are not ITIL. This was when I discovered that ITIL is neither a Roadmap nor a Blueprint - I have been doing Organisational Tranistions and Transformations too long to fall for that trap.
ITIL says "Best Practice", I believe they mean that if your Incident Management process has all of these activities in it and these activies produce these results then you are "best practice" for the moment so don't rest on your laurels as you can always do better. Continuous Improvement should have the effect of improving what you do today. I keep telling my current clients that the SLA's you have today will be no use to you in six months let alone 3 years time when you renew that Contract. Change is inevitable so the "Best Practice" of today is tomorow's packaging.
I can wax on for hours and bore you with details - I will leave that for another day.
"Roadmaps" - I agree. I make a bit of money doing roadmaps for people. The reason ITIL is not a roadmap is simple: the roadmap is different for every organisation, heavily shaped by conditions, constraints and politics within.
But "blueprint"? I'm a bit rattled to find myself defending ITIL :-) but once again, how is ITIL not a blueprint? It has a few bits that will never work in practice (my views on CMDB are pretty clear). That is true of many drawings I have seen. It has some ugly gaps that could use more detail (service catalog springs to mind). Ask the builders of the Sydney Opera House about the original concept blueprints they had to work from.
In general it says: these roles do these processes made up of these activities which relate according to this flowchart to create these data flows in these objects. It also says tell this to management, look for these potential risks, use these KPIs, evaluate tools this way... I'm a bit baffled by what is missing from ITIL that it would need to qualify as a blueprint.
Happy New Year from the IT Curmudgeon
Last edited by The Skeptic; 01-03-2007 at 03:39 AM.
-- ITIL by itself is like a blueprint, lets say for a ship. It may say, put the rudder in the back so you can properly steer the boat; and place the bridge strategically so you can see where you're going.. but it doesn't tell you what materials to use or how to glue it together. And while we both may have built this "ITIL boat", if you will, mine may crash and yours may not because each of us "put it into practice" differently. I have been in the IT for 8 years and have unfortunately experienced working for the Titanic of ITIL boats because although the methodologies by themselves make a whole lot of sense, my company didn't put them into practice in a way that made sense.
ITIL Transition and Transformation
Linear Mode
