The ITIL Business Case 101

I've ranted enough at itskeptic.org about the need for ITIL projects to have a real business case. So we will discuss what an ITIL business case should contain in an up-coming column, but first we lay some groundwork: how to build and execute a business case.

This is done in the context of ITIL, but most of this is of course applicable to any business case.

There is much discussion of which processes to start with in ITIL, or what order to do them in, or whether to do them at all, or how to decide. If the decision on which processes to re-engineer is driven by a business case then the right ones will be chosen; those where ITIL will yield a return.

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 bITa Planet CIO Update Intranet Journal Update Datamation IT Management Careers Datamation IT Management Update Grid Computing Planet HTML E-Security Planet Text E-Security Planet HTML DRM Watch HTML

Sadly, in IT, decisions are often not driven by business case. Investment is often sunk into projects that return unknown benefit because some manager thinks (or has been convinced) it is a good idea. For too long we have made many decisions in IT based on whether something will be "better" (faster, more flexible, more space, cooler) without addressing the basic issue: "Show me the money."

If the return does not exceed the investment, don't do it. If you are part of a business then you should run like a business and that means having a business case.

A business case should be a reasoned and structured document with supporting evidence and references that justifies a project on either financial or strategic grounds. It should address the overall strategy and plans of the business and be reviewed and approved by senior management.

In the commercial world, a business case justifies its project in monetary terms. No money, no project. It is amazing how many arguments lose sight of this simple principle.

Returns on investment (ROI) can be above-the-line or below-the-line or both. “Below-the-line” means cost savings, efficiencies, lay-offs. “Above-the-line” means more customers, new products, more sales, higher prices.

Below-the-line money is easier to make tangible, to put a solid figure on it. It is also harder to prove because people understand the current process and have some measures of it. Above-the-line numbers tend to be more speculative (read: “made up”) because we are talking about new fields, the unknown.

Show Me the Money

Here is how to find the money for your business case:

Look for below-the-line savings. There are a some analyst-papers that give you percentages to wave around: 25% less calls to the helpdesk, 15% less downtime …. whatever. Find some existing cost metrics within your business (dollars per call, dollars per hour of downtime).

Failing that use yet more analyst wet-finger-numbers. Do some impressive spreadsheets (colours are good) to show the expected savings.

If the resulting numbers still look a bit light, claim you will increase everyone’s efficiency by two percent, then calculate the entire staff costs and claim two percent of it. (If you are scoffing, I have seen it done for a web portal product.)

This is of course nonsense. If I gave you an extra ten minutes per nine-hour day (who works eight any more?), how much more would you get done?

When the below-the-line numbers don’t stack up, look above-the-line. If you plan to claim increased productivity of two percent, add that to annual gross return and calculate the increase in profits. Claim that. Or find strategic issues that are hot in your organisation right now; growth, flexibility, quality, customer. Show how the project contributes to those.