Business case: justifying a project before committing

A business case is the document that lets a sponsor decide whether a project deserves to exist. It sets out the problem, the options considered, what each would cost, what each would return, and which one is recommended. Its purpose is to make a decision possible — including the decision to say no.

What it must contain

The problem or opportunity, stated in terms a non-specialist can grasp. The options examined, including doing nothing — a business case with a single option is a request for approval, not an analysis. The full cost of each option, the expected benefits with dates and owners, the main risks, and a clear recommendation. Everything else is annexes.

Quantifying benefits without fooling yourself

A benefit is credible when it is measurable, attributable to the project and dated. "Improved productivity" is none of those; "three hours per week saved for twelve controllers from the second quarter" is all three. The test that separates the two is simple: someone must be willing to be held accountable for the figure once the project is delivered.

Cost the whole thing, not just the project

The cost of a project does not stop at go-live. Licences, hosting, support, training and the effort needed to keep the thing running are part of the equation, and increasingly so as software moves from purchase to subscription. Comparing an investment against a recurring charge over the same horizon is what makes options genuinely comparable.

ROI, NPV, payback — and their limits

Return on investment is easy to communicate but ignores time. Net present value discounts future flows and is more honest over several years. Payback period answers a question sponsors genuinely ask: when do we get our money back? Give at least two of the three, and always state the assumptions — a business case whose hypotheses are hidden cannot be challenged, therefore cannot be trusted.

It does not die at kick-off

The most common failure is not a bad business case; it is a business case nobody opens again. Reviewing it at each major milestone — are the assumptions still true, are the promised benefits still achievable — is what allows a project to be stopped in time. A project killed at 30% because its rationale has evaporated is a success of governance, not a failure.

Following it through in FoxPlan

FoxPlan holds the planned and actual cost of a project, its revenue and the resulting margin, so the economics of the business case stay visible during execution rather than only at approval. At portfolio level, projects can be compared and arbitrated against the capacity they consume — which is where a business case is either confirmed or quietly contradicted.