Egg on face from the ITIL Refresh Refresh: we can do better at reviewing bodies of work

The whole of New Zealand was out by 190 metres - we're in the middle of fixing it. No big deal: redraw, rebrand, reprint, redistribute every single topographical map of the country; recalibrate/reprogram some of the GPS devices; run batch programs to change the coordinate position of everything in every database in the country; work really hard to make sure all the emergency services stay on the same page map. Simple really. Harder is telling people it is happening: nobody I speak to even knows. It would have been a little simpler if they had got it right the first time, but that is unfair criticism since technology has moved on over the however-many decades or centuries since they surveyed it for the last set of maps. The errors took a long time to show up (when GPS became widely used).

Imagine the reaction if it were to come out in a year or so that the latest set of maps is still wrong.

I don't need to labour the point of the analogy with recent events in the ITIL world. After I posted on the ITIL V3 Edition 2 (as we think they might maybe be calling it -why not the "Refresh Refresh"?), let me share some recent comments for you:

First, Vinod Agrasala wrote Get ready for the inevitable: ITIL revision Again! which makes some excellent points [that I missed :(]

the official communication urges the readers (all of us!) not to confuse between “Version” and “Edition”. So this is not going to be ITIL V3.1 or ITIL V4; it is going to be ITIL V3 Edition x...

‘Simplify the Service Strategy Publication’! (The feedback from community says it is too difficult to understand – My question here is what was the outcome of public consultation and reviews of the publication before the launch in 2007? Nobody thought it was difficult to understand?)...

What amount of revision is expected in the training syllabus, courseware and sample exams etc?

This comment from Naird Lonut is worth reading in full

How many people were involved in writing, developing, mentoring, contributing or reviewing the Service Strategy book?...
In addition to the Chief architect and two authors (3 people) there is /was
1. The “ITIL authoring team contributed to this guide through commenting on content and alignment across the set”.
1.1. There are 11 people mentioned here
2. Mentors
2.1. There are 2 mentors
3. “A number of people generously contributed their time and expertise to this Service Strategy publication.”
3.1. There are 16
4. ..”to develop ITIL Service Management Practices ,,, and produce publications of lasting value, OGC consulted widely with different stakeholders throughout the world at every stage in the process. OGC would like to thank the following individuals and their organizations for their contributions”
4.1. There are 25 people mentioned on the ITIL Advisory Group:
5. And finally the Service Strategy book reviewers
5.1. I count 53

So, if 110 are / were variously responsible, accountable, consulted or otherwise involved what did they actually do to help prevent this sad situation?

And this from Pink President David Ratcliffe (also more great comment to be read there, and on David's blog)

I can't help wondering about the pages and pages at the front of the books listing all those folks who assisted with various type of review. So that worked out well, didn't it! What exactly did those people do - other than succeed to get their names linked to the development of ITIL V3? I wonder how many of them will be removing those "ITIL V3 Content Reviewer" statements from their email signatures, business cards and bios!...
if I was a savvy customer I'd be just as likely to ask "How many more revisions will there be before these books, courses and exams are 100% right?" We're already on version 4 of the Foundation exam, these updates will mean version 5. That's 5 versions of a simple product in less than 3 years. When I say "simple product" we ain't talking anything high-tech here. These are 20-40 question multiple choice exams!

Aside: Commenters on this blog and my fellow bloggers elsewhere keep pre-empting my half-written posts (and books - He Tangata was a hot idea a year ago, but it threatens to be old before it is published). The only comfort I draw from this is that I must be attuned to the zeitgeist.

I've reviewed a few books of this type, though not the core ITIL books. This recent debacle highlights how badly we all review them. I offer here some thoughts on reviewing bodies of knowledge, as a contribution towards Continual Review Improvement.

Reading is not reviewing. If you just read a book and say "yep sounds about right, except for the missing colon on p47" you have not reviewed it, not at the rigorous levels required for a body of knowledge that is to provide the foundations for a whole industry for up to a decade.

Some reviewers do a bit more and check for our personal hobbyhorses, our pet key points, and make a fuss if they are not there.

Reviewing must include benchmarking. A few reviewers may compare to another framework. Ian Clayton does that with his own USMBOK but nobody listens to Ian because he's annoying. Perhaps if he'd been invited inside the tent there'd be a lot less errors in ITIL V3, but Castle ITIL is more about being chummy than being right. I wonder how many V3 reviewers cross-referenced ITIL to COBIT? They certainly kept their results secret if they did. What about ASL, MOF, ISO38500, KCS and a raft of other industry BOKs that were around at the time?

Reviewing must include deconstruction. A good way to quickly learn something is to teach it. That works because you must understand it well enough to explain it - it forces you to go deeper than superficial reading. And you must then interact with another person until THEY get it, which forces you deeper still, exposes your own gaps in understanding, and makes you paraphrase and reshape the concepts until they click for the student. How many V3 reviewers tried to teach it?

The BEST way to quickly learn something is to write the training materials and then teach it. How many reviewers deconstructed the book and tried to summarise it or rewrite it or write a training course on it or draw flowcharts or mindmaps or...?

Reviewing must include testing. The analogies between content and software usually work. So why don't we apply all our best practices to releasing content?

Number one best practice that is missing is testing. Current reviewing method is like only testing the non-boundary expected values. If you do nothign but read the book, it is like only testing the same values the author did.

How many reviewers conducted walkthroughs and other simulations to test the viability of the advice in ITIL V3? How many tried teaching the content to people who knew nothing about ITIL? and people who knew nothing about IT operations?

When I pay thousands for books and websites and training to adopt a new body of knowledge, I expect it to be as tested as a software product: not perfect but not broken.

I don't think the failings that are besetting ITIL V3 are unique to ITIL. I'm finding a few doozies in COBIT 4.1. I bet The-Framework-Formerly-Known-As-PRINCE2 has 'em too. MOF is better than Vista. ITIL V2 wouldn't withstand this level of scrutiny. USMBOK has extraordinary consistency because it is the product of one mind (and excellent completeness), but it must have errors. Let this be a learning opportunity for us all.


Golden Shovel behind the Golden Pony?


To successfully review any book it is in my view key you have a basis, a reference for understanding the content and being able to provide a critique, as you say, reading is not reviewing unless its just typo spotting. I was one voice that moaned at the horrible condition of the draft books, as an ATO I was allowed eyes on about 30 days prior. Someone did an amazing job to lick them into the final shape in that time period from a cosmetic perspective and I know I blogged to that somewhere.

I have to agree with David here - it seems certain folks are invited to be involved and listed - its not all one way. I know of at least one mentor who was invited only to have his comments totally ignored. It was my team that represented the itSMF USA view in Dallas. I KNOW what we asked for on behalf of the US and I KNOW we were listened to, but obviously not understood.

As you know, I have lived the subsequent years painted as an ITIL heretic - when what I was trying to do was to run ahead of the ITIL automobile with a red flag to "protect any existing or planned investment in ITIL". ITIL V3 was a failed project. How much it failed will be illustrated by the level of restructuring in the new 'edition'. In strategy they went to the Carnegie Mellon outsourcing model, and away from the origins of service management, which are in Richard Normann's seminal books c1977-2001.

They totally abused the marketing 101 references of Phil Kotler, and Kellogs for Marketing and Strategy, standard references for any product manager in today's service economy and society. Its not all about strategy. Its about customer driven market management - as run by Disney, Amazon, and so many others. IT has no place re-inventing established and proven concepts and methods, tying them up in an ITIL bow and then suggesting you run a business on ITIL concepts! And - where did they get the Golden Pony from (the story is like others misrepresented).

Yes I have been harsh and I will continue to be - because too often I have to carry the golden shovel behind the golden pony and clear up the mess that 'evangelists' and consultants leave after encouraging folks to 'implement' ITIL. This is a product. Its a commercial offering. It is NOT driven by its customer base and primary sponsors - the itSMF. COBIT is completely different is this and other respects. Why the itSMF continues to push ITIL at the higher levels under the mask of ITSM remains a mystery.

To review the usefulness of any such source, including COBIT, the reviewer must have an appetite for using the source, problems they need to address they feel the source can help. Or, the provider of the materials must set that background in place and position and explain the materials in the light of researched problems. Ken Gonzalez spoke to this on the Forrester UK blog of Stephen Mann. ITIL need product manager expertise not project management. Product. It needs to give its customer a voice. It needs to think and act and speak outside-in from the respect it is responding to a need.

The itSMF should ASK its members if and what typ of involvement they require for itSMF to continue to sponsor and promote (using membership money) the framework above others. Or - they should pool their expertise and develop an alternative.... either way - members interests should come first, not sponsors...

What is ITSM community expecting for ITIL 2011

My question here is, what is everybody expecting for the continual improvement efforts??

I know that OGC and TSO are not characterized for having a good methodology for their continual improvement, in fact I believe that the steps they take are really bad but, there is something I know. This is to much better than waiting for two more years to see the update, refresh, new edition or whatever At the end, we will be writing again and complaining about this refresh, update or new edition

I participated as a reviewer for the Service operation Book on the second round of reviewers, I knew that TSO gave us little time, I knew that I had to work on December holidays for this review, I knew that this is not the best way to review a book but that doesn’t matter to me because I knew that it was my opportunity for trying to change things that does not liked me. I sent over 200 change suggestions, but I knew that I was not the only one sending suggestions and that maybe, just maybe some of my suggestions would be considered.

Once again what is ITSM community expecting for this? ITIL is not science, ITIL theory is not reliable, and there is no minimum validity of data. I’ve been working on ITIL research for more than 4 years in order to try to get some reliable and valid data and it will take to me much more years.

COBIT reviewers take note

I hope all those reviewing the COBIT 5 Draft read this post first. I also hope a few of them act on it.

[Special note for OGC: it is entirely possible to actually involve the public in reviewing your product, as I recently suggested]

Underthings all in a bunch?

On some level it's difficult for me to get excited about all of this hand wringing around the 'refresh' (or whatever they decide to call it). Yes, there are many (many) things to kvetch about within ITIL. But isn't this all simply missing the point of it being a framework in the first place?

I suspect that a lot of the whine in this vintage pours forth from people who want it to be 'just so', not requiring any thought, adaptation, etc. prior to application. Good luck with that. Utilized as the starting point it was intended to be, ITIL is great material for beginning a service management effort. It's not the end point.

Conversations and all of the attendant and highly productive thinking, deliberation, deconstruction, etc. are occasioned by ambiguity and contradiction. What's wrong with that? I would certainly hope that any effort to improve service management begins and carries forward with a lot of vigorous back and forth around basic concepts and their applicability in a specific context. In the most basic sense, isn't that what we call CSI?

The basic trade-off at play in the authorship arrangement with ITIL is that the internal coherence of the guidance exists in tension with breadth of its authorship. Both coherence and breadth are important. Personally, I think the gross mass of editorial energy was somewhat insufficient for the breadth of authorship involved. But, I think they hit the elephant...perhaps in the arse, but they hit it nonetheless. Breadth provides fertility. Coherence provides stability. Without fertility, ITIL wouldn't port well to the huge diversity of environments out there. Without coherence, we'd all spend the rest of our time on blogs like this one.

For my money, I think the keepers of the flame caved too readily to the peanut gallery by embarking on this recent revision. There's irony in that, of course. I've not yet seen it, but the rewrite of Service Strategy (at least the first part of it) seems to me likely to become a tragic capitulation. The first half of that book (all sections prior to Service Economics) are really flat out brilliant, coherent, flexible and even wise. Yes, it's challenging. No, it won't get better in the Dummies version. The Service Economics section, by comparison, is pretty average. I'll be sorry for the loss I'm anticipating. And this will all happen in part because of the over-loud grumblings of the 'just so' and 'right now' and 'without any uncomfortable thinking' crowd.

So, what's the boil out? The problem is not in the quality of the revision, but in the fact the revision was allowed in the first place. What's hurry? Let it simmer for a few more years. To the editorial board: grow some huevos and get used to the occasional lobbed tomato. A lot more damage has been done to ITIL by the certification scheme than by the guidance itself. And, true to form, a good part of that damage was done in the name of 'just so', 'right now', and 'without any uncomfortable thinking'.

Flat out wrong

What? The first half of the Strategy book is flat out theory devised form existing sources that were seldom recognized. Service Management has nothing at all to do with what much of ITIL suggests it is. Its origins and some of the luminaries who worked in (service) marketing c1970-1985 started and ended with the customer view.

Its so simple. It requires you define a service system. Its NOT lifecycle management and the established service (management) system used in business marketing includes customer experience management nowadays. In fact ITIL V2 was much, much nearer with its delivery and support core. I just wish they had included the business perspective and ICT books in the Foundation syllabus - that would have demonstrated some level of common sense.

Anyone worth their salt has, or who has completed an MBA program, has been dipped in both Kelloggs for Marketing and Kelloggs for Strategy books - mandatory references for any service (product) manager. Remember, a service is no more than a type of product - period. Add Phil Kotler's Marketing management reference and you have everything you need.....Yet in the Strategy book we see established terms given new monikers, and many great sources - ignored. Normann, Eiglier, Gronroos, Szmigin, Mills, Chase, Bitner, Kotler, so many true experts and industry leaders.

Strategic planning, like any seasoned product manager will recognize, is a elemental task within marketing - (Develop Product/Market Strategy) and activities that go towards forming a product (service) plan. Its all been worked out and I received my training from a marvelous outfit still around today - Pragmatic Marketing, and frankly OGC should have commissioned authors who were skilled product marketers/managers. The service portfolio discussion is a crude representation of the product lifecycle topic. The requirements engineering in the Service Design book has huge elements that belong in the market research and product planning activities.

The strategy book would have had much more acceptance if it had been positioned as an additional consideration. Anyone going into a meeting with business c-level executives risks getting shredded if they use the language of this book....

As for the service economics section - I believe that was the title only - the rest was lumpy financial management theory. There was no correlation between the development cost by feature, move items into and thru the portfolio, and how the information should be used to help decisions as to whether to address a market opportunity, retire a product, or enhance functionality, or even price out resource and support costs caused by expected, and unexpected demand.

I'm sorry - the Strategy book IMHO was no more than an academic exercise to try and IT-ise what the business already does. I wish the rewriters the very best and as I have said previously, I urge them and my fellow ITSMers to recognize and respect we have been living in a service economy since before ITIL V1 was announced.... it needs no re-inventing and most of what is known outside of IT as product/service management is established, in use, and proven.

Please stop educating IT folks in business practices invented by IT. And PLEEEZE stop suggesting ITIL can be used to successfully run a business. Ooh is that a cloud I see...

Hear, hear

Well said, David.

they hit the elephant

I agree with a lot of what you say and I love "I think they hit the elephant...perhaps in the arse, but they hit it nonetheless"

There are two camps here. There are the perfectionist "there shouldn't be this many errors" folk, and there are the "we can't get rich selling service strategy training because it can't be absorbed in two days of powerpoint from a spotty youth in a suit" folk. Don't mix them up.

There are a lot of changes in the Change Log that are pedantic, but there are plenty that are substantial. If ITIL is a point of pontification for fulltime ITIL onanists to argue the subtle nuances all day, then it is indeed fertile ground the way it is. If ITIL is useful guidance to newcomers without needing expensive professional interpreters, then these more fundamental errors are a worry.

I do think sites should seek professional guidance (being one of those guides myself) but that doesn't excuse ITIL from being readable without us and without inducing confusion.

So I suggest they splattered the elephant and a bit of cleaning up is welcome. The dumbing down of Service Startegy is indeed another matter and you hit the elephant on the head with the phrase "tragic capitulation"

Have people actually read the books

You don't have to be a perfectionist to find the number of errors too high. There are just too many major errors.

The big question to me has been why so many ITSM pro's have been willing to accept the books as such. I have a theory that they fall in three categories:

a) They never read the books, they just took a class and studied training materials and listened to presentations praising the new version
b) They read the books but did not understand enough to see the errors
c) They read the book, saw the errors but decided that this is what we have been given and we just have to live with it.

I have never seen the Strategy book as too complex. Utility and warranty became familiar to me somewhere late '90s when my business partner started to study in a doctoral program. I can understand that that part can be a revelation if it is new to the reader. My only complaint of the strategy book is that how many ITSM practitioners really need to consider strategy at this level. Those who are trying to figure out how to handle real life problems and errors do not need to spend time studying Market Spaces and Service Portfolio Management. What they need is useful guidance on incidents, problems and errors. Dumbing down Problem Management has not been helpful.


Failure to connect existing dots

Aale, with respect - the strategy book was not written to serve the existing needs of the ITIL customer base. few if any were ready to take advantage of its academic theory - true, and I agree we all needed more how to on the blue collar stuff. That said, I for one expect ITIL to lead, not follow, and it has done little to help prepare us for cloud computing options, where service subscription rules.

Strategy is deeply flawed. The way utility and warranty were discussed without any relationship to how the customer perceives value, finances, and support, was concerning. It was never properly linked back into product management and service portfolio decision making as to what features and functionality should go into an offering, and how all this cascades into catalogs and agreements. Nor was there any discussion on how to arbitrate between requirements competing for the same resources - fundamental considerations when developing a product (service) plan to drive design and development. There was zero discussion on a must-do - product positioning statements, required to craft meaningful service descriptions.

Need I go on.. not really. So I do agree, they should have stuck to what they knew best, and what most folks wanted - more depth added to ITIL V2.... I cringe at how many IT organizations might have embarked on a service catalog, portfolio and strategy journey minus the customer input and marketing 101 skills.....

Not invented by ITIL


Ok, agree with the criticism of Strategy. You just take it one level deeper but actually spell out what I was trying to comment.

I think the Strategy book was written by some fresh MBA's straight from the business school and they just copied their school books. It has no useful connection to ITIL or ITSM and the WOW-effect comes only if you have not seen those models before. Some people seem to think that ITIL invented all the theory in the Strategy book.


I don't expect ITIL to lead

Agree with all but one point: I don't expect ITIL to lead. My understanding is it is supposed to be about good solid proven practice that can be relied upon to work almost anywhere - Generally Accepted Service Practice GASP. I've blogged before about ITIL's diversions into blue-sky conjecture - that's a dangerous mistake. They might be wrong and lead a whole industry up the garden path. With all due respect to the ITIL authors, they are ordinary folk who got the writing gig, not superhuman visionaries. The wat they get feted at conferences may have convinced one or two of them otherwise, but they aren't infallible. I'd go so far as to say they have no right to be foisting opinion on the IT industry, because of the very great dangers if they're wrong. If it isn't proven it shouldn't be in the books.

I don't what ITIL to lead. Who knows where it might lead us.

The Art of the Possible

We should certainly distinguish between GASP and blue-sky conjecture, but that does not mean there is not a need for the latter as long as

a) It is clearly signed posted as such and doesn't disguise itself as GASP

b) It is written by, or based on the work of, some one with a genuine track record

c) It is written with an awareness of other relevant disciplines outside of IT

I'm tempted to add

d) It is capable of being tested in a well designed business experiment.

There is also knowledge that lies between GASP and blue sky thinking. For instance the boundaries of ITSM are being stretched by innovative or complex business models. Perhaps these instances only require a passing mention in ITIL, or even a warning against adopting them when they are neither needed or cost effective.

James Finister

ITIL books are not the place to toss ideas arond

I don't think a book like ITIL is the correct forum to test or suggest ideas that are not proven, or to push the envelope, any more than say a medical textbook.

I am of course thinking here of my favourite hobbyhorse CMDB. It is salient to note that even the "definitive" book The CMDB Imperative said that no such thing exists in the market, a decade after it was first proposed in ITIL. I shudder to think how much money has been lost chasing what was just a bright idea, and how many vendors have enriched themselves promising to deliver it.

And now we have SKMS....

I'm beginning to think that automating the generation of incident tickets from events is another example of a bright idea that should not be attempted by mere mortals on an earthly budget.

I'm sure we can think of more....

New theory needed to displace old myths

There is a fascinating field of research into Evidence Based Practice in healthcare. It might come as a surprise to us lay people how little of modern healthcare actually fits the criteria for this. I recommend Ben Goldacre's "Bad Science" as a good primer.

The problem with the CMDB as currently represented in ITIL is not that it is essentially new, unporoven theory, but that:

a) It rests on outdated theory that needs to be challenged
b) It ignores contrary evidence from the empirical world

Surely a new version of ITIL would be the ideal place to say

"Sorry chaps, we might have accidentally misled you in the past, but here is the most practical advice we can give you based on what people are really do, and here is how it might be extended to deal with the leading edge of cloud, BYO etc"

The sad truth is that, excellent book though it is, "The CMDB Imperatrive" will not reach the audience that ITIL will.

We also need to be aware that one man's GASP can appear as theory to someone operating in a very different environment - I put the automated raising of events into incidents into that category. I've seen it done well, but it presupposes a relatively stable infrastructure, requires a reliable and well analysed history of possible event types and their probable consequences, and effective control mechanisms to handle exceptions.

The danger we face is that by relying on GASP we reinforce GASP, whether it is right or wrong. The original value of ITIL was in getting organisations to break the loop of "Doing things that way because that's how we've always done it."

I'll reiterate here what I said in my previous post.

- There is a distinction to be drawn between pure blue sky "what if" thinking and leading edge ITSM practice
- The structure of ITIL needs to reflect when it is talking about GASP, when it is talking blue sky and when it is talking leading edge
- Protocols need to be in place to ensure content is correctly categorised, for instance where material from an already established profession is being included it should be reviewed by professionals in those areas.

James Finister

CMDB evidence?

James, further thoughts/elaboration appreciated re:

"a) It rests on outdated theory that needs to be challenged"
"b) It ignores contrary evidence from the empirical world"

Not self-evident to me at least :-)

Charles T. Betz

"In the beginning the infrastructure was formless and dark

...but then ITIL said let there be CMDBs, and lo, there were many false CMDBs but no one true CMDB. Yet the vendors and the consultants saw that the people wanted to believe, so they set up an idol of a gold plated CMDB, and on the forehead of the beast wrote the letters CMS"

OK I know I'm going to be hoist by my own petard here and fall foul of the "Ken Gonzales test of a real ITIL expert" by not quoting chapter and verse. On top of that you might argue that what is really at fault is how what ITIL actually says is interpreted by the false prophets .

So first of all I don't disagree with all that ITIL says about the CMDB/CMS. Section 7.3 of Service Transition, for instance, offers a straightforward account of what a CMS tool should be able to do. Perhaps some of them are still a little ambitious if taken to the nth degree.

Where I believe the underlying view of CMDB that ITIL appears to support is unhelpful, indeed fatally flawed is, for instance:

- Promoting a multitude of CMs specific roles which in turn promotes the idea of a monolithic CMS team that is not truly integrated with other processes
- The design of the CMDB seen as being driven by an independent set of requirements rather than being driven by the needs of the organisation
- The failure to face up to the point Rob will make time and time again - why do we see so few "real" CMDBs that meet the ITIL definition when it is supposedly so central to the ITIL solution.

The result is what we discussed in the CMDB forum at Pink12 - there are CMDBs out there that have consumed vast amounts of resource and all the organisation has to show for it is some reports produced every month that no one really trusts, and some pretty, but out of date, diagrams hanging up next to the wallpaper graphs produced by service level management.

And here I have to do my usual penance and recall that many of the things I'm criticizing now are ideas that I stood up and promoted eighteen or so years ago:

Student "So which ITIL process do you think we should introduce first?"
Me "Well the CMDB is essential for all the other processes...."

What ITIL needs now, he said with the confidence of a further 18 years experience, is an approach to Configuration Management that...oh no, it is just a crazy theory, you wouldn't want to hear it ;-)

James Finister

the 5% and 10% Clubs

Oh I do want to hear theories, just not in the books.

Yes, I've been going through numbers lately, and I'm sticking to my assertion that less than 10% of organisations have an accurate working CMDB that truly tracks impact on services.

And less than 5% of sites actually have a genuine business justification for one, as compared to a geek desire for it.

Practicies survey on CMDB

According to my practicies survey in Finland (sorry, not published in English), 22% say they have a good CMDB and 65% they have one but it has some deficiencies, half of them do not have relationships in CMDB. Still this means that about half have some kind of CMDB and in many cases it is work in progress.

75% think they should invest more effort to the CMDB, only a small minority thinks that the efforts have been wasted. And finally, there is clear positive correlation on the esitimate of the stability and existence of a good CMDB. No CMDB = 20 % good stability, deficient CMDB 50% good stability, good CMDB= 80 % good stability.


Down Chokey

Very interesting Aale but
what is the population you draw from?
how do you sample?
What is the control group?
how do you verify the data? I.e. is it anything more than someone's opinion? who is that person? what vested interest do they have in the CMDB? e.g. the one who decided to spend all that money in the first place?

DOWN Chokey! Get down boy! Back in your cage!
Chokey the Chimp

Yes, yes

I know it is pretty hopeless to do a truly reliable survey on this kind of subject but I'm not selling or proving anything here, I actually expected to see more failures in the answers. In general, those who answer my surveys do not hide failures. Our culture is pretty "spade is a spade", as you put it somewhere. The main weakness is the small response rate which can skew the results.

In this case the stability data comes from another survey on change management.

I cannot say that my results are definitely true but it might be that times are changing, understanfing is increasing and tools are better.


Halo Effect?

I observed in the debate back at Pink 11 that I believe many organisations recalibrate their criteria for success rather than admitting that an expensive CMDB project has failed.

I would add to Skep's list of questions:

What is the view of consumers of information from the CMDB?
What impact did it have on the maturity of other processes and capabilities?
Did it improve the quality of change impact assesment, leading to fewer failed changes?
Did it materially speed it up the time to service requests, resolve incidents and diagnose root causes?
Did it allow the organisation to make cost savingd through rationalisation and contract re-negotiation?

If it did achieve any of the above did it do so in a more cost effective way than alternative approaches such as directccontact with SMEs, contract reviews, ad hoc software audits, auto discovery tools, and service desk scripts?

I'm amazed how often I come across organisations who claim to be at high levels of maturity for change management but at a low level of maturity for configuration management, and sometimes the other way around. How can that be if ITIL is correct? ;-)

Even if there is a correlation between stability and CMDB that does not prove a causal relationship, it could even be evidence that CMDB only works in a stable environment.

And those 75% who think they should invest more - are they sufferring from the sunk cost fallacy and convincing themselves that if they only made a little more effort they could reap the benefit of what they have invested to get so far?

As an outsourcer I would say it is very rare for us to take over a CMDB that is fit for purpose, even when that purpose is more limited in scope than the ITIL model.

James Finister

The mal-informed leading the un-informed

Charles, ITIL theory has outdated from day one and version 1 in that it did not properly take into account pre-existing research work completed by the marketing luminaries of the 1970s, who defined the service concept and 'service management' specifically, as part of the product manager's need to adapt to the service society.

When it did, it only took a cursory glance at work by the service management royalty, inclduing Levitt, Chase, Gronroos, and Bitner to name a few. Lets take the well trodden SERVQUAL model as one example of what it did do when it tried. First, it did not cite where it got the idea from (see page 16 in CSI - 'service gap').

SERVQUAL is a useful if slightly dated model that starts out by stating the customer view of quality is paramount. Gap 1 is that between the customer perception of what they need and what they think they are receiving, and the provider's management perception of what the customer needs. In this simple example within CSI - the failing if ITIL is there for us all to see. It ignited a feverish and extremely valuable debate amongst marketing practitioners and theorists alike.

As for ITIl, it seems they took a well researched quality measurement model and adapted it to their own view, without citing the source, the reasons for the change, or it seems fully understanding why that model rests at the core of many service based quality management systems - customer centricity. As a result, the uninformed are led by the mal-informed. The potential value of introducing IT folks to established and 'accepted' service management theory is lost.

There are many other examples, especially in service strategy and design, where known service management theory that was discussed at length in the business universe, was certainly read by the authors, adapted, mostly without citation, and then misrepresented by some as the only valuable source for service management related 'best practice' guidance.

Setting that aside, if ITIL were presented as a set of opinions from those involved I would have no problem at all - as it helps fuel a valuable debate from which we can all learn. My problem over the years, as I have blogged frequently on as you all know, is that the cottage industry around ITIL has stifled this discussion and opportunity to learn, and progress our common definition of service management as it applies to the challenges of IT. Thats the pity. Until now I suppose given the excellent experiences folks professed from attending conferences such as Pink11 last year.

Right now, today, the business is using and exploiting service management concepts and methods that are based upon the work of the service royalty. They are using these and their subsequent learnings to tackle the challenge of today's service experiential world and strained economy. Do we as ITSM professionals really understand what they have, and continue to use - I think not in most cases. There again lies a damning indictment of the folly of not defining what ITSM truly is - SM applies to IT (Freudian eh?), and compounding the frustration business has with its IT counterparts.

Stretching to apply this to CMDB

Hi Ian,

I am stretching to apply your comments to CMDB. Can you help me understand how they are relevant? I'm sure the references you cite are all excellent, and I have ordered Levitt on your recommendation.

As we have discussed, I do think that CMDB might have industrial antecedents in the concept of Bill of Materials (a commonly mentioned analog) or Bill of Resources (a less common analogy, but I think one that is more correct). Neither of these concepts would seem to invalidate the CMDB concept per se.

Charles T. Betz


The bill of materials is more to do with assembling a product not operating one. I suppose it helps one identify a spare part, but the nearest IT analogy to BOM is a software build.
The theoretical connections aside, few other industries organise a service of such staggering complexity and volatility. A BOM is generally well behaved and stable. The attempt to track IT configuration in real time in IT strikes me - as you know - as exceedingly foolhardy except in extreme cases. I'm all for the theory - it is the practicalities that concern me.

debate happens before the books, not in them

I think it is pretty obvious that I am a fan of robust debate around ITIL :)

But in the books is not the place for it. There are plenty of fluid and interactive forums for debate, even if OGC fails to provide or promote any of them.

Once the debate is settled and ideas have been tried with success, THEn we can think of including them in the books. I disagree that GASP is self-reinforcing. This industry errs on the side of being TOO welcoming of novelty and change.

My best ever reply

It really was, I finally refuted your stance with both blinding logic and emotional resonance. Then just before sending it the cat walked on the keyboard and I lost it all.

James Finister

How a reviewer was expected to do a book in a few weeks

I guess I fall into all three groups: didn't read books properly, read but didn't think enough, read and saw some issues but lived with them. It took me years to get my head round all five books, and as recent blog posts show I still have a ways to go - I'm regularly unearthing unpleasant discoveries and don't for a moment think I'm near finding them all. The majority of things in the Change Log are news to me. How a reviewer was expected to do a book in a few weeks is beyond me, even if they'd worked at it 8 hours a day, which almost none would.

My method for checking

My method for checking things is quite simple. Works for houses, cars and frameworks. Check first those parts you understand well. If you find, rot, rust or crap, it fails. It is a safe guess that if I can spot a problem in five minutes, there are more hidden. Then forget how good it looks and start digging.

With frameworks I start always with help desks which I know best. So far COBIT passed, MOF passed, ITIL V3 failed. When I saw the definition of incident, I knew there were more to find. These were some early findings, It takes more time to notice the missing parts.


Hey - Ease Up On The Elephantacide Will Ya!

David Stucky makes some wise points. (Reminds me of some of Aidan Lawes' rantings about ITIL not being a substitute for a brain).

However I'd stop short of saying "let's not do anything".

Refresh - no. New Edition - yes.

Refresh = It's like what we had last time when we went from V2 to V3. New ways of explaining the same things, new opinions, new diagrams (please no!) and completely new ideas & concepts. All in the name of "further clarification". Not needed - use your brain.

New Edition = Correct the errors. If a term is used in one book and a different term is used in another - pick one (eliminate the inconsistencies). What's the harm in going through the master copy of each book and fixing errors before running them through the presses again? That's why it should be a called a "New Edition" and not a "Refresh".

So I'm with Skep on this one. Get your correcting pens out, but tell the army of new authors, mentors & reviewers to stand down.


yes please, just release a new edition, fix the mistakes.

Reviewer/Editor for ST

When asked to be a reviewer, we were given a terribly short period of time to do it. As a previous comment here has stated, we had no way of knowing whether the changes we suggested were taken into consideration. Being the Type-A person that I am, I actually kept a copy of the document with my comments, and then compared that to what was published. I think that other than mis-spellings, none of my suggestions were considered "correct" enough to make the published edition. We wont' even go into the fact that my name somehow got "missed" in the list of acknowledgements..*sigh*....quality control at it's finest!

Speaking as author, reviewer and tech editor (not of ITIL books)

For one of the early books I helped develop and write, the publisher also listed me as the Development Editor. The book had more than a dozen contributing authors and was over 1100 pages. I didn't ask for the title, they just did it. Why? I suspect this is part of it:

I read the contributions of every author, made sure the content conformed to stated objectives, made sure the voicing was consistent, that each author properly addressed the audience, that the content was accurate, and that the language was readable by the audience. Then insisted the publisher find additional knowledgeable readers to comment on the book to validate what I was doing. We also had a separate Technical Editor. It was the entire team that worked with guidance from me to produce the very successful book. It took a single minded vision to which everyone had to subscribe to make things work.

Ultimately, only 1 person is and can be accountable for the entire 5 volumes. I don't know anything about the development process. I do know from some of the comments I've seen here and elsewhere on the Web, I'm not convinced the process used (a) was the right one and (b) could have lead to anything other than what we have.


Speaking as a reviewer...

...albeit of the Service Transition book not Service Strategy, I would have to say that we were given a ludicrously short time to carry out the review, and got no feedback on whether our comments were taken into account. I made, I think, around 800 comments. Personally I fed back that I was critical of the Service Transition book (sorry Ivor and Shirley) because it seemed unsure of its audience and veered between the academic and the practical.

In contrast, with COBIT we get public exposure drafts in good time to respond to them, and in ISO we if anything spend too long trying to get every last detail correct. The interesting thing for me about the ISO side is how much debate goes on before publication.

I think the very best suggestion you make is: "The BEST way to quickly learn something is to write the training materials and then teach it."


Speaking as a reviewer

I have reviewed one of the ITIL books (Service Operation) and agree both with James Finister and Sceptic, the process was not taken seriously. I have refereed several scientific papers. As you may know there is much debate on the quality of that process. But at least it is, in my experience, done sincerely.
I also was also involved in one of the meetings (with training providers from The Netherlands, Germany and France) that discussed what changes we would like the ITIL update to include (and what not).
If the way the input from both these exercises has been dealt with is typical, then the end result indeed surprised everyone involved.
So don’t take it to hard on those that honestly tried to contribute to the quality of the refresh of ITIL, even though they didn’t succeed because the politics involved (taking back ITIL from the IT Service Management community for commercial reasons) didn't let them.

Syndicate content