Most business cases fail before they're even read. They're too long, too optimistic, and written by people who already know the answer they want. The result is a document that convinces nobody and commits to everything.
I've reviewed business cases for programmes worth hundreds of millions of pounds and dirhams. The ones that get approved and then actually delivered share a set of characteristics that have nothing to do with formatting templates or methodology frameworks. They're honest, specific, and built around decisions rather than justifications.
The business case isn't just a funding document. It's the first test of whether a programme is being led by people who understand what they're doing.
Why Most Business Cases Don't Survive Contact With Reality
The single biggest problem with enterprise business cases is benefits inflation. Sponsors want approval, so they overstate returns. Finance teams know this and discount everything. The result is a negotiation dressed up as analysis, and the actual programme ends up accountable to numbers nobody believed in the first place.
The second problem is that most business cases treat risk as a formality. There's a risk section, it lists generic risks, and it assigns them all a medium rating. Real risk analysis asks: what would have to be true for this programme to fail, and how likely is each of those things?
What Approvers Actually Want to Know
Before writing a single page, understand what the decision-makers need:
- Is the problem real and significant? Not assumed, not theoretical. Evidenced.
- Is this the right solution? Have alternatives been genuinely considered, or is this the solution someone already decided on?
- Are the benefits credible? Who has signed off on them? Are they measurable post-delivery?
- What does failure look like? And what's the plan if it happens?
- Who is accountable? Not the project, not the workstream. A named individual.
How to Structure a Business Case That Gets Delivered
| Section | What It Must Contain |
|---|---|
| Executive Summary | One page. Problem, solution, cost, benefit, decision required. Nothing else. |
| Strategic Context | Why this matters now. Link to organisational strategy. |
| Options Appraisal | At least three genuine options including do nothing. Show your working. |
| Benefits Case | Named benefit owners, measurable outcomes, baseline data, realisation timeline. |
| Cost and Resource Plan | Full-cycle costs including post-delivery. Not just build costs. |
| Risk and Dependency Analysis | Top five risks with mitigation. Dependencies on other programmes. |
| Governance and Accountability | Named sponsor, named programme director, escalation path. |
The benefits section is where most cases fall apart. Benefits need three things to be credible: a baseline, a target, and an owner. Without a baseline, you can't measure improvement. Without a target, you can't define success. Without an owner, nobody is accountable when the benefit isn't realised.
PMI's research consistently shows that organisations with mature benefits realisation practices are significantly more likely to meet their programme objectives. The discipline starts at the business case stage, not after go-live.
Keeping the Business Case Alive Post-Approval
The most common mistake is treating the business case as a static document. Once approved, it gets filed and forgotten. A live business case is reviewed at every major stage gate. Benefits assumptions are tested against emerging reality. If the programme scope changes, the business case is updated.
The business case is the contract between the programme and the organisation. Treat it like one.
If your organisation is preparing a major investment decision or reviewing a programme that has drifted from its original objectives, our team can provide independent assurance on both the case and the delivery approach. Book a 30-minute discovery call.