The Business Case Dies When Funding Is Approved
A business case that ends at approval is not a case; it is a sales document.
The number that wins the meeting
The figure on page twelve is 38 per cent.
It is the promised return on a £24.6 million programme to replace several customer and order systems, introduce a common database and open a new Internet channel. The calculation is precise: fewer clerical staff, shorter call times, higher repeat sales, lower printing costs and a twenty-two-month payback.
The investment committee debates the assumptions for forty minutes. Finance reduces the sales-growth estimate. The programme sponsor accepts a higher contingency. Approval is granted.
Two years later, the programme will still report its expenditure to the nearest thousand pounds. Nobody will be able to say whether the 38 per cent was achieved.
This is not unusual. It is how many organisations now use the business case: as a persuasive instrument before approval, then as an archived document after it. The cost forecast becomes a control baseline. The benefit forecast becomes history.
A business case that ends at approval is not a case; it is a sales document.
The theatre has a script
The textbook account is orderly. A proposal identifies an opportunity, compares options, estimates costs and benefits, discounts future cash flows, tests assumptions and recommends an investment. Once approved, the programme delivers the change and the organisation realises the return.
The lived version is less elegant.
Sponsors know that scarce capital follows confident numbers. Project teams are asked to show a favourable return before they have designed the new work in detail. Benefits that belong to several functions are assembled into one total, although no single executive controls them. Intangible gains are converted into financial values to make the arithmetic complete. Risk is placed in a separate section, while the headline return remains untouched.
The result looks analytical because it contains a spreadsheet. But the precision often conceals a negotiation.
A customer system, for example, may promise a 12 per cent reduction in call-handling time. That saving exists on paper only if four other things occur: procedures are simplified, staff are trained, supervisors change their measures and the released time is either removed from the cost base or used to handle more business. The system can make the improvement possible. It cannot perform those management decisions.
When nobody owns those decisions, the benefit is counted before approval and orphaned after it.
Costs belong to the programme. Benefits belong to the business—and that is precisely why benefits disappear from view.
Delivery success can hide investment failure
Programme governance is usually built around what the project manager can control: scope, schedule, expenditure, defects and implementation risk. Those are necessary disciplines. They are not the same as value.
Consider a composite programme approved with £18 million of expected benefit over three years:
- £7 million from reducing 140 administrative posts
- £5 million from improved customer retention
- £4 million from fewer billing errors and disputed invoices
- £2 million from reduced stationery, postage and storage
At go-live, the system is delivered within 6 per cent of budget and six weeks of plan. It is declared successful.
But only 32 of the 140 posts are actually removed; the remaining capacity is absorbed by old reporting and reconciliation work. Customer retention is not measurable because the original baseline used a different definition. Billing errors fall, yet the finance function does not record the value of disputes avoided. Paper use declines, but new promotional mailings consume much of the saving.
The programme has delivered its outputs. The investment has not delivered its case.
This distinction is uncomfortable because it crosses the boundary between technology and management. The project team can install software, convert data and train users. It cannot, on its own, simplify policy, remove a management layer, change sales incentives or stop a redundant report. Yet those actions frequently carry most of the promised return.
The business case bundles them together to secure approval, while the delivery plan quietly narrows to the things the programme can build.
The strongest defence of the present system
There is a serious argument against relentless benefit measurement.
Not every investment can be reduced to a clean financial return. Some expenditure is necessary to maintain service, satisfy a fixed obligation or keep pace with changing customer expectations. Market conditions move. Competitors act. Baselines become stale. Attempting to attribute every revenue movement to one programme can create more bureaucracy than insight.
That objection is correct. False measurement after approval is no better than false precision before it. A business should not spend months proving that one system caused a small change in sales when many forces were at work.
But uncertainty is not a reason to abandon accountability. It is a reason to state it honestly.
A credible case distinguishes among three kinds of benefit:
| Benefit type | What can be promised | What must be tracked |
|---|---|---|
| Direct saving | A defined cost can be removed | The budget line, date and accountable manager |
| Capacity gain | Time or volume can be released | How the capacity will be redeployed or removed |
| Strategic effect | A better position may be created | The leading evidence, assumptions and decision points |
This does not eliminate uncertainty. It prevents unlike claims from being added together as though they carried the same confidence.
Benefits need owners before they need numbers
The remedy is not a more elaborate financial model. It is a change in ownership.
Every material benefit should have one named executive who controls the business action required to realise it. That owner should accept the baseline, the measure, the timing and the consequences if the benefit does not appear. If no executive can own a benefit, it should not sit in the case as a committed return.
The practical disciplines are simple, though not easy:
- Fix the baseline before approval. Record the present cost, volume, error rate or service level and the method used to calculate it.
- Separate enablement from realisation. State what the programme will deliver and which management action converts that output into value.
- Name one benefit owner. Committees can oversee; they cannot own.
- Put benefit actions in the plan. Policy changes, staff reductions, training, process redesign and the retirement of old systems require dates and resources.
- Review the case at decision points. If assumptions change, revise the return openly rather than preserving the original figure for appearances.
- Continue after implementation. Close the project when delivery ends, but keep benefit reporting with the operating business until the agreed result is reached or explicitly abandoned.
This makes some proposals look weaker. That is a virtue. It also reveals when a strategically sensible investment rests on judgement rather than measurable savings. Boards are capable of making such decisions—provided the papers do not pretend that judgement is arithmetic.
The current correction should reach the business case
The enthusiasm surrounding Internet ventures and large systems programmes has encouraged a particular style of case: high growth, rapid payback and benefits spread across the enterprise. The recent fall in technology share prices is a reminder that persuasive forecasts do not become true merely because many people accept them.
The same discipline now being applied to market promises should be applied inside organisations.
Ask of every approved programme:
- Which benefits remain valid?
- Which assumptions have changed?
- Which executive owns each business action?
- Which costs will actually leave the budget?
- What evidence would cause the investment to stop, narrow or change direction?
These questions are not an audit after the event. They are part of managing the investment while choices still exist.
The business case should remain alive precisely because the world does not stand still. Its purpose is not to prove that the original sponsor was right. Its purpose is to help leaders decide whether the organisation should continue committing money, attention and disruption in pursuit of the promised value.
A strong business case does not end with a convincing return. It begins with an accountable one.