I'll defend ITIL when I need to.
These are strange times. I find myself defending ITIL, and defending myself for doing so.
Aale Roos has been winding me up, as he does so well. In a recent comment entitled "ITIL will look like 80's hairdo" he said
ITIL books contain stuff that was written in the 80's. These concepts are now written in stone by all the certifications...
IT service management is far from ready, there should be a stream of innovations and new knowledge coming. I look at this site as one of those sources. I don't teach itil any more, I teach IT service management good practices, it does not stop me from using itil practices if they seem to be holding water...Castle ITIL does not need you as a defender ...
Now the term "defender of Castle ITIL" is quoted out of context and was not meant as it sounds there, but it stung none the less. I'm clearly not.
I'm a balancer of extremes. When ITIL was soaring to the top of the Hype Curve I started this blog to try to calm the frenzy down a bit. Now ITIL is plumetting down the other side of the Hype Curve into the Trough of of Disillusionment, and some of the anti-ITIL rhetoric is becoming as hysterically irrational as the zealotry once was: think Stevie Chambers for example. I don't put Aale in that camp by any means, but sometimes I think he is too hard on the theory or content of ITIL. And I find myself at the other end of the see-saw trying to balance opinions the other way - an odd sensation but a position I'm still proud of. A skeptic resists irrationality anywhere he finds it.
There's a blog post brewing about "the Candle in the Darkness". There are some immutable truths in ITSM that don't change from decade to decade, not as long as we still serve a customer. And some of those truths got lost when the mainframe disciplines spiralled out of control into the distributed age. Just like the Renaissance rediscovered the knowledge lost in the Dark Ages, ITSM brought the ITIL knowledge back from the brink.
Sure some of it is outdated. I spend a lot of time right now thinking about how ITSM in general and ITIL/COBIT/ISO20000 in particular need to respond to what Craig Wilkey has coined "adroit computing" ("agile" is too loaded a word). Parts of the ITSM core BOK may need to be fundamentally restructured but I'm not so sure. I think it is more about re-interpreting the axioms for the new language and culture. The wording and examples of ITIL will look quaint in future - the principles won't.
There is a stream of innovation coming into ITSM. Think Lean and KCS. ITIL is a lagging indicator. It embodies proven and generally accepted practice, or at any rate it is supposed to. It's not supposed to embrace the latest blue sky bullshit (think SKMS or Green IT). All the good innovation will find its way into ITIL and COBIT. We're becoming a very impatient world. Heroin and hookers provide instant gratification. One day we'll re-discover that good things take time.
Perhaps it is just because I live in New Zealand. There is a great line in a Flight of the Conchords episode where a women is yelling at Jemaine abusing him about his "70s clothes" and he mumbles "These clothes aren't from the 70s. They're from New Zealand". Maybe we Kiwis are stuck in a time-warp. If so that makes it hard to explain RWW and Weta Workshops and zorbing and Xero and Beetil. [Google them. That last one is ITSM-related].
Or maybe I'm an old-fart mainframe dinosaur, as Stevie thinks. No, I'm a rationalist skeptic.
Made in New Zealand 
Comments
Don't make ITIL more (or less) than it is...
I recently started re-reading some old papers and books about various aspects of IT. As part of that effort I read Ward Cunningham 1992 OOPSLA experience report: The WyCash Portfolio Management System that included the following:
"Shipping first time code is like going into debt."
At the time the sentence stuck a cord because of a project I was working on behalf of IBM with several developers converting code to OS/2. The rest of paragraph reads:
"A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise."
The message is still valuable nearly 19 years later, consider a Gartner study (circa 2005?) that 87% of incidents were related to change...
Today I see the two (Cunningham & Gartner) with a different lens that includes an outside-in driven approach to IT -- although the term is relatively new, not the approach -- details if anyone wants). I suspect many readers of this blog have seen change-related issues kill the productivity of more than one IT organization (in effect bring it to a stand-still).
ITIL is a descriptive framework, not a cookbook or a body of knowledge (in the prescriptive sense of PMBOK or BABOK). The goal for ITIL is IT service management, not fixing. ITIL is about improving both effectiveness and efficiencies of IT. Success with ITIL depends on organizational change, potentially boarding on a paradigm shift for many IT organizations.
Part of the problem is that too many people think ITIL is an immediate quick fix for everything, just do the processes in the book. ITIL is as much about providing a framework for improving organizational maturity (which obviously includes some individual maturity, too) as it is about anything else.
Getting back to technical debt...
ITIL is about doing more upfront, finding a balance that includes risk management, about not building a better mousetrap because we can, but because it will make the results the mousetrap more efficient and effective at what it's supposed to do: getting rid of mice. But here's the paradox. Most people don't really want the mousetrap to catch mice (because of the clean-up), they want the trap to somehow make the mice less visible.
ITIL can help reduce technical debt, but not if the focus is process, not if ITIL is viewed as a quick fix, not if ITIL is misunderstood.
David
Not the Process or Tool but The Organizational Will
Aale
I am afraid we have a fundamental disagreement about the root of the problem. Someone recently told me that there are no such things as a process or technology problem only people problems. I fully agree!
This week I was speaking with a customer in the energy sector and I was discussing the concepts of ITSM (Service Orientation vs Technology Optimization) with the senior leadership team and they asked me if it was really necessary for the various IT groups to follow a common process. They stated that they were a very siloed organization and they did not understand the need to have a common approach but preferred each group to define their support model they way they best saw fit.
I have seen several organizations make great strides in process improvement and established groups focused on Service Management. Only to dismantle the very structures and processes they initially put in place when new leadership came to power or they needed to continue to feed their cost reduction goals.
Many organizations that undertake programs to improve their IT Service Management processes and service delivery capabilities are frustrated by a general lack of results or the overriding failure to achieve their ambitious goals.
Much of that frustration can be directly attributed to a single, pervading factor: Leadership’s inability or unwillingness to understand that adopting service management concepts and processes within traditional siloed focused IT organizations means some degree of change to a large part of the current function’s structures, work practice, values, and measurement systems.
Contrary to popular belief and practice ITIL projects are not all about documenting processes or buying and configuring an IT Service Management tool!
Certainly these two elements are necessary and even critical but they are still only enablers - not the goal itself.
• Documenting processes is a necessary step due to a quirk of human nature that believes that unless a practice is written down and enforced it remains un-defined and open to argument and interpretation. (Necessary evil – not the goal)
• The Service Management tool certainly contributes to the goal by lifting the process from paper and making it tangible, visible, measureable and hopefully more efficient. (Though not always the case)
So my point is that it does not really matter what the process is or whether you think the ITIL definition is a good one or not. The major issues are not about the process but very much about the Practitioner organization.
Why is it that the Dutch and English have not made any further progress than the rest of the world towards Service Management since they have arguably know about it for longer than many part of the world.
By all rights those countries should be a veritable Shangri La of ITSM / ITIL case studies. They are not!
Why? Because our IT culture & Leadership has not been ready for the enterprise approach to governance and discipline required to manage IT processes consistently across a fragmented and silo based organization structure.
This is a prime discussion on my article.
The ITIL Incident, Problem and Change Dance: http://bit.ly/hP4zXN
Troy
All of them
Troy
Of course the will of the people and the management are important. Let me give an example to explain how I see the case:
A group of people want to hike to the top of a mountain. More accurately, they would like to BE at the top. A gear salesman has assured that his boots and stuff will practically fly them there. The fact is that they will get to the top only if they are willing to walk there. They will fail if they lose their will and determination and those are the most important things. But they need to have proper gear and a good map too. Hiking in the mountains without a good map is a bad idea. I am NOT saying that a map or a guide book is a magic carpet that will fly people to the top and I do not expect it to be flawless. Of course no guide is ever perfect. I'm saying that it is a problem if the map or guide has major errors. Let's say the group has hiked close to the top when they come to a rushing river and see that the bridge shown on the map has washed away years ago and they need to go down and take another route. When they get back to the starting point, the group decides that they will give up. Of course giving up is a people issue but I would blame the map too.
Riitta Raesmaa has just started blogging and there is an interesting quote in her latest article: http://raesmaa.wordpress.com/2010/12/12/are-you-systems-intelligent/ "...we in the business world must focus on knowledge flows, instead of knowledge stocks. A bit paradoxically, in these times when we have huge amount of data available, the most value comes from the tacit knowledge flows."
I think we in the ITSM business should heed that advice. ITIL is a stock of knowledge and most of the knowlegde has been out a long time. A lot of people have used that knowledge and could add to it. The practitioners are creating new best practices and I'm trying to study those. In my ITSM Portal column I suggested that the Service Desk model may be outdated. The most important input to that article comes from people who have been running service desks and customer service in several IT service companies for a long time. They are not big silo based organizations, they are relatively small businesses in a competitive market.
Aale
Some People Don't Know What They Are Talking About!
Ok I am not one to typically rant but I have had it up to my eyeballs with people who say ITIL is dead, dying, or for some reason not relevant! Frankly you don’t know what the heck your talking about!
I don’t care if you call it ITSM, ITIL, COBIT, VAL IT, CMMi, TOGAF, etc. etc. etc. what you are simply taking about is moving IT Management disciplines around Plan-Build-Run activities up some kind of maturity curve from chaos to continual improvement. Today much of our industry operate based on strategy by guesstimation, management by gut feel, and operations by tribal knowledge. What all of these frameworks are, is simply a generally agreed reference model for what the practices should, could look like some day. It was Steve Covey who said “Start With The End In Mind”
What is ITIL or any of the other frameworks for that matter than a reference or picture of what could or should be? ITIL is not some magic bullet, a get out of jail free card or the answer to all problems that face our industry. It is simply a description of generally accepted truths and practices about the business of running an IT shop in a way that will improve the value and delivery of services. This is true no matter how you feel personally about the agencies or structures currently overseeing it.
To say ITIL is dead is basically saying the business of IT Management is dead!
I and many other’s reading this blog have performed countless IT Management assessments on various aspects of the IT Value chain and my experience is that the average maturity for most IT activities, processes etc. is a 1.5- 2.5 on the CMMi maturity scale. In layman’s terms the process is not defined, agreed and is consistent as long as the same people come to work today. ITIL’s definitions “even if you think they need improvement” are so far beyond most organization’s current practices that even to adopt them partially would be a massive improvement on the current reality.
Now to give our industry a bit of credit we are very young in the bigger scheme of things. We have had what? At most 3 decades to mature from an R&D shop to an organization that can be trusted to manage the very lifeblood of the business. (Its data and process automation)
In my opinion most IT shops don’t even know the questions about what it means to be a mature service provider let alone the answers! In fact let me go further and say much of ITIL is beyond most organization’s culture to adopt let alone see the value of. What’s the business case for a Service Catalog, CMDB or and SLA for that matter if your company does not mange by or care about services? A topic I have recorded a short screen cast about at the following link.
Cultural Roadmap For ITSM Adoption: http://bit.ly/dvxAXP
ITIL at least give us an end state to consider and even possibly with knowledge reject, without which any direction will do just fine.
ITIL Maturity
"I and many other’s reading this blog have performed countless IT Management assessments on various aspects of the IT Value chain and my experience is that the average maturity for most IT activities, processes etc. is a 1.5- 2.5 on the CMMi maturity scale. "
... not to mention what the costs are to get it to level 4 or 5 and the staff required... not sure many organizations can afford this...
Isn't there a bit of
Isn't there a bit of self-attribution taking place here?
For instance, perhaps the skew towards "...1.5 - 2.5..." is because mature shops (4 or 5) wouldn't find it necessary to perform an assessment? They never enter your sphere of activity in the first place.
Mature IT Shops
And just how many Mature Enterprise IT Governance shops have you met in life?
I really don't like working as a consultant for my own bank "ignorance was truly bliss" now I stay awake at night wondering how they function with a common strategy or management approach across silos
Maturity
Hmm, I have been using e-banking from the very beginning and that was before internet and I cannot recall a single error or outage that would have somehow caused trouble or financial loss to me. My internet connection has not failed for years other than a couple of hardware problems at my end where their Service Desk was able to tell me which component has failed. This does not mean that these services are perfect. My telco has started to offer IPTV also via the same old copper wire and while their virtual digibox is great, there is no iPad app and the internet version is difficult to use on the iPad ;-)
Actually this silo thing is not at all common among my customers, I suppose there has to be a large organization before you find silos. Nearly all IT organizations I know have outsourced both application development and infrastructure management a long time ago. One of the reasons for the difference in opinions might be that IT organizations are not the same in different countries. A large internal IT operation with mainframes and in-house application deveploment might be a mess. I think the best solution would be breaking it up asap but that would require also that there are mature service providers available which might not be the case in some countries. So maybe ITIL V3 would be more meaningful in that situation.
Aale
I wouldn't say many. But
I wouldn't say many. But more than I can count on two hands.
Investment banks and their capital markets brethren always seem to lead the way. The governance and adaptive process mechanisms they've implemented are quite remarkable. Think about the maturity required, for instance, when you have acres of quant PhDs pushing hourly releases to trading algorithms. Mistakes are transparently expensive. So is sluggishness.
(I do not include the big banks in the above. They tend to bring up the rear.)
Likewise, there have been clients in Aerospace and Silicon Valley (particularly around Stanford) where I could only recommend, "Keep doing exactly what your are doing."
(I'm not referring to Facebook. Good lord, what a mess those folks have on their hands. Excellent example of "Agile gone wild.")
So?
There are 24 million registered companies in the USA. it represents about a third of the world's economy. So lets say 60 million worldwide.
Say half of those are paper companies. That leaves us with 30 million entities that use information. Say only 20 million of them do that electronically. Add to that all the public (national, local and civic) and not-for-profit entities and that would easily double again to say 40M.
the US has 7000 banks. let's say 20,000 worldwide. But only a fraction of those are investment banks. lets say 2000. Chuck in aerospace and Silicon Valley and call it 4000 to make the maths easy. Your experience of high performance IT management relates to perhaps 0.01% of the world's IT entities.
Even amongst the world's top 200 companies, aerospace and investment banking only account for about 10%
Meanwhile over here in the real world ...
You miss the point
The earlier implication was that mature organizations do not exist. They are unicorns.
Once you cross a certain line, many things come into view. Once there was no cure for HIV. Now that a patient has been cured, that statement is no longer an acceptable outcome. Once the first planet outside the solar system was found, many were soon found.
If I can find mature shops in my small corner, then surely there are many more to be found in the "real world."
count organizations, or count economic activity?
I haven't had the time to consider Rob's 5% claim rigorously but given the number of small companies and paper companies it might well be true. And meaningless. The more interesting questions:
What % of economic production in a given country or sector is produced by organizations big enough to have a CMDB?
What % of IT staff in a given country or sector work in organizations big enough to have a CMDB?
What % of ITSMF members and conference goers work in organizations big enough to have a CMDB?
What % of readers of this blog work in organizations big enough to have a CMDB?
My working hypothesis would be that those #s are higher. Interest in the formalization of management practices is a function of scale.
Charles T. Betz
http://www.erp4it.com
Victoria's Secret
I don't dispute the leading edge exist. I too find it as exciting as anyone else. It does form the benchmark to aspire to.
I think the analogy is the Victoria's Secret Fashion Show which I ...er... inadvertently surfed into on the TV last night. Much as i enjoy admiring such freakish creatures, I also acknowledge the very real danger they represent to teenage girls if they come to believe that everybody is supposed to look like that.
I think it's great you can have CMDBs, that must be a thrill. And it's really cool that there are maturity 5 companies out there. But these are aspirational to the majority of ITSM practitioners. For most of the million Foundation-dipped practitioners, there are more realistic pragmatic goals to be attained. Telling everyone they are deficient if they don't have a CMDB or they are failing if they don't get to maturity 5 is not helpful. We end up with bulimic clients, gorging on process and vomiting it all up again.
On that cheery note I gotta go open presents. Merry Christmas!!!
As IT operations people, we get a remarkable insight
Don't work for an airline then :) There's one I worked for (not in NZ or Australia) where I marvel they keep anything in the air.
On the same tack, it's clear why insurance is so expensive. There cannot be a more incompetently and inefficiently managed industry.
Actually i know what Australasian banks are some of the world's strongest - they're quite well managed.
As IT operations consultants, we get a remarkable insight into the intestinal workings of corporations. I think you can make a sound case to act on what you see: sell shares, change suppliers.
ITIL comes at the end of a business outcome
it's not a question of whether you can afford it. it is a question of whether you can cost-justify it.
if you are doing ITIL on faith, because IT thinks it seems like a good idea, then you need to cost justify it.
if you are addressing a business need that has a real Value On Investment, and your portfolio management judges it to be the best use of the funds, then you will get approval to do the work to deliver that value. if the work happens to require increasing process maturity in selected areas then do it. And if the best tool to help increase that maturity is ITIL, then do it.
ITIL comes at the end as an enabler to an initiative that has nothing to do with ITIL and everything to do with a business outcome.
So why is it taking so long?
Troy
It was at a HDI conference in Orlando, in 2002 if memory serves me right, when I realized that ITIL is coming to my market. All help desk software vendors had updated their tools to ITIL compliant. OK, we know the change was mainly in the sales material but they were pushing the concepts and the training and consulting boom started, both in North America and Finland. Now eight years later you say that the processes are still immature which I mostly agree. Actually many Dutch have said the same while their ITIL boom happened much earlier.
My question here has been, why is it always the practitioner's fault if the processes do not work? For example, I have seen that problem management was the most immature process in my small sample of Finnish companies. David told me that Pink has made the same observation from a far larger sample of North American companies. Could it be possible that the fault is not in the people who try to apply ITIL best practice but in the practise itself? I will give my answer to that question in Pink 11 but I suppose everybody will guess it ;-) but some people will be suprised by my arguments.
My method for assessing process maturity has been ISO 20000 which is the subject of my other presentation at Pink 11. The assesment has shown that many of my customers are quite mature in processes where they have not even started looking at ITIL or which do not exist in ITIL. In this I disagree with you, it is possible to achieve mature IT Management without applying ITIL, ITSM is not equal to ITIL.
I have seen that I'm getting a label of being an ITIL hater. That is not the situation. I'm doing ITSM consulting based on ITIL all the time. ITIL has useful parts.
Aale
Stuck in a time warp...
It seems Aale Roos is very passionate about ITIL and wants to update it. I suppose that's good.
I think I'd be careful, however, not to fall too much in the argumentum ad novitatem trap.
ITIL has worked hard to become the established standard. It is the status quo. It is, therefore, likely to be somewhat out of date, a little unfashionable for those who wish to think of themselves as the newest and coolest.
Any such "industry good practice" tends to establish minimal practices, not best practices. ITIL is the Brooks Brothers of IT. ITIL borrows lots of concepts (e.g., Six Sigma, Lean (sort of), Standard Costing) from long-established disciplines.
My problem with ITIL is that it perpetuates the us vs. them, IT vs. "the customer", inside-out view of IT operations. I think that is incredibly damaging.
ITIL is not worth getting worked up about. It is what it is - a set of good practices that serve as a starting point for discussion within your organization. It misses a lot. It is the single us vs. them viewpoint from IT.
The prize is not implementing ITIL. The prize is higher reliability, more consistent acceptable execution - at service price point the customer understands because of cost transparency and accepts. The prize is trust with the rest of the business and joint work towards the corporate goals. Accept ITIL, and other "practices" for what they are - a checklist, guidance - that can help you achieve the prize.
More passionate about ITSM
If I'm passionate then it is about ITSM, not itil. Ron Muns (of HDI) once gave me some kind of recognition award, which was a small framed picture with text about passion, the point being that nothing was ever achieved without it. So maybe it is good. But Rob was observant when he wrote about me winding him up. I do and it makes him come up with better arguments and hopefully helps him to sometimes see things differently?
I agree that the inside-out view is especially damaging in the customer service. The poor user is allowed to make a humble request or report an incident for consideration. Great model for service and cooperation. So, why should anybody study 20 days to become an expert in a framework that contains it?
Aale, Certified ITIL V3 Expert
What makes ITIL v3 an inside-out view?
What makes ITIL V3 an inside-out view that is especially damaging for customer service? Is it where services should be defined as something the business recognizes? Is it around Demand Management that seeks to understand the business cycles. Is it reporting on performance of a service and not just the independent speeds/feeds of networks, servers, applications?
Demand management
Have you ever read V2. You know, they did talk about services there too, that is nothing new. But Demand management is such a nice inside-out term. It is great that I'm not tied to a monopoly service provider who could decide that in the name of demand management, they will set a limit to the number of emails I can send in a day. I suppose that my service provider has sales and marketing people who decide the services they offer.
Not quite
"It is great that I'm not tied to a monopoly service provider who could decide that in the name of demand management, they will set a limit to the number of emails I can send in a day."
Um, they likely do. You just haven't hit the high water mark. Here is a test: Try setting up a SPAM shop, choke their bandwidth and see if they don't request a "demand management" conversation.
Demand management goes both ways.
Excellent question. I don't
Excellent question.
I don't see ITIL taking an "inside" nor "outside" view. (IMHO, both those lenses offer skewed perceptions.)
Rather, ITIL is upfront about taking a "systems" view whereby value is co-created.
I have been wondering about NZ
Innovation comes very slow to itil. I had Greg Oxton 10 years ago in Helsinki explaining KCS in a HDI event. His ideas were then far beyond the pitiable DIKW stuff in ITIL V3.
I do agree itil has value, there are a lot of good things in there. It is just that somebody should dig it out and fix the faults, not heap more manure over it. I would like to see more of that plummeting happening because only a crash of the certifications market will allow the changes needed. The sooner the better.
But about NZ. Sometimes I have wondered if the IT situation out there is behind the rest of the world. It might explain some things... But my knowledge of NZ is minimal and may not be wholly accurate. I have two main sources of information about it. LOR was filmed there so I know how the place looks like. Flight of the Conchords (yes, it is on TV even here) has shown me how NZ people act and speak but does not give much info on NZ IT ;-)
Aale
PS
If you want a similar comprehensive view of Finland, go and see Rare Exports http://www.rareexportsmovie.com/en. Then we can compare our views in PINK 11, assuming we can understand each other's spoken English.
What is there to defend?
I agree with your points. I struggle with ITSM in general trying to understand just what question the whole "movement" really answers. I said recently that ITIL has become Eurospeak for a failed Bataan death march style implementation fails and so now it is "hipper" to refer to it all as "ITSM". Lean, six sigma and other continuous improvement methodologies are also necessary but not sufficient to deliver real IT transformation, in my experience. I believe firmly that it is not a compendium of best practices that delivers high performance but rather a solid understanding of the philosophy and thinking behind the practices of high performers that is crucial. ITIL, ITSM and the whole lot of consensus oriented "good practice" is still far from the realms of proven management science. Matter of fact most real improvement is not rooted in consensus at all..otherwise we would all be doing IT correctly to begin with.
my .02
kb
Problem Whack-a-mole
Here in the US we have a fun arcade come 'restaraunt' (I use that rem very loosely, called Chuckie Cheese. Its a pizza joint with adult beverages and tons of kids game machines. One of my favorites was 'whack-a-mole', where you clubbed the head of any mole that dared pop it out of a hole and scored a point for doing so. One of the most gratifying efforts after a long day at the office.
In today's economy much of IT management is playing problem whack-a-mole (WAM) - "find a problem and make it go away - quickly". This thinking, coupled with some customer centricity, is at the heart of any continuous improvement program, inspecting a situation, defining the findings as a problem based upon the impact upon stakeholders, and mitigating or eliminating the risk of it reoccurring through change.
The bitching about ITIL and ITSM I hear may be in frustration. Instead of adopting a WAM approach - the tendency has been to take a page out of Noah and Kevin Cosner's playbooks (build an Ark and save two of each, and Field of Dreams - build it and benefit will come).
Like Skep, for years folks have labeled me as an 'ITIL heretic', my fault perhaps in how I presented my opinions, but few noticed that behind my leading chin was a clear mantra "... to protect an existing or planned investment in ITIL". There is little wrong with ITIL if its positioned properly - by that I mean its intended use explained accurately - Aiden help me here - "adopt and adapt". IMHO ITIL is to be incorporated into a personal specification or blueprint for an (IT) service management system - for 'system' Google 'holistic system' - do not think tools or software alone. Any other strategy will likely lead your management to a 'Thelma and Louise' moment.
The problem our industry has - is that there is no common template for what represents a customer centric blueprint for a service management system and organization - thats where consultants can provide added value... and where I hope I provide my own. There is also scant know-how about how to avoid the Noah's Ark approach and to build the IT WAM machine... I'm also pretty sure given the huge gaps in the ITIL guidance many refer to, there is a lack of the proper skills to properly define the problems and their impact.
Unless you can personalize a problem so when described it has the effect of a knee in the groin of those you want onside - you will stand alone in your effort to change things for the better... There is no such thing as consensus for change - that equates to no-one taking any individual responsibility - except you! Understand how to personalize impact. Understand whats good and bad about ITIL. Understand the elements of a service management system and how to start looking outside-in, from the customer perspective.
If you do I would suggest you will have a much easier time justifying the use or reference of ITIL and perhaps be more accurate/surgical in your criticism of ITIL, and in specifying what you need out of any future 'editions'. As for the 80s hairdo comment - funny.... remember - hair grows faster than ITIL improvements and you can always shave it off or dye it a color to hide flaws....