Home �   ITIL�  Index

What Goes into an ITIL Business Case

Money, justification and a little creative thinking, writes ITSM Watch columnist The IT Skeptic.
Jan 22, 2007

The IT Skeptic

In my previous article Business Cases 101 I covered some basic principles of business case design. Now, let's apply those principles to a business case for an ITIL project.

The previous article said the strength of a business case is money, real or imagined. The strategy of a business case is how it is aligned with the target organisation. With strength and strategy, and a little luck, you can succeed.

Other Articles by The IT Skeptic

ITIL Must Embrace the Collective

Stop Calling ITIL Best Practice

What You Need to Know About "ITIL Compliant"

FREE IT Management Newsletters

It is not executive management that we need to convince, not at first. We should be convincing ourselves. In theory, IT should not attempt anything that does not have a positive ROI for the business (though of course in practice that can be hard to prove when building or maintaining infrastructure).

We see too often where the ops manager or CIO subjectively decides to do ITIL then starts a great work of fiction called a business case to validate their decision. Most IT organisations have learned to talk like a business but not to think like a business.

So, first do the business case as an exercise. Does it stack up? If not, why are you taking it to the business? How is it in the best interests of the organisation as a whole? If you still feel it is the right thing to do, then work out why and include those arguments in the business case.

Of course, you may be proposing an ITIL project because you can all see redundancy looming and ITIL looks good on a CV. Even if the business case is as wobbly as a BS15000 certification franchise, this article will still help you get the business case through.

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.

    Someone at the ITIL consultancy Pink Elephant posted an excellent rule of thumb for ROI at blog.evergreensys.com: “[Y]ou 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 is 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 to 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 is 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 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.

  •     1 2 >> Last Page

    IT Management Daily Newsletter

    Related Articles

    Most Popular