Saturday, 28 March 2009


ROI for ITIL has always been a tricky area. There have been grandiose claims (see the IT Skeptic 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

Wednesday, 25 March 2009

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.

Tuesday, 24 March 2009


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?

Monday, 23 March 2009


Yesterday was Mothers Day (In the UK, don't panic if you are in the US). I ordered my mother some flowers from Interflora. As usual they were priced at a premium because it is a special day and a Sunday as well. No flowers are delivered, and my mother is obviously upset.

So I complain to Interflora and they respond with an automatic refund by email. But that is it. No promise to investigate why the flowers weren't delivered, no assurance it won't happen again, no recognition that they let me down over an important event, and no recognition of the upset caused to my mother. In fact the feeling you get is this happens a lot and they just want to get rid of complaints ASAP without quibbling.

Now I guess there is nothing wrong with that, you could even say they have done more than they had to, but somehow it isn't going to make me order flowers from them again.

I wonder how often we treat customers like that in the IT world?

I would like to think we wouldn't, but I suspect we do. We apologise, take the hit on service credits and expect the customer to forget it ever happened, rather than realising that in the customer's eyes getting service credits is a sub optimal outcome compared to being convinced the contracted service will be delivered in future.

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.

Thursday, 19 March 2009

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

Sunday, 8 March 2009

Service reports

Once again the client's IT supplier is late producing the monthly report. Most months by the time it lands on my desk for review I've already lost interest in it. It tells me about events I'd rather forget, and since then other things have gone wrong which need dealing with and have a higher priority in my mind. And it doesn't tell me anything about the future.

What really bugs me though is the effort they have to put in to producing it every month, and the feeling that if I didn't ask for it they wouldn't produce it for their own use.

How can you claim to be managing a service when you have no objective data to work from, and how can you claim to be doing problem management when you don't produce any data on trends?