type="text/javascript"
src="http://wave-api.appspot.com/public/embed.js">

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!

ISO IT Standards Survey

This survey is now closed. Thanks to everyone who contributed, I'll post a link to the results once they are available.

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?