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!

Watching the fish

I'm lucky enough to live near the banks of the Warwickshire Avon. At this time of year I love walking along it with the dogs, keeping an eye out for basking snakes on the path and peering into the clear water to spot fish. There is always a certain thrill in spotting a pike, hovering to strike at anything that moves in front of it, including smaller pike.

PIKE is actually a useful approach to dealing with a recession.

• Prioritise
• Innovate and invest
• Kill or keep
• Economise

I'll look at each of these in turn, but for now just think about that order, in particular that economise is last on the list, not first.

Clouds and ITSM

For years now the mantra of ITSM has been that IT has to align with the business. Does that still hold true with cloud computing? Once we move to commodity provision of IT doesn't the emphasis move to the business having to fit around IT - in return for reduced costs?

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?

The bigger truth is found in small thingsPt 1

Have you ever made a judgment about a major organistion based on a single interaction ? Thought so, and I bet it wasn't positive.

The truth is we make meta judgments based on micro experiences.

How do I judge an entire hotel chain?

On what my experience was the last time I registered, when the girl on the desk asked me if I'd ever stayed with the chain before when I'd only checked out 36 hours earlier.

You ring the service desk, get an off hand message and conclude IT don't care about the business.

Get the small things right in IT and there is a chance you will get the big things right.

Get the small things wrong and you might as well go home.

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?

Flowers

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.

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

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?