I have seen many business cases for proposed IT projects. I have seen few good ones.

Authors generally do a good job of describing the project, its scope and the costs. This is because authors are typically project managers or other IT leaders who are very familiar with project scope documents and budgets. Where they tend to fall down is in describing the benefits. All to often I see the following.

• “This project will improve efficiency.” – Too vague. Efficiency is often a code word for “we just don’t like the old system”.
• “Upgrading will improve reliability.” – OK, how much? What is reliability today? Why isn’t that enough? What will it be after the project is complete? Who will measure it? When?
• “There are huge issues with the current application.” – No hyperbole!

We need to apply the same discipline that we use when defining scope and costs to the benefits in our business cases.

Not all benefits can be measured in purely financial terms. That’s OK. In fact, the most compelling business cases are often based on non-financial benefits such as reputation enhancement, improved worker safety, or reduced environmental impact. But we are asking permission to spend real money and we should be clear about what that money will buy.

Begin by classifying benefits properly. Benefits are either:

• Monetizable – resulting in reduced costs and/or increased revenues;
• Quantifiable – resulting in measurable but non-financial improvement in some factor that supports the objectives of our organization (e.g., reduced lost-time incidents);
• Realizable – resulting in an important but intangible (unquantifiable, unmeasurable) improvement in some factor that supports the objectives of our organization; or
• Speculative – maybe the project will deliver this benefit and maybe it won’t but we think we should try.

Our classification must be honest. Any benefits that we believe are monetizable or quantifiable should be accompanied by current and target values. We should also identify who will confirm that those benefits are realizaed after the project and when they will do that. (Those people should be approvers of the business case.)

Writing a great business case is easy. It just takes a little discipline.