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.

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.

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.

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.

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.

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.

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.

Finally if all else fails to come up with the money: Nick it. The new SAP rollout has a five-hundred-million-dollar budget, so pipe some your way by showing how the ITIL implementation is essential infrastructure for the new system. You know the department is under-spent for the year: offer to help mop up some of the surplus. Your peer manager is out of favour with your boss, so go after his budget. You get the idea.

Not Compelling

The following arguments seldom work:

“Because we should. Because it is the right thing to do.” So are a thousand other things you aren't doing right now. Why this one?

“Because it is better." You got by last year, why can't you get by next year? "Better" actually works but only once you link it to one of the other arguments listed elsewhere: You look better to potential clients. You have to get better to meet the quality standards of the new contract, etc. “It is my recommendation.” “I strongly urge.” “It is evident to those at the coal-face that … " If your opinion mattered so much it would be your decision. Put another way, your 5000 colleagues are doing it this way and you want to do it that way.

“Because I need it to do my job." Either you are not doing your job now or you are managing with what you have now.

“Because it will improve staff morale." This will get lots of affirmative lip-service but unless poor morale is actually costing or risking something forget it. If there is an underlying cost or risk, address that instead of whining.

My favourite poster: "Sackings will continue until morale improves." Or a great slogan for ITIL projects: "If you can't change the people, change the people." So don't go banging on about morale, they just might do something about it.

“Because everyone else is." This can actually work, especially if the decision-makers have been reading about it in McKinsey Quarterly or CIO or ComputerWorld or the Economist or Time. (Once it is in USA Today or Readers Digest it is probably time to move on.) But it works as part of the persuasive language (see below).

You include lots of the usual drek from Gartner to make them feel good about the decision; but it is not an argument. It is not part of the case itself. On its own it will not do, it is just supporting evidence.

These arguments do not work because they have no value to the organisation or the decision-maker. Maybe you haven't noticed yet, but in business what matters to you matters only to you.

Making It Work

You can get the content right but fail at the communication of it. Make sure the way the case is explained does these things:

Takes away pain or fear. Humans are basic creatures. All the rational intellectual arguments in the world are but dust in the wind if the person is in physical or emotional pain or genuinely afraid of something. Convince them you can remove the cause of that pain and you will get anything you need.

Deliver on key people's personal agendas. Never mind what the organisation wants: What does the decision maker want to hear? Steady consolidation with no major change because he is headed for retirement?

Radical transformation because she is new to the job and wants to be seen to have made a difference? The same basic content can be presented either way. Guess what happens when you get it the wrong way around.

Align with key business initiatives. Another way of saying this is to align with the decision-maker's KPIs (key performance indicators—what they are measured and paid on). It is a variant of (1) above (every criterion for a successful business case is).

The company has a drive for SOX compliance. The Minister has decreed cost cutting measures. The board has announced to shareholders an exciting new program, Transformation 2010. Shape the whole business case around the language and ideas of the initiative you are aligning with. Measure the business case in terms of the initiative's deliverables.

Use the right buzz-speak. Read the Annual Report. Read what the decision-maker has been writing lately, and what they have been reading lately. Pick up on the language.

The strength of any business case is money (real, imagined or … ah … diverted). 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. Look for my next column on how to put this into action for an ITIL project.