Pre-contract

Why the business case is the cheapest place to fix a programme

Every capital programme inherits the assumptions baked into its business case. Get them wrong and every stage after pays to correct them. Get them challenged early and the correction is almost free.

A business case is usually written to clear a hurdle. There is funding to secure, an approval body to satisfy, a gateway to pass. So the document is built to win a yes, and once the yes arrives it is filed. The programme moves on to the things that feel more real: procurement, design, delivery. The case that justified the whole endeavour is rarely opened again.

This is a mistake, and an expensive one, because the business case is the most leveraged document in a capital programme. Everything downstream inherits its assumptions. The budget, the schedule, the scope, the benefits the organisation has publicly promised to deliver, all of them flow from decisions taken, often quickly and under pressure, at the business-case stage. An error introduced there does not stay there. It is procured against, contracted around and built on top of, growing more expensive to correct at every step. The business case is the cheapest place in the whole programme to fix a problem, precisely because nothing has yet been committed.

The symptoms surface much later and wear other names. A programme that cannot hold its budget. A benefits case that no longer adds up when it is reviewed two years on. A scope that has grown without anyone quite deciding it should. An organisation defending a programme it can no longer cleanly explain. These look like delivery and commercial problems, and they are managed as such, but a good number of them were set in motion the day a thin or optimistic business case was approved and then forgotten.

A decision, not a document

The first confusion is treating the business case as paperwork rather than a decision. Its real job is to answer three questions honestly: is this worth doing, can it be done for what we think it will cost, and will it deliver the benefits we are claiming. When the case is written to pass approval rather than to answer those questions, the answers get shaded. Costs are presented at their most optimistic, risks at their most manageable, benefits at their most generous. The document passes. The decision it was meant to inform was never really tested.

Optimism is designed in

Capital programmes have a long and well-documented habit of arriving late and over budget, and the roots are usually visible in the business case. Optimism bias is real and pervasive: estimators and sponsors, acting in good faith, tend to assume the better end of every range. There is also a less innocent version, in which the numbers are quietly shaped to fit the funding available or the answer the organisation has already decided it wants. Either way, the case sets a baseline the programme cannot actually hit, and the gap between the promise and the reality becomes someone else's problem two years later. Government guidance exists precisely to correct for this, but an optimism adjustment applied mechanically, with nobody genuinely challenging the underlying numbers, simply moves the optimism somewhere less visible.

Benefits are the first thing forgotten

A business case is approved on its benefits. A programme is delivered on its cost and its schedule. That asymmetry is where a great deal of public money quietly loses its purpose. Once delivery is under way, attention flows to the things with deadlines and invoices attached, and the benefits, the entire reason the spend was justified, slide out of view. Scope is trimmed to protect the budget, and the parts trimmed are often the parts that delivered the outcome. A programme can complete on something close to time and cost and still fail the test it was funded against, because what it built no longer delivers what was promised. A case that is never checked back against delivery cannot catch this happening.

The case that is never revisited

Approved once and shelved, a business case ages badly. Costs move, scope evolves, the world around the programme changes, and the live programme slowly stops resembling the case that justified it. The most useful discipline a sponsor can adopt is to treat the business case as a living test rather than a one-off gate, returning to it at each major decision and asking the unfashionable question: knowing what we now know, is this still worth doing, and is this still the best way to do it. Programmes that ask that early can stop, re-scope or re-baseline while it is still cheap. Programmes that never ask it tend to find out the answer when it is not.

Why challenge is worth most here

The people who write a business case are, almost by definition, invested in its approval. That is not a criticism, it is structural. The team that has worked the proposal up wants it funded, and is the worst placed to mark its own assumptions. This is exactly where an independent, experienced read pays for itself many times over. A reviewer with no stake in the answer can ask whether the cost estimate is credible, whether the benefits are real and measurable, whether the risks have been faced or finessed, and whether the thing is genuinely deliverable by the organisation proposing it. Carried out before approval, that review costs a few days. The same problems, left in, cost months or years.

None of this calls for a heavier process or a thicker document. It calls for the business case to be treated as what it actually is: the decision on which everything else rests, and the one point in the programme where being wrong is still free to fix. Everything after it is more expensive. It is worth being sure, and worth having someone independent, with no stake in the answer, be the one to ask whether the case truly stands up.