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