Every significant investment requires a business case. The team builds one using detailed models showing strong ROI, benefit projections that justify the cost, a clear narrative for approval.
Three years later, the investment has delivered a fraction of the projected benefits. The business case is forgotten. The executive who sponsored it has moved on. The spend has become part of run-rate cost, and nobody has formally reviewed the outcome.
The Optimism Bias
Business cases are advocacy documents presented as analysis. The team building the case wants approval. Every assumption therefore tilts in a favourable direction: revenue ramps faster, costs come in lower, adoption is higher, and competitive response is absent.
It is human nature combined with investment in the outcome.
Finance's job is to stress-test those assumptions before approval. What if revenue ramps 30% more slowly? What if costs are 20% higher? What if adoption is half the projected rate?
Run sensitivity analysis. Push teams to defend their assumptions against historical performance. If the previous three comparable initiatives took 18 months to break even, the justification for a 6-month payback needs to be specific and credible.
The objective is not to kill good investments. It is to approve them with honest numbers.
Benefits Realisation
Business cases tend to have detailed cost projections and loosely defined benefit assumptions. Costs are grounded in vendor quotes and implementation plans. Benefits are expressed as estimates like "we expect a 20% improvement in productivity."
Costs materialise reliably. Benefits often do not, because nobody is specifically accountable for capturing them and nobody measures whether they were actually achieved.
Make benefits realisation an explicit part of the business case. How exactly will these productivity improvements be captured? Who is responsible for ensuring they translate into actual cost reduction or increased capacity? What is the measurement plan and timeline?
If you cannot answer those questions concretely, the benefits should not be in the business case. This forces teams to think through the organisational change required to realise value, not just to implement technology.
The Sunk Cost Problem
Two years into a three-year programme that is clearly not delivering its projected benefits. The response is to continue because the investment so far must not be wasted.
This is the sunk cost fallacy, and businesses fall into it regularly despite knowing better.
The money already spent is gone regardless of what happens next. The only question worth asking is given what we now know, should we commit the remaining budget? Often the honest answer is no.
Build formal decision checkpoints into every business case at the outset and at defined milestones, we will evaluate actual results against projections and make a conscious decision to continue, pivot, or stop. Make it explicit that stopping is a legitimate and responsible outcome, not a failure.
The "Strategic Value" Escape Hatch
When the financial case is weak, the pivot is often to strategic value: "This is not really about ROI, it is about strategic positioning" or "competitive necessity."
Sometimes that is a legitimate argument. Sometimes it is a way to avoid accountability for returns.
If the investment is genuinely strategic, make the strategic logic specific like what capability does it build? What option value does it create? What competitive disadvantage does it prevent? Then measure against those strategic outcomes, not financial returns. But "it is strategic" should not function as a blanket exemption from delivering value.
Post-Implementation Reviews
How many investments does your organisation formally review two to three years post-implementation to compare actual outcomes with business case projections?
If the honest answer is very few or none, you have no feedback loop. You cannot improve business case quality if you never close the loop on whether previous cases were accurate.
Require post-implementation reviews for investments above a meaningful threshold. The purpose is to understand which assumptions were wrong and improve the next case.