The cases looked sound. The projects didn't deliver.

There is a particular kind of frustration that comes with being a CFO in a capital-intensive organisation.

The business cases arrive looking sound. The numbers stack up. The assumptions seem reasonable. The risks are listed. You approve them through the right process, with the right governance, and with appropriate scrutiny.

And then the projects don't deliver what they promised. Costs blow out. Timelines extend. Benefits that looked clear at approval become harder to measure, harder to attribute, and eventually stop being tracked at all. And the question that sits uncomfortably in the background is whether the problem started at approval or after it.

Why the distinction matters

If the business cases were genuinely sound and execution let them down, the fix is a delivery problem. If the cases were optimistic, incomplete, or shaped to get approved rather than to reflect reality, the fix is upstream: in how cases are prepared, reviewed and tested before they reach the committee.

In our experience, it is rarely one or the other. We sometimes see organisations where both are true at the same time. Cases that passed scrutiny but carried assumptions that were always fragile. Delivery organisations that inherited those assumptions and built plans on top of them. By the time something visibly fails, the original weakness is buried under layers of subsequent decisions.

The two hundred page business case

Part of the problem is visible in the documents themselves. We recently reviewed a set of business cases. Some ran to two hundred pages.

The length was not accidental. The documents contained everything: market analysis, technical appendices, risk registers, sensitivity tables, stakeholder maps. What they did not contain, in any clear form, was a crisp answer to the question a decision maker actually needs to answer: should we do this, and on what basis?

There is a quote often attributed to Pascal: "I would have written you a shorter letter, but I did not have the time." The same discipline problem sits at the heart of most business cases we review. Brevity requires clarity. Clarity requires hard choices about what actually matters. Those choices are uncomfortable, so the document grows instead.

A well-constructed business case should work something like a good dashboard. A decision maker should be able to scan it in a minute and know what the decision is. Read it in three and understand the key issues. Spend ten and have enough depth to probe and challenge with confidence. Beyond that, you are reading for the author's benefit, not your own.

When a case runs to two hundred pages, one of two things is usually true. The author has not done the hard work of distilling what matters. Or they have, and they would prefer the decision maker didn't look too closely. Either way, the organisation is not making the decision it thinks it is making.

Three things worth testing

Pull three projects that have underperformed and trace them back to their business cases. Ask whether the assumptions that proved wrong were visible at approval, or whether they were genuinely unforeseeable. The answer is usually somewhere in the middle, and that middle is where the real work is.

Ask how benefits are tracked after approval. If the answer is that they are not tracked systematically, or that responsibility for benefits realisation sits with nobody in particular, the cases are being written for approval rather than for delivery.

Ask how often a business case comes back for rework rather than being approved. If the answer is rarely, your review process may be testing compliance rather than quality.

The gap worth closing

The CFO who can clearly separate a case quality problem from an execution problem is in a much stronger position to intervene early, at the right point, with the right response.

Most organisations have not built the system that makes that distinction visible. That is the gap worth closing.