Most business cases are written to win an argument in a room. The numbers lean optimistic, the risks get a polite paragraph near the end, and the benefits arrive conveniently after the writer's likely tenure. It works often enough to be a habit, and it's exactly why so many funded projects quietly under-deliver. The fix isn't more spreadsheet. It's writing the case as an honest forecast, not a pitch.

The quick version

  • A business case answers four things plainly: what problem, what options, what it costs, and what you'll get back, by when, and how you'll know.
  • The single biggest failure mode is optimism. Forecasts built from "our plan" beat reality far less often than forecasts built from "how did projects like this one actually go?"
  • Anchor your numbers to a reference class of comparable past projects, and run a premortem before you submit. Both are 30-minute habits that materially improve estimates.
  • Write the case so the approver can hold you to it: name the benefit, the owner, the date, and the metric. Vague benefits are how money gets lost.

The idea in depth

Strip away the templates and a business case is a structured answer to a simple question an executive is asking: if I give you this money instead of spending it elsewhere, what happens, and how sure are we? That last clause is the one most cases fudge.

Optimism is the default, and it's expensive

In their Harvard Business Review article "Delusions of Success" (July 2003), Dan Lovallo and Daniel Kahneman argued that most major business initiatives, acquisitions, capital investments, market entries, are justified by forecasts that systematically exaggerate benefits and underplay costs. The cause isn't dishonesty; it's the planning fallacy. When we plan a specific project, we take the "inside view": we reason forward from our own plan, our team, our intentions. That view is blind to the base rate, how projects of this kind generally turn out.

The pattern is most visible at scale. Oxford's Bent Flyvbjerg, drawing on a dataset spanning decades and dozens of countries, calls it the "Iron Law of Megaprojects": over budget, over time, under benefits, over and over again. In his sample of major projects, fewer than half came in on budget, and the share that hit cost, schedule and benefits together was vanishingly small. Your funding request is not a megaproject, but the bias that sinks the big ones is the same one shading your numbers a few percent in the friendly direction.

So the move is: stop defending your estimate and start interrogating it. For every benefit and cost line, ask "what would a skeptic who'd seen ten of these say?" If you can't answer, you haven't done the work yet.

The outside view: forecast from comparable projects, not from your plan

The practical antidote Kahneman and Lovallo prescribe, and Flyvbjerg operationalised as reference class forecasting, is to take the "outside view." Instead of estimating bottom-up from your own assumptions, you (1) find a reference class of past projects genuinely like yours, (2) look at how their actual costs, timelines and benefits landed, and (3) place your project on that distribution, adjusting only for real, specific differences. Kahneman called this approach "the single most important piece of advice regarding how to increase accuracy in forecasting." McKinsey now teaches a stripped-down version to teams as a standard "bias buster."

In practice: before you finalise a number, list five to ten comparable initiatives, your own company's past projects are gold here, and write down what they actually cost and delivered versus what they promised. If similar projects ran 40% over, your "this time it's different" case needs to earn that difference explicitly, line by line. This connects directly to comparing investments: an NPV built on inside-view inputs is a precise answer to the wrong question.

The honest limitation: reference classes are easy to gerrymander. Pick flattering comparators and the outside view becomes optimism with a footnote. The method also assumes a stable enough world that the past predicts the future, genuinely novel work (a new business model, an untested technology) has no clean reference class, and reference class forecasting itself has credible academic critics who note it can be gamed and that optimism bias isn't the only driver of overruns. Use it as a discipline that forces honesty, not as a number-generating oracle.

flowchart TD
    A(["Estimating a number
(cost, time, benefit)"]) --> B(["Inside view:
reason forward from your plan"])
    A --> C(["Outside view:
find comparable past projects"])
    B --> D(["Tends to: optimistic,
blind to base rates"])
    C --> E(["Anchor on what
similar projects actually did"])
    E --> F(["Adjust only for real,
specific differences"])
    F --> G(["A forecast you can
be held to"])
Inside view vs. outside view, applied to a single estimate. Leaders Loop

Make the benefit something you can be held to

The other quiet killer is the un-ownable benefit. "Improved efficiency," "better customer experience," "future-proofing", none can be checked, so none can be missed, so no one is ever wrong. That's comfortable, and it's how organisations fund the same vague promise repeatedly. The research base here is sobering: industry studies of IT investments routinely find that a majority of expected benefits are never fully realised, in large part because the business case stops being used the moment the money is approved rather than serving as the live contract for what the project must deliver.

The discipline that fixes it: for every benefit, name four things, the metric, the baseline today, the target, and the person accountable for it. "Reduce onboarding time" becomes "cut median new-hire ramp from 9 weeks to 6 by Q4, owned by the People Ops lead, measured in the HRIS." A benefit you'd be embarrassed to be measured against is not a benefit; it's decoration. This is the same discipline that makes strategy execution and cascading goals work, a funded initiative should ladder up to an outcome someone actually owns.

A worked example

The figures below are illustrative, invented to show the method, not drawn from a real company.

A regional logistics firm wants £600k to build a route-optimisation system. The first draft of the case is the usual: "Industry sources suggest route optimisation cuts fuel costs 15–20%. On our £4m fuel spend that's £600–800k a year, so the system pays for itself in under a year." Clean, confident, and almost certainly wrong.

Now apply the Toolkit. Outside view first: the team finds three comparable internal projects (a warehouse system, a telematics rollout, a CRM) and one peer firm's published case. Pattern: every internal build ran 30–50% over budget and 6–9 months late, and benefits landed at roughly 60% of the original forecast in year one as adoption lagged. Reference-class-adjusted numbers: budget £600k becomes a planning figure of £840k; the 17.5% fuel saving becomes ~10% realised in year one (£400k), ramping to 15% (£600k) by year two as drivers actually follow the routes.

Premortem next. The team spends 30 minutes imagining it's 18 months on and the project failed. The reasons surface fast: drivers ignored the routes, the data feed from the depots was dirtier than assumed, and a key engineer left mid-build. Each becomes a mitigation written into the case, a change-management line item, a two-week data-quality spike before committing, and a documented design rather than tribal knowledge.

The redrafted ask is less exciting and far more fundable: "£840k including change management; ~£400k benefit in year one rising to £600k in year two; payback ~22 months; biggest risk is driver adoption, which is why 15% of the budget is change management." The CFO can hold the team to that. The first draft, they couldn't, and wouldn't have trusted it.

flowchart LR
    A(["Problem & options"]) --> B(["Draft costs
& benefits"])
    B --> C(["Outside view:
reference class adjust"])
    C --> D(["Premortem:
surface failure modes"])
    D --> E(["Add mitigations
& owned metrics"])
    E --> F(["Submit a forecast,
not a pitch"])
    F --> G(["Track benefits
post-approval"])
    G -.->|case stays live| E
The business-case loop: the document is a forecast that keeps working after the money lands. Leaders Loop

Frequently asked questions

What's the minimum a business case actually needs?

Four sections, plainly written: the problem (with evidence it's real and worth money), the options considered (including "do nothing"), the costs and benefits over a sensible horizon, and the risks with mitigations. Everything else, appendices, sensitivity tables, governance plans, is supporting detail. If a reader can't extract the ask, the cost, and the expected return in two minutes, the case is buried.

How detailed should my financials be?

Detailed enough to be checkable, honest enough to show a range. A single point estimate signals false precision. Give a base case and a downside, state your key assumptions explicitly, and show payback or NPV using your firm's cost of capital. Approvers trust a case that names its own weak assumptions far more than one that pretends there aren't any.

How do I handle benefits I genuinely can't quantify?

Name them as strategic rather than financial, and say so, don't smuggle a guessed number in to make the NPV work. A case can rest partly on a hard-to-quantify benefit (regulatory compliance, optionality, defending a strategic position) as long as you're transparent that you're asking for a judgement, not selling a calculation. Dressing up a soft benefit as a hard one is the fastest way to lose credibility when it doesn't materialise.

Why do approved projects still fail to deliver?

Usually because the business case dies at approval. The benefits were never assigned an owner, no one re-checked them against the original promise, and the case gathered dust while the project drifted. The research on benefits realisation is consistent on this point, keeping the case live as the yardstick the project is measured against is what separates initiatives that deliver from those that merely launch.

Isn't all this just sandbagging, lowballing so I look good later?

No, and the difference matters. Sandbagging is hiding upside to beat an easy target. The outside view is removing bias in both directions: you'll often revise costs up, but you'll also defend genuine benefits more confidently because they're anchored in evidence, not hope. The aim is a number you'd bet your credibility on, which is the only kind worth funding.

Related in the Toolkit

Where to go next