Is ISO/IEC 38500 The Cinderella at the IT Governance Ball?

I like ISO 38500.  I like it very much indeed.

Which is why I find it so hard to understand why it has been met with such deafening silence in the UK.

• Is it because COBIT is already so well established?

• Is it because people are not aware that it exists?

• Is it because people are unsure how to respond to it?

A survey is now open to 6th March to assess the market for ISO 38500 If you can, please identify that you came across the survey from this blog.

Why do I like it so much?

I honestly believe that the standard has a lot to offer organisations, especially those that have not already been driven down the governance route in reaction to external requirements.

I believe that whilst we often talk about ITSM addressing the concerns of the corner office the truth is we rarely actively engage senior business management in delivering IT. Good IT Governance, with a focus on the interests of stakeholders can make a real difference to the relationship between IT and the business.

The benefits of good governance  obviously extend beyond ITSM, it is also a sign of effective portfolio, programme and project management.

What is so great about ISO 38500 is that it can get people, and I include the business, not just IT, to realise just what their responsibilities are for ensuring IT is effective and efficient in supporting the organization. And the standard is, of course, very clear that the responsibility for IT rests at director level.

I'll end this post with a specific example of how I've seen an idea inspired by the standard make a difference even in an organisation that has yet to decide whether to adopt it wholesale. 

They thought they had good project reviews, they had even adopted the concept of gateway reviews that were led by the business, but what they discovered when they compared their approach to the standard was they were only judging each project by its own internal criteria. 

In effect they were only assessing if the project was on track and within budget. What looking at the standard made them realise was that they were not asking if the project was still aligned to corporate objectives, and that compromises being made within the projects were contrary to the Principles of the standard. 

For instance short cuts were being taken over the acquisition of change related hardware and services that threatened to contravene the financial limits for needing to re-tender the entire project.

So what is ITIL?

What is ITIL?

I don't mean in an ITIL 101 type sense.

I don't mean in the glib way a consultant would sum it up on a .PPT slide.

I don't even mean what does ITIL claim to be.

I mean what is ITIL in reality.

I'm not an ITIL v3 expert so I cannot give you a text book answer. Instead here is my own interpretation.

To begin with - what ITIL isn't.

It isn't a standard
Yeah, we all know this. Those of us involved with developing ISO/IEC 20000 can tell you how different it would be if it was. But hey, since we have ISO 20000 so we don't need ITIL to be one


It isn't Proven Good/Best Practice
Perhaps this is less obvious.Once upon a time it was true. V1 was very much based on what good mainframe shops did as a matter of course.  There are still bits of ITIL v3 where this is true. In some areas though you are either getting blue sky thinking without any evidence to support the ITIL position, or you are getting ideas that are dated and basic. Which are which? Hmm not obviously signposted is it?

It isn't Proscriptive
Well it would have to tell you if it was, but it doesn't tell you which bits of it you HAVE to do to provide an adequate service to your customers.

It isn't a Menu from which you can Make Choices
I actually think this is the most dangerous misconception there is about ITIL, compounded by the failure to identify the things you must do to be successful. In reality there is a tendency to drop the difficult but essential bits. That's why ISO 20000 doesn't give you the option to do that. You can chose to miss out a stage of ITIL's change management process, but if you do there is a high probability  your change management process will be fatally flawed.


So What Is It?


Good question. It is neither fish nor fowl., and that I think is a major flaw.

A Compass?
Someone described it the other day as being a guide or a compass. I find that quite an attractive analogy, but one of the key things about a compass is you always know which way it is pointing. I don't think there is a clear North in ITIL.

A Philosophy?
Ivor Macfarlane used to say something along the lines of "The IT Infrastructure Libary is a set of books, but ITIL is a philosophy."

I find that quite an attractive view as well, and ten years ago it is the view that would probably have got my vote. But ten years ago the ITIL community was relatively small , relatively homogeneous and relatively self organising. Most of the people involved had an implicit understanding of that philosophy. Times have changed though, and that is no longer true. We can no longer liver with a disparity between the books and what we really mean

A Statement of Facts?
This is a view that has only really struck in recent weeks. I suspect it is in part my reaction to the view that you can chose the elements of ITIL to adopt, and that you change the meaning of what ITIL says to suit yourself.

It doesn't matter what I say or think, an incident is still  different from a problem. A change is a change, whether I like it or not, and I firmly believe there is only one overall change management process that can work. Marginal costing has a very precise meaning in accountancy. What makes something a contract isn't whether we call it a contract instead of an SLA.

Is ITIL a Map?
Slowly I'm coming to the conclusion that what ITIL is closest to being is a map of the ITSM world. There might be some areas of that world that we don't want to venture in to, but they are still there whether we chose to believe in them or not. There is a way of holding ITIL up against the real world that helps make sense of the real world, but we have to learn what the symbols on the map mean.

Being like a map isn't the same as actually being a map though, and most maps interpret the world through a political lens and can only be based on what we currently know allied to some more or less reasoned supposition.

What I am certain of though is that it ITIL is not to continue getting people lost in the ITSM world there needs to be absolute clarity about what ITIL actually is.

The Rise of the Instant ITIL Expert

Back in November I presented a session at the itSMF UK's conference on getting the right people involved in your  ITSM initiative. One of the key themes was how do you tell the heroes from the villains within your organisation.

There seem to be a lot of self styled ITIL gurus around these days and it can be equally difficult to identify who to trust, so here is my personal opinion about just some of the types to be wary of.

The Retrospective ITIL Expert
This one claims that they've been using ITIL for years, but when pushed you discover they've only recently been  qualified and appear to know little about the history of ITIL or what it is really trying to achieve. Of course they'll then tell you that ITIL is only common sense and their practical experience trumps ITIL

ITIL by the v3 Book
This one argues everything against the specific wording of ITIL v3 and appears to be oblivious to the fact that just about anybody who was involved with v3 will cheerfully, in private at least, admit it has flaws and omissions. They rarely seem to be aware that ITIL existed before v3 or that rather like another well known book you can usually find an out of context quote to suit whatever position you chose to take.

The Flawed Theorist
Theory is good, ITSM deserves a better underlying theoretical model than it currently has. The theorist, however, is only interested in their own theory. That  almost nobody else agrees with it is not an indication that the theory night be flawed but of the stupidity of everybody else in the ITIL world. The rest of us are not capable of appreciating the intellectual superiority of their idea. More often than not their great new theory rests on the type of misunderstanding the Foundation exam was introduced to counter. When pressed to prove their theory they will retort it is up to the rest of us to prove them wrong.

The Expert in ITIL and nothing but ITIL
A close relative of the believer in ITIL by the book. These days they are often to be found in the training community. Their entire knowledge of subjects comes from what they know of ITIL.They appear unaware that much of the content and language of ITIL is a sub set of other specialisms. Mostly harmless.

The Wannabe
The wannabe was once forced to attend a workshop as part of an ITIL initiative. At the time they were quite happy to tell everyone what a waste of time it all was, but hey now they are an expert, especially if it means being able to get a job in consulting or training.

The Confidence Trickster
Nothing phases this one, they have absolute confidence in their own expertise and are only too glad to share it if you attend their training courses or reply to them off list. They often award themselves some grandiose but meaningless title . It doesn't matter if you are a newbie making an innocent mistake or a true guru passing on a hard learnt lesson, the confidence trickster will treat you with equal contempt. What they are not so great at it is showing any evidence that they've actually applied ITIL any where or have any real insight.

The Good Guys
As I said in my original presentation the odd thing is that there is a superficial resemblance between the heroes and the villains so why don't we remind ourselves of what you should be looking for in an ITIL expert.

Retrospection
It really is helpful if they can see their pre-ITIL life through an ITSM lens. That includes recognising the things they would have done differently had they known about ITIL at the the time, or even the things they would have done differently in the gap between knowing about ITIL and really understanding ITIL. They'll also be able to identify the things they did right that echo what ITIL says.

V3 Knowledge
The real expert will understand what has changed in V3 and how it relates to the history of ITIL. Of course they will also know about COBIT and ISO/IEC 20000.  They will be able to give you a cogent account of how v3 could be improved but won't lose sight of the benefits of the changes. Not only that but they'll be able to add real value because of their practical knowledge of integrating ITSM throughout various life cycles.

Theory
A real expert understands the need for an element of theory, but will also know how to apply and adopt  that theory.

Breadth and Depth of  Expertise
You don't want an advisor who only knows about a small part of the ITIL world, you want someone who can offer input across the full breadth of ITIL. But you also want some depth and a good sign of that is a previous relevant specialism.

Ambition
True experts are always willing to learn and to improve. They are confident about what they achieved on their last assignment, but are already thinking about what they will do differently next time.

Confidence
The true ITIL expert does have a certain arrogance, but it is based on demonstrable success. If they hold a strong  view they will explain why.

When a wheel falls off

The Power of the Analogy

Every year I make the pilgrimage to Le Mans for the famous 24 hour race. 

Being me I can't help thinking about the parallels with service management and the lessons we can learn from the teams. 

Before I continue a word about analogies. It strikes me from time to time that there are people in the IT industry who do not see the parallels between what IT does and what other specialisms do.  I guess it doesn't matter that they don't get some analogies, after all when we are teaching, for instance, the use of an analogy is only one way to get a point across and you need to appeal to different mindsets. When it does matter though is when what another specialism does is directly analogous to what we do in IT and has valuable lessons for us to learn about the right way of doing things.To disregard how the engineering community carry out Root Cause Analysis, for instance would be both supremely arrogant and irresponsible.

Recognising we have lessons to learn from outside IT is a major driver for making improvements. Here is one interesting story:

I'm afraid my insights based on Le Mans aren't going to be quite as vital as that.

Lesson Number 1: Things will go wrong

At the start of Le Mans several million pounds worth of cars are lined up on the grid. For every team this is THE race of the year. Winners of Le Mans, both drivers and cars, go down in motor racing history. Every single person involved with those teams is committed to....well winning the race or your class would be great but the 250,000 spectators at the track (Yes you read that number right) all know that just getting to the finishing line 24 hours later is a massive achievement.. The current record for distance covered during the race is 3,235 miles. That works out at an average of 135mph, though the highest speed actually recorded for a car at Le Mans in 248mph.

So, things break, or get broken.

And the teams expect that, so even though they have spent a lot of time and money trying to make sure things won't break they also plan for what will happen when they do break. That means:

They design things to break

It is much better to have a minor component break in a known way than to have a major component blow up. So you sacrifice one component and the car limps back to the pits. Did I mention that if anyone but the driver touches the car whilst it is on the 8.5 mile long circuit the car gets disqualified? Don't worry about the guy in the photo at the start of this post, he is actually in the start of the pit lane, though that isn't where he was at the start of the crash. How did it get like that? I'm afraid one of the Aston Martin cars hit it and slammed it in to a wall. That wheel at a crazy angle  is an example of what I'm talking about, the suspension has sheared off at points deliberately weakened to protect the main structure of the car. 

They design things to be fixed

End of the race for the 26 car above? Not yet. The crash happened about 7.30pm, by  2am the car was back on the road. Remember this isn't a little shunt on the high street, this is a crash that saw the car slam into a concrete wall at high speed. How did they do it? 

Here's a picture I took in the pits before the race. Can you spot what is missing?

Every component is designed to be removable, and the mechanics train on how to move and replace them.

People Are in the Right Place

The pit lane at Le Mans is a dangerous place, and those garages where they have to do any major mechanical work are about the same size as a large domestic garage. You can't have hundreds of people milling around. The team management are normally on the pit wall keeping an eye on the telemetry. The drivers who aren't in the car are asleep in a motor home, and the bosses, the sponsors and the guests are in the hospitality suite above the garage.

And Finally...

You can do a surprising amount with gaffer tape and a hacksaw, but a final top tip is some of the teams swear by using a certain brand of  fizzy cola to clean the flies off the windscreen  - but make sure you wash it off well and don't try it on a computer.

And for those who just like the cars...

Here's a slide show of the rest of my photos from the 2009 race

Le Mans 2009

A new beginning

Don't you just hate blogs that suddenly dry up for no apparent reason?

Like this one. No sooner had it received the ITskeptics seal of approval than it all went very quiet here.

At least that is how it must seem.

In reality the number of draft posts has been growing steadily, but for various reasons I've not wanted to publish them. The main reason has probably been that many of them are related to an area where my own thinking is developing rapidly. So what is it?

No it isn't the Cloud or SaaS.

Well not exactly, it is the more generic topic of commodity computing, and how we apply service management best practice to it.

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.

Prioritisation 2

So what goes wrong with prioritisation in most organisations? Everything really.

Most people don't understand what is really important, either now or for the future. So often we see a new project  as number one priority when it's actual contribution to ROI is minuscule.

Then there is the resource issue.

Now I might be a bit slow because it has taken me quite a few years to work this one out, but forget Critical Path Analysis with the emphasis on skey tasks.

The biggest reason I know why things are delivered late is because of the dependence on scarce resources. We have one Ruby On Rails expert, how do we most efficiently spread them across tasks? That is the type of issur prioritisation should address,  ensuring an even flow of work to that scarce resource.

And then we come to timing. There must be an equation for this, but I'm fed up with a high priority/big resource issue constantly taking precedence other a medium priority/low resoucre issue.

Get the easy to do tasks out of the queue ASAP. Password reset? Low urgency, relatively high impact, low severity, do it now.

Resource now free to do something else. PASS

Major change going in but it fails pre prod testing? Let it re-enter the change cycle a month later PASS.

Major change going in but it fails pre-prod so you throw every available resouce at it to fix it in a  day? FAIL.

 Take up next weekend's change slot and demote everything else that was meant to happen at the following weekend FAIL Repeat for the next six weeks? FAIL.

Prioritisation

When I ran ITIL course I was sometimes surprised by the concepts that found people difficult.

Prioritisation is a good example, which is a shame because I believe that understanding how prioritisation should really work is one of the keys to unlocking the power of ITIL.

In a later post I want to look at prioritisation as part of my approach to reacting to the recession ( See an earlier entry) but for now I want to focus on the basics.

To me prioritisation is about:

• Deciding what is important in the big picture
• Allocating the right resources
• Ensuring the activities are completed at the right time.

In contrast many people seem to see it in terms of:

• Doing what is most important right now this minute
• Throwing everything we've got at it
• Doing it now

There is quite a difference between these worldviews, and anyone familiar with Goldratt's Theory of Constraints will be able to see what is wrong with the second view.

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.

Fractal Forms

Perzi is now back up and running after its outage, so go to

http://prezi.com/56162/

to see what I've been working on.

Please bear in mind both the medium and the message are experimental!