An Englishman, an Irishman and a Scot walk into a bar....

...no it isn't the start of a joke, but a scene in the Bellagio at the start of the Pink11 conference in Las Vegas earlier this year. The Irishman was Patrick Bolger and the Scot was Barclay Rae , two of my fellow presenters on the ITSM Weekly Podcast Rest of the World Edition. The Englishman was obviously me, there to present on ISO 38500 and take part in the CMDB panel discussion chaired by Rob "ITSkeptic" England.

Pinky goes to Vegas

Running into two such  great enthusiastic and  ITSM thinkers right at the start really set the tone for the whole event, even if I could have met them much more cheaply without leaving the UK. In fact in the next hour we were joined by a plethora of ITSM gurus. Those of you who have listened to our post Pink11 podcasts will have realised that Pat, Barclay and I came back buzzing with ideas, and again I want to spotlight some of these over the next few weeks.(Update - those ideas have morphed into the Back2ITSM concept)

Vegas 

OK, by now you will have gone away and checked the link to the conference and worked out that it took place way way back in February. So you'll have two questions.

Number 1 - When is the next Pink Conference?

Number 2 - Why has he only just got round to blogging about this?

Well there are two answers to that. The first is that I've been rather busy with the day job, and the second is that I've wanted to reflect a little before drawing conclusions.

Social Media 
Not only was this a hot conference topic but it also made a huge difference to the conference experience. A lot of facetime conversations were continuations of Twitter based debates. Not only that but in the main sessions there were live Twitter feeds following the #pink11 hash tag, and that hash tag generated a lot of interest. There was also a lot of activity in the blogsphere - Barclay Rae and Matt Hooper both got very excited.

Recording the podcast. Oh the glamour of it all

Here are some of my own initial thoughts, largely focusing on the difference between this event and similar conferences in the EMEA  region.

Back to Basics
I'm going to make a gross generalisation here. At UK ITSM conferences the presumption is we all know what the foundations of ITSM are so we don't bother questioning them, and the result is our thinking about the subject hasn't moved forward for years. At Pink there was an awareness that those foundations aren't as robust as we'd imagined. Some very fundamental issues, such as "What is a service?" and "Do you need a CMDB?" and "Do you really understand problem management?" were addressed. If you think they are trivial questions with answers enshrined in ITIl then I would suggest you probably don't understand the questions. Suffice to say at least one hastily conceived  CMDB project was publicly abandoned following the debate on their value.

Ceiling in the Bellagio's reception 

Not Being Scared to Ask for Help
This kind of leads on from my last point. At UK conferences speakers stand up and tell you what a great job they've done and that they've got all the answers. If you've read my ramblings on "The Halo Effect"  and "Cargo Cults" you'll know my view of that approach. Here there was much more of a dialogue going on between the speaker and the floor, and more discussion between delegates.

Perhaps the extreme example is the overwhelming response Pink and Hornbill have had to their ITSM Extreme Makeover initiative.

Personal Highlights

• Meeting so many ITSM gurus face to face, too many to mention them all
• Sitting on such a distinguished panel to discuss CMDB
• Listening to Captain Mike Abrashoff talk about leadership

Who says Vegas is fake?

If you've never been before I really really recommend that you make the trip to next year's show.

Lessons From Beyond the Clouds

My Adventures in the world of thin client computing


We sometimes forget that IT strategy should be driven by business imperatives, and that those business imperatives don't change just because the technology does.

So when we start to look at Cloud and SaaS from  an ITSM perspective we should always keep those business imperatives in mind. It also helps to remind ourselves that the problems the business want the cloud to solve are existing ones.

One of the most interesting projects I've been involved in recently replaced all the client's desktop computers with thin client devices, accessing all applications over a combination of an intranet and the internet and a mixture of internal and external hosting. The thin clients and the infrastructure were all provided  as part of an outsourcing deal.

It was a fascinating experience with novel technology and as you might expect there were major hiccups along the way. What struck me time after time though  was that the challenges and issues from an ITSM perspective were all old familiar friends, but seen in a new light. As the French say

Plus ca change, plus c'est la meme chose

Let us begin with what the business were trying to do, and this was very much a business led change. 


They wanted:

• Reduced and predictable running costs and total lifetime cost
• Scalability 
• A stable platform to enable rapid roll out of new services 

A longer term requirement was to enable their internal services to be made available to other partners and directly to their customers.

Lots of implications obviously follow from these high level objectives. Not all of them were perhaps realised at the time, and others were over emphasised during the roll out of the project at the cost of reducing the overall benefit delivered. Other objectives were also added on during the life of the project, such as integration with the business's green policy.

What about the service management perspective?

Many of these will already be familiar to you, I'm sure.

Service Transition

A major issue, as with so many projects, was that the project team made decisions with a significant impact on the  quality of service that could not be delivered without seeking the approval of the service management team, 

Testing

Many supposedly key aspects of the service were contractually specified as requirements for service acceptance and as targets for the service once it had gone live, but no effort was made to design and build tests during the project stage. Had an attempt been made to develop tests, and integrate them with UAT then someone might have noticed that many of the targets and service levels were nonsensical or ambiguous .

Targets

What do I mean by the targets being nonsensical? Pay attention because this is extremely important. I mean they were:

• Impossible to measure. I mean logically impossible, not just difficult
• Not relevant to the actual quality of service
• Not measuring what people wanted them to be measuring
• Not within the control of the supplier(s) to deliver

In many case these flaws could be traced back to targets being inherited from previous contracts and SLAs. Although the thin client solution highlighted their short-comings the truth is they were never good measures to begin with.

Those that were impossible to measure were often ones that were not relevant to the new architecture. For instance those measuring performance at a component level that no longer existed, or which were now hidden inside the cloud.

Often these were also measures that even if they could be measured couldn't be consistently mapped on to the customer or user experience. As an example because of  the way the system was designed to dynamically reconfigure itself it could run perfectly well one day with two portal servers unavailable, but the next day just one portal server failing could bring the entire service to a halt.

A far to common failing of targets is the seemingly universal flaw in logic which goes like this:

"I want to measure X. I can measure Y. Therefore Y must tell me about X"

How stupid is that, but we do it all the time. Do you measure average call waiting time on your ACD system? What is it that you actually want to know, measure and achieve? 

Write them down. Now.

Yes, I am looking at you, write down what you actually WANT to know.

Some suggestions:

"Do customers ring off because they get frustrated with waiting?"

"Does the call queuing system work effectively?"

"Do I need more staff on the help desk?"
"Do my users have reasonable expectations of the service?"

"How long does it take from a user first ringing the service desk until they speak to someone who can help?"

"How many customers are unhappy about how long they've had to wait for their call to be answered?"

"How many times does a customer call the desk before their call is answered?"

Now ask yourself if average time to answer recorded by an ACD system answers any of those questions.

A classic I came across on this particular project was that it was two years before the service desk provider let slip that they only counted waiting time after the caller had listened to the "Welcome" message. Their target was to pick up calls within 20 seconds. The welcome message typically lasted 45 seconds. Go figure.

And if you want a service delivered over the internet you can't hold your application supplier responsible for the poor transaction response time experienced by a user living on a canal boat moored in a cutting.  It didn;'t stop the user complaining though.

Contracts

Something I've never understood about ITIL, especially considering OGC's wider role, is that it has never addressed that in the UK most IT services are dependent on outsourcing, and contracts are therefore key.

Where do I begin? Well to follow on from the previous section too many contracts are written with what went wrong the last time in mind, which might be wholly irrelevant today. 

Secondly far too often the parties agree on the words, but not on the meaning of the words, and again I'm afraid that ITIL does not address this. We can all agree that a service change should go to the CAB, but that is of little use if we don't agree what we mean by a change to the service.

Language and the Dramadriehoek

Pardon my Dutch. Customers, users, the retained organisation and different suppliers are rather like the Americans and the British. They are divided by a common language, which unfortunately they insist on talking to each other. Those of you, who unlike me, have mastered another language will know the peril of the "familiar friend" that expression you can easily translate into another language, but then has a wholly different meaning. 

Mail me for the sick joke that I could insert here but won't. It was told me by a Collector* in HMR&C**. 

The great challenge for ITIL and ISO 20k has to be understanding how you map supplier terminology onto customer and user terminology throughout the value network.

The Retained Organisation

Another opportunity to spit over you whilst attempting to say "dramadriehoek" The ITIL missing link is the role of the retained organisation/intelligent customer.  You need to understand what role you expect the retained organisation to fill, and  you need to realise that it will change over time. The RO should not be man marking the supplier and providing support when they make mistakes. THe RO should be setting the framework for supplier/customer/user interaction.

Service Credits and SLAs

Welcome to a basic lesson in economics. If I set myself up to deliver service A, and you apply constraints C which have I implications on how I can D Deliver the service...

...You get ACID, which is never good.

Punishing your supplier financially only works in a narrow subset of situations. Forget the sunk cost fallacy, what matters is how you can move forward.

Forget the mistakes of your past... what is it that matters now?

----------

* A very very senior British Customs Officer

** If you want  a good night out go to a Burns Night with  the British customs.The man himself was a "Gauger" A well known founder of itSMF was once found lying in a hedge after one such event. I know it was a good night because after five years I finally understood every word the Scottish CFO at the Passport Office said to me. Pity I didn't understand him earlier when he was teaching me accountancy.

CoreITSM 101: Call a call a call

Contract and SLA negotiation is always an interesting experience., especially when they've already been signed, which is when I usually end up getting involved.

Here is a typical scenario. The original negotiations have been intense, both side think they've got what close to what they want. The big guns have sorted out the sexy clauses. What nobody has noticed is the time bomb lying in wait. Nobody has noticed it because they think it is something they all agreed on, and anyway it is trivial and obvious what the contract means.

What is the time bomb?

It is the clause about the volume of activity that the service desk will handle.

You see for all the good stuff about service strategy in ITIL v3 it is the simple stuff that trips us up time after time. Like saying "calls" when we mean "incidents" or "incidents" when we mean "requests" or...well it goes on, and ITIL, for all the talk of providing a common vocabulary, doesn't always help.

Let me give you a couple of real world examples of the chaos that can be caused both by not using the right words and by not understanding the implications when it comes to setting performance targets and penalties.

An organisation that should know better - not least because it claims to sell ITIL consultancy - outsourced their Service Desk in a separate contract to their main outsourcing deal. The contract specified the number of incidents the Service Desk supplier was supposed to handle and the target time to answer and first time fix rate.

What the supplier did not realise was that the customer considered the number of incidents to be both a target in itself and independent of the other metrics.

Think this through.

The Service desk supplier has limited control over the number of incidents it has to handle. It has rather more control over the number of calls, but we'll save that for the second case. The number of incidents is driven by the underlying quality of the service. In this case they were also classing requests as incidents, and requests are driven by service demand, which again is largely out of the control of the Service Desk.

So we have a supplier being judged against a target that is almost entirely out of their control.

Needless to say the underlying quality of service was not there, and a rapidly changing business model meant large numbers of requests. As far as the customer was concerned this was all the Service Desk's problem.

It goes without saying that handling 25% more incidents the Service Desk struggled to meet the targets for call answering.

Result?

The customer invoked the penalty clauses against the Service Desk provider.
The customer did not renew the Service Desk provider's contract.

The tragedy is it what was a really, really great Service Desk.They were performing miracles to handle the extra calls and stay within budget - a budget that also had to take the hit of the penalty payments.

OK, I hope most people wouldn't be so profoundly stupid, would they?

Case number two is more understandable.

The customer's in house IT had always provided a good basic service and whilst the internal Help Desk wasn't the greatest on the planet it fulfilled the "log it and flog it" role quite well, and because they were good at pro actively informing the user of what was happening the ratio between calls and the combined total of requests and incidents was pretty much 1:1. Unfortunately they didn't really track the difference between incidents and requests. I'm sure you do though, don't you?

For really good reasons they outsourced both the IT infrastructure and the Help Desk to the same supplier, and combined it with a massive change in technology.

In the contract they specified how many calls the service desk should be able to handle.

The supplier did a validation exercise and agreed on the number of calls being dealt with prior to the handover.

This isn't the place to discuss why the technology shift didn't work out as planned, but it didn't.

What is important is that because in the past there had been a 1:1 relationship between calls and incidents/requests the contract only specified expected call volumes.

So what happened?

The technology didn't work, so there were lots of incidents. Because there were so many incidents the desk got overwhelmed, so any pro-active communication went out the window. As a result the number of calls per incident also shot up dramatically to something like 3 calls per incident/request.

The supplier blamed the customer for generating more requests, although they weren't tracking the ratio of requests to incidents despite it being a contractual obligation.

The customer blamed the poor quality of service and the lack of communication back to the users.

And I invoked the penalty clauses and cursed whoever had signed the contract.

It wasn't pretty.

In this case there was happy ending of sorts because a period of stability proved that the customer had specified the call volumes to be expected with a stable service and that the desk the supplier provided could cope with those volumes.

But all that pain could have been avoided if there was a clear understanding of the differences between calls, requests and incidents.

Next we will look at the use and meaning of call, incident, request, ticket, alert and event with an emphasis on their importance in producing meaningful management reports

Are you too competent to give advice?

"Trust me, I know what I am doing"

Inspector Sledge Hammer

Why do they cancel all the best TV shows? Take "Sledge Hammer!", it only ran for two seasons. Crazy.

Recently I've written a couple of posts on Instant IT Experts and ITIL as a Cargo Cult that have attracted some attention. Both of them highlight examples of the Dunning-Kruger effect summed up by their excellent paper "Unskilled and Unaware of it". For those who haven't come across it before the paper provides evidence that those who lack a skill are not capable of judging how bad they are at that skill compared to others, or how good others are at that skill. Hence they tend to massively over estimate their own ability and underestimate that of others. 

I first became aware of this effect at an organizational level during my involvement with the BQF and the EFQM Excellence Model. Organizations that were new to the scheme tended to self assess themselves at a level that exceeded what you would expect from world class operations.

In the educational world a model of concious competency has been around for may years. This posits that people move through four stages:

• Unconscious incompetence
• Conscious incompetence
• Concious competence
• Unconscious competence

The point I want to make in this post is that we have a responsibility to identify which of those stages people and organizations are at before we offer them advice, and the advice we give should be tailored to the stage they are at. 

A lot of the "bad" advice I'm seeing out in ITILland is not intrinsically bad, but it becomes dangerous when handed out without due care and attention. I suspect a particularly dangerous kind of advice is the sort that is intended to only apply in specific instances, but which can be taken as a general rule.

And I guess most of us have fallen into that trap at one point or another. As a trainer I became very aware that a throwaway comment could often be picked up on as a guiding principle by a student who totally ignored the bit which you went out of your way to say was really really important.

Where ITIL is concerned I think it is particularly dangerous because ITIL itself does not conform to any clear sound generic principles. Hence attempts to characterize it, including my own, are probably doomed to failure.  Bits of it are proven good practice, some of it might be considered best practice, other parts might be sub-optimal and yet others untried blue sky thinking. Some of it might be considered descriptive, other parts are clearly intended to be prescriptive for all practical purposes. In places it tells you the why, in others it tells you some of the how, but  not always. We live in a world though where people struggle with ambiguity and want black and white answers.

There is a tendency when talking to others to take their own assessment of their competency at face value and to see their understanding through your own eyes. The less concious you are of your own ability the less you might  realise that not everyone shares your wisdom and some still need to learn the basics of ITIL 101.

A physicist I know put it like this.

"At school in the lower grades they teach you that physics explains how the world behaves, but they lie to you about how it does that.

In the higher grades they tell you that how it really works is like this....but when you get to university theyt ell you that was a lie as well and how it really works is like this...

Then you become a professor, and realise nobody has any real idea about how it really really works."

Thick Skinned and Ugly

"Historians often hide from us the real path of history behind their errors, different opinions and false tales"

I have a good friend who is a doctor and a psychiatrist. She knows very little about the world of business which makes her observations on the world of management quite refreshing. To put it another way, she tends to see through the b******t and posturing. When we meet up it is usually to go to  a lecture on one of the subjects we share an interest in, be it psychiatry, psychology, philosophy or pseudo-science. 

Last year we got a last minute chance to hear Malcolm Gladwell speak. 

It was, I guess from talking to others, a typical Malcolm Gladwell experience. An adoring audience. A wholly scripted speech that was so well rehearsed it appeared off the cuff, a gripping storyline and a lovely little moral. In this case "However well prepared you are don't be over confident because something might happen that will trip you up." It was a fun, entertaining and rather expensive fifty minutes. It was worth it though to get such a deep insight into the....no hold on this is where my friend looks at me and says "That was s**t" , despite the fact she has a mega crush on him.

The same story, the same facts about the Battle of Chancellorsville could be used to tell any number of other neat stories. You could even make a case that Hooker lost the battle because he wan't confident enough , not forgetting that you could cherry pick another battle to support another view.

Having heard the story what can I do with it? How should I change my behaviour to get any benefit from it? How do I reconcile it with other Gladwell anecdotes?

You have to hand it to Gladwell though, he speaks with confidence and whilst you are listening to him it all makes perfect sense.  If you get the chance go and hear him speak.

Don't wait for a chance to go and hear the next speaker I want to talk about. Instead do everything in your power to go and hear him speak, and take as many people as you can along with you.  In fact if you can arrange a speaking event for him.

Ben Goldacre  is a doctor and a science journalist. He writes a science column for the Guardian newspaper, and in 2008 published the brilliant book Bad Science.

This genuinely is a book that if taken seriously could save lives. It attacks the  self serving, scientifically unfounded and deliberately distorted thinking that prevents effective health care strategies from being delivered and leads to many deaths.

He is passionate about the need for evidence based medicine.  You can hear him speak here about the importance of  meta analysis

His talks are free.


And my friend has an even bigger crush on him

The Pictorial History of The Rhinoceros

For  many years the best known drawing of the rhinoceros was a woodcut by Durer made in 1515. It was based on a description of a rhinoceros that lived, briefly, at Lisbon zoo.  It was the last rhinoceros seen in Europe until the arrival of Clara in 1741 and throughout that period Durer's woodcut was considered the most authoritative depiction of a rhinoceros.

So it is a pity he gave it a horn on top of the withers, scaly legs and dragon like armour amongst other fanciful embellishments.

What seems likely is that Durer added his own interpretation of the description, and those  following afterwards would not have noticed what his imagination added because it still appeared to match the description. It was armoured, and it did have two horns, for instance. 

Not only that but a 1752 edition of a catalogue of Roman coins appears to depict a Roman rhinoceros looking just like Durer's.  So did Durer's embellishments come from knowing what the Roman's thought rhinos looked like, or was the authority of Durer's drawing such that it influenced the person drawing the Roman coin to see details that were not there?

Why did Durer's drawing endure? Perhaps for no better reason that that people found this image of the rhinoceros attractive and it resembled what they wanted a rhinoceros to look like.

The Dangers of Second-hand Knowledge

If we hear an attractive story from someone like Gladwell, or are shown a compelling picture like Durer's woodcut we are inclined to believe it and loath to let go of it.  In the ITSM world there are people who never bother to ask if the story is true, if the conclusion is sound, or if the diagram makes sense.  Then they go and repeat the story and copy the diagram and tell everybody who will listen, and some who won't, that "This is the truth about ITSM" 

How do they know it is the truth? They read it on a PowerPoint slide.

Rather like the strange link between the woodcut and the coin you sometimes even have  a distorted version of your own ideas and diagrams ,that you'd discarded as dated ten years ago,  placed in front of you, quite innocently, as somebody else's original  new great idea.   

We love to have complex realities reduced to simple stories, but that doesn't make those stories either true, or useful.

And here I confess that the quote with which I started this post is extremely second hand. It comes not from some revisionist historian late in the last century, but from Sebastiano Errizo writing in 1559.

For that quote, and more on the story of Durer's Rhino, I am indebted to and  recommend The Rhinoceros of The Pope

Is ITIL a Cargo Cult?

The Halo Effect
One of the must read management books on my list of all time greats is Phil Rosenzweig's 'The Halo Effect'

In some ways you could describe it as an anti-management book in that it debunks the claims made by most of the  best selling management books to know the secrets of long term management success. "Good to Great" is still a wonderful inspiring read, but have you ever asked yourself  "What happened next?" in the organizations it praises? Do we still associate Fannie Mae with greatness?

Rosenzweig likens much management thinking  to what that great thinker Richard Feynman called Cargo Cult Science.



Cargo Cults


During WW2 islanders in the southwest Pacific saw troops form both sides of the conflict descend on their islands, build airstrips, install radio stations and call down aircraft to deliver supplies.

When the troops moved on the islanders built non functioning copies of the airstrips and the equipment they had seen in use, and  they copied the behaviour of the troops in the belief that they too would be able to call down goods from the gods or their own ancestors.

Although the intervention of the interlopers changed their behaviour they were actually confirming a view the islanders already held - that they would be rewarded if they behaved in the right way. In fact they thought the troops were usurping the benefits that were actually meant for them.

An intelligent reader, such as yourself, can probably see where I'm going with this...

Is ITIL a Cargo Cult on an  Island Near You?


ITIL qualifies as a cargo cult if::

• There are  people who genuinely get benefit from an ITIL approach
• The behaviour of those people appears alien to the islanders
• The islanders copy the form of ITIL, but not the substance
• The islanders' behaviour remains consistent with their old belief that they deserve rewards

Do People Get Benefit From ITIL?

Yes. 

Forget the crazy claims about absurd ROI that are fodder for Chokey the Chimp. 

Here are just some of the ways ITIL has benefited organizations that I know of from personal experience:

• Reduction in actual headcount - not just notional savings of people hours
• 75% in the time to fulfil requests
• SLAs that the business believe in
• Improved NFRs resulting in services designed to meet the customer need
• Contracts rewritten to define the service, not the underlying technology
• Changes rejected before work has started on building them, not the day before release

I know, normally I sound more cynical than sceptical about ITIL, but that doesn't mean I don't believe in ITIL's underlying value.

I could also mention the benefits it has brought to individuals, such as increased confidence to talk to the customer, higher salaries and greater job satisfaction, but I'm going to save that for a post about ITSM training.

Are These People Crazy?

Leaving aside the rather worrying tendencies of some people to go overboard in their belief that ITIL holds the answers to all questions I think there is much in the behaviour and attitudes of those who deliver benefit based on ITIL that is distinctively different., and can seem crazy to outsiders. 

• They seek out bad news
• They use metrics and targets
• They talk to customers and users
• They admit what they don't know
• They look for best practice outside of their own IT department
• They believe that the mechanisms of ITSM matter
• They don't believe the answers are to be found in technology
• They use a distinctive language and argue about what words really mean
• They believe IT staff should have non technical training
• They adapt ITIL where the guidance is currently insufficient
• They seek help when they need it

They do all these things and more

Do People Copy the Form but not the Substance?

You bet they do. 

These are the people who seek out ready to use templates for SLAs. These are the people who want metrics to prove their success, not so they can see where they need to do better. These are the people who call in external consultants to tell them what they are already doing is fine. These are the people who argue endlessly over the semantics of an ITIL term without ever trying to understand what the authors actually meant by it. These are the people who think that putting in a service management tool will solve all their problems. These, above all, are the people who believe they can leave out vital great chunks of ITIL in the name of adapting and adopting it.

These are the people who think renaming the Help Desk as a Service Desk was actually important

I could go on.

Is This Consistent with their Old Behaviour and Believes?

I'm afraid that it is. These are the islander who will always latch onto a fad and copy it. These are the people who will exploit any idea if it promises to bring them rewards. These are the people who believe that they are delivering a good service and the customer should be grateful.

Why Did The Gods Deliver The Goods?

Looking at it from an islander's perspective why did the rewards come for the troops and not for them?

Maybe it was because before the troops came to the island they had already developed the capabilities and tools and lines of communication needed to build the supply chain..

Maybe they simply knew what they were doing.

A couple of links

Chokey the Chimp on Crap Factoids

The ITskeptic on ITIL as a cult

P.S. I'm sure I've seen another post somewhere suggesting the link between ITIL and a cargo cult, but the only sites I can find are about cargo cult agile, not ITIL. If anyone comes across a link that pre dates this one can you let me know.

When brands like Toyota lose their shine

It would be a cheap trick to use Toyota to push up hits on my blog wouldn't it?

So as I throw my copies of "Toyota Culture" and other Toyota inspired management books in to the recycling bin, and reflect on the fact that the wife chose a bad week to order a new Toyota IQ, I'll try and think of a brand "like Toyota" instead.

You know, big on process and CSI.

A brand that has moved rapidly in to new geographies and launched a plethora of new products.

A brand that is in danger of putting short term gains ahead of the long term market.

Yes, you've guessed it.

I'm thinking

Is ITIL the next Toyota?

Service Catalog

This month I've been collaborating with Michael Jagdeo of B Wyse on the subject of service catalogs.

http://snipurl.com/ke2xe

I guess our conclusions might be seen as as provocative to the vendors of service catalog tools.

Let me stress we aren't saying that service catalogues aren't a good idea, but that their premature implementation can lead to issues.

ITIL tool certification

The launch of an official ITIL tool certification scheme has raised hackles, and it is worth thinking why.

There are a number of issues to consider.

There are those who question whether a framework like ITIL actually lends itself to conversion to a compliance criteria for a tool, especially some of the more esoteric aspects that v3 has introduced.

But then PinkVerify has been around for a long time, and most of us use it to produce a long list for tool selection. We, that is ITSM consultancies, also have our own proprietary approaches to tool assessment.

The Pinkverify criteria are in the public domain, those for the new scheme won't be. You can argue that the availability of the Pink criteria makes it easier for vendors to distort features of their tool to fit the criteria, but I like the transparency.

There will, I'm sure, be a market for the new scheme amongst tool vendors, and seeing a tool badged as officially compliant will I'm sure appeal to some buyers, though they would be unwise to place too much relience on it because we all know that a tool that works well in one organisation might not be the best fit for another.

I think my personal concern is to do with checks and balances. To be credible the scheme has to be seen to be transparent and independent.

If anybody knows how the decision to award the contract for running the scheme was awarded I would like to know more about it than I do. I am presuming it was the result of an open competitive tender?

I would also like to know what safeguards are in place to ensure the assessments are free of any perceived bias.

My final thought is I wonder if the new scheme has been launched at the wrong time. In a recession tool buying is driven by different thought processes than in the good times.

ITIL ROI Part 3 / The Myth of the ITIL Project Part 1

There is an accepted, but arguably untested, view that you should implement ITIL as a project.

How can it be untested I hear you say, surely there have been lots of successful ITIL projects?

Well there have, I've been involved in several, in fact I designed (we say architectured these days) two ITIL projects that went on to win the itSMF Project of the Year Award, and was was heavily involved in the execution of a third award winner.

So that proves ITIL can be implemented as a project, yes? Well yes, but that doesn't prove that it is the best way to do so. How much service improvement activity gets thrown into the project that should actually be being done as part of the Business As Usual (BAU) day job?

In all the usually quite spurious claims of proven ITIL ROI one thing you'll very rarely hear factored in is the cost of failed ITIL projects. BTW I'm not saying that ITIL doesn't provide a positive ROI, only that most of the claims are spurious. If you are making a decision to implement ITIL by running a project you would be sensible to factor in the failure rate across the industry.

Very simplistically - There are four ITIL projects each costing $1m. One of those succeeds and generates gross savings of $2m, a net saving of $1m and a positive ROI. Across the four projects though it is a different picture. Let's be generous and presume the other three projects didn't do any actual harm to the long term cost, but didn't generate any saving s either. Factoring that in to the picture we find that ITIL projects as a whole actually generate a negative ROI. They have cost the industry $4m, for gross savings of $2m, producing a net LOSS of $2m.

How many ITIL projects fail? Well it is a tough one to answer, because first of all you need to define what success means. My gut feel is that as many ITIL projects proceed their effective scope is reduced, but they are still declared a success at the end. In fact I suspect that in the great majority of cases what begins as a project focused on cultural change becomes yet another software tool implementation. Part of my argument against ITIL projects is that the IT project management mentality encourages that shift of emphasis.

Personally I was very skeptical of claims emanating from some organisations that they had implemented ITIL v3 within months of publication.

Another issue in judging success is that the delivery of ITSM is, by its very nature, a long term activity. You can not measure the success of an ITIL project the day it goes live, you need to judge it over a number of business cycles. Do that and you find something interesting: In the UK where ITIL has been around a long time some organisations are on their third of fourth ITIL project.

So my first question is this: Does the fact that some ITIL projects are successful mean that ITIL projects are consistently successful?

My second question is: Why are some ITIL projects more successful than others?

My third is: Are they successful because they are projects, or despite being projects?

Projects v BAU

One of my pet peeves is the view that the best, if not only, way to implement ITSM/ ITIL is as a project. My experience is that many ITIL implementations work despite being treated as projects.

I'll blog more about this later, but at the moment I'm engaged in a debate on the subject with the ITskeptic.

http://www.itskeptic.org/node/1415#comment-4418

ITIL ROI Part 2 Investment

The easy bit of ROI to understand is investment. Well sort of. Investment is often not about "do I X or do I do nothing", but about" do I X or do I do Y , or do I do nothing."

Investment in an ITSM project, or which more later, is often a mix of funds already allocated and new funds. Take internal staff costs for example. You are paying people's salary whether they are doing their day job or working on an ITIL project. Only very rarely have I come across an IT department that employs additional contractors to backfill for people engaged on the ITIL project.

That, of course, tells us somethign about how well utilsed some of those people are if they can be seconded to a longterm project with no need for resources to replace them.

So what are the costs of doing ITSM?

Training

Consultancy

Toolset

Process design

Project Management overhead

The cost of the new processes put in place

Additionnal staff

Reduce any of these without impacting the benefit and we've improved ROI

ITIL ROI Part 1

ROI for ITIL has always been a tricky area. There have been grandiose claims (see the IT Skeptic http://www.itskeptic.org/ for the debunking of some) but little hard evidence. In many ways this isn't surprising, because even under perfect conditions ROI is going to be hard to prove. And lets begin with a very simple problem;a lot of people talk about ITIL ROI don't always know what they mean by the term. Not surprising when the financial aspect of ITIL is so unpopular on the training courses.

So Part 1 begins with a look at the investment angle.

And here I find myself at variance with the norm, but let us remind ourselves where that norm comes from.

Consultants. Say after me "Consultants want to maximise their utilisation" 

So let us think about this. The people you go to for advice make more money the longer it takes you to achieve something.

How good are you feeling now? Log on tomorrow

ITSM in the recession

It is hard to avoid this subject at the moment, and it is one I will be looking at in a series of posts.

To begin with though it is worth reminding ourselves that this is not the first recession since ITIL has been on the scene, although clearly it is by far the worst. In the last recession ITIL was a powerful tool for cost cutting, especially head count reduction. That might sound strange to those who see ITIL as an exercise in job creation.

My headline predictions are that we will see less ITIL/Lean/ISO 20000 projects, but those that happen will be directed towards specific outcomes and have a greater chance of success than the raft of "me too" projects of recent years.

This will be a major change to the consultancy industry, especially to those consultants whose expertise lies in knowing the ITIL books rather than in practical management.

Simplicity

Inherent in the idea of Core ITSM is the concept of simplicity. There are two books I love on the subject: De Bono's "Simplicity" and "Simple Heuristics that make us smart" by Gigerenzer & Todd.

Too often in the IT world, particularly the ITIL version, we make things more complicated than they need to be. I don't need a complex process map for customer relationship management if I am close to my customers and users and internalise their needs.

Talk to users and often you'll find very quickly that two things bug them the most: Delays to basic tasks such as setting up new users, and problems with printers. The solutions in both cases are usually simple.

Simple doesn't mean easy though, at least not to begin with. The solution to sluggish work requests typically means certain support groups having to relinquish old ways of prioritising work.

I wonder if a lot of the complications we see in "process driven" IT shops are actually the result of people trying to avoid facing up to the need for a simple solution?

ITIL and contracts

I come across a lot contracts where terms such as "ITIL compliance" are used, or "the supplier will operate an ITIL change management process" I wonder if any of these terms have ever been examined in court?

ITIL books

I don't know about you but I seem to be faced with a deluge of books explaining to me what ITIL v3 is actually all about. Do they all add value, can I trust their view of the ITIL world, and doesn't it say something about ITIL v3 that it has spawned an industry telling us what it all actually means.

ITIL and Job Creation

One complaint I hear a lot is that ITIL creates its own bureaucracy and management roles start to proliferate whilst the people who actually GET THINGS DONE find themselves with more and more unproductive jobs to do.

This goes back to the early days of ITIL, in fact to one the earliest ITIL projects at the MoD , led by Ivor Evans. Ivor wanted to use an ITIL approach to breakdown the silos, but found that by trying to build an organizational structure around ITIL he just ended up creating new silos.

That is when it struck Ivor that just because ITIL mentions a role it doesn't mean it has to be undertaken by a dedicated resource. It was a topic addressed as well by the other ITIL pioneering Ivor, Ivor Macfarlane, when he produced the ITIL In Small IT Units guidance - I"TIL In Situ", which I believe is due for an eagerly awaited update soon.

In trying to determine which roles need to be allocated to distinct actors the questions you need to ask are the same as in deciding any other organizational structure:

Do people have the right mix of skills - we can't be experts in everything.

What will be the span of control - we don't want a heavy communications overhead.

Do we need segregation of duties, to use an audit term - personally I want my change manager to have as little personal interest in changes as possible so they remain independent.

What authority does the role have - often too many actors means no one is really in charge.

Can we design the processes around the role to reduce the workload - the more things that are done automatically rather than as an overhead the better.

Can roles be carried out by a committee rather an individual.

If we look at all these questions we often find that we can simplify the organizational structure and don't need as many managers as we first thought