The keys to a strong ITIL business case

We have been discussing ITIL business cases in some previous posts. Now let's get down to the nitty gritty: where is the value in an ITIL project?

The keys to a strong ITIL business case are some basic things:

• There ought to be low-hanging fruit. If there are no real short-term gains you will never hold the attention of either grass-roots participants or senior management.

• There ought to be real money. If you are not saving dollars somewhere to pay for at least part of it, you will be dependent on a "religious decision" (i.e. a leap of faith) by a senior manager who supports you. When that person moves on, the support is gone. Without demonstrable ROI you are back to square one with their successor. A Pink Elephant person posted an excellent rule of thumb for ROI: “you set your maturity target for process improvement at CMM3. You then analyse the incident data and determine what percentage of incidents would not have occurred with a CMM3 level of process implementation. From this, you can calculate the ROI”.

Thankfully the operational side of IT tends to have strong metrics to support business cases, and to involve repeatable processes where efficiencies can be made. Nevertheless, the dollars will seldom be enough, so make up the "shortfall" in the business case with risk, compliance, and strategic advantage.

• Risk: the easy one if management are at all risk sensitive. As we said last time, reducing risk can be a compelling argument if (a) there is focus on that risk right now due to scrutiny or a recent embarrassment and (b) the person who owns the money owns the risk. Find the Audit Office, Risk Manager, or Chief Security Officer, and find out what concerns them about IT. Get them needling your decision-maker, or at least threaten the decision-maker with them. If you are a bank, use Basel II. Security is the obvious domain to talk about risk, but do not neglect the other ITIL domains. Reducing production outages or speeding mean time to repair can have a dollar value, but they also reduce risk.

• Compliance: really easy once a compliance requirement has been slapped on the business. SOX, ISO9000, and coming soon ISO/IEC 20000. Also look for a big customer contract that has some process or quality SLAs in it. There may also be internal requirements: a much-talked-about example is “transparency” or “business alignment”. If this is a genuine formal requirement on IT from the business, good: use it. If it is just words then it is not an argument. There must be a real pain.

• Strategic advantage: this is much harder for back-room stuff like IT operations but you can argue increased flexibility and responsiveness, and faster time to market with new IT systems. Well, you can try: the Skeptic is sceptical and so are many managers. The best argument the IT Skeptic has seen is that improved processes mean less fire-fighting, thus freeing up resources for more strategic projects, but this is still drawing a long bow. The exception is IT Service Providers, and other very IT-intensive organisations. If IT is the business, then there are real strategic advantages to making IT slicker and more robust.

This post is an extract from the ITSkeptic's ITSMWatch article What Goes into an ITIL Business Case

Comments

RTSF

I think the most important component of an ITIL business case is RTSF (Return to Service First). I just dreamt that up but explains my view that the most important issue to address is reducing the TIME durations in provisioning and outages.
TIME is the most important metric and each measured duration becomes an aggregated measurement that can be analyzed.
A valid business case can be built by prioritizing return to service and using elapsed time as a metric. Risk, money, compliance and strategic advantage are wishy washy factors that are always associated with subjective opinions. TIME is not.

This is getting valuable

With my belief that this sort of community site becomes valuable if you discuss practical concepts, I found this post pretty good.

Normally I like "The Skep" because of the critical aspects.

A couple of things. I have not personally witnessed this;
"Thankfully the operational side of IT tends to have strong metrics to support business cases," in fact quite the opposite. The IT shops I run into, the ones that need help do not have metrics which is precisely why they are in the S@*t. They don't know where to start because they cannot see the problem.

Good tips on starting points I have found which have real money attached;
- configuration management - focusing on a software license audit
- capacity management - focusing on eliminating new equipment purchases, or extensions to the datacenter facilities

See how many people can throw in other ideas.

$0.02
Brad Vaughan
http://blogs.sun.com/buraddo

metrics that treat IT as a black box

It is my personal opinion that when we say they have no metrics, we mean no metrics that measure what we think they need as an outcome, or more precisely no metrics to measure ITIL. This is that circular reasoning that if the problem is lack of ITIL then the solution is ITIL.

So I was thinking of more general metrics that treat IT as a black box.

How many sev 1 outages per year? we know this one by the scars.
How much does a day's outage cost the business? i bet they know
What does a month's delay in implementing the new sales system cost? I bet they know.
what does the average IT staff member cost per year? HR know

etc etc

Outcomes

What we need, and usually lack, are metrics that address the outcomes. Both IT and the business, to be honest, tend to end up selecting "so what?" metrics. Calls answered in under five seconds - so what? Less than 5% of lost working business hours due to IT (as oppossed to sickness, process slack, training, comfort breaks etc.) perhaps more interesting?

The same applies to business cases, often they end up being much more internally focussed than we think they are.

I increasingly feel that there is a distinction to be drawn between the business case for relatively short term enabling/ removal of constraints activity/ correction of what is broken as oppossed to the longer term delivery of benefit/ providing enahnced business capability case, though both clearly have to be part of an overall plan. We confuse these at our peril, and I'm afraid that one are where we do so is in addressing the quick wins. These have a tendency to look like they are value enhancing at the start of the improvement phase, but looking at them after implementation the reality is that the number of other constraints in the system means that the long term value is not delivered. Take improvements to the service desk. I've said this before I'm sure, but what you see is an intial perception that the changes have delivered value because users are happier, but in the long term we have simply got the service desk back to functioning as it should, we haven't delivered anything extra.

Syndicate content