A business case that exists only to get a program funded and a business case that can actually be checked against later are two different documents, even when they look identical at kickoff. The gap between them is a major reason roughly 73% of organizations can't prove ROI on their transformation investment months after go-live — the business case promised value nobody was ever assigned to track.
The Funding Pitch vs. the Defensible Case
A funding pitch optimizes for approval: it makes the strongest possible argument for why the investment should happen. A defensible business case optimizes for accountability: it specifies exactly what will be measured, who owns each benefit, and what the baseline looks like before the program starts. Most business cases are written entirely as funding pitches, and the accountability structure that would make them checkable later is never built.
What a Defensible Business Case Requires
Named benefit owners. Every projected benefit needs a specific person accountable for realizing and reporting it — not "the department" generically, but a name.
Baseline metrics captured before the program starts. Without a documented "before" state, there's no credible way to prove the "after" state was actually caused by the transformation rather than some other factor.
A distinction between hard and soft benefits. Cost reductions and cycle-time improvements are directly measurable; "improved employee satisfaction" is real but needs a different, more honest measurement approach than the hard-dollar figures nearby it on the same slide.
Assumptions stated explicitly. What has to be true for the projected benefits to materialize — adoption rates, process compliance, data quality — should be documented as assumptions, not left implicit, so they can be checked as the program progresses.
Where This Connects to the Rest of the Framework
A business case is the entry point to the Value dimension of the AMIGA Framework, but it depends on Governance for benefit ownership to actually mean something (someone needs the authority to hold that owner accountable) and on Data for the baseline metrics to be trustworthy in the first place.
Carry the Business Case Through to Benefits Tracking
A business case that stops at approval and never becomes a tracking mechanism is most of the reason benefits evaporate. The Benefits Tracking Template is built to extend a business case's projected benefits into an ongoing measurement process.
Read more on measuring transformation value →
Frequently Asked Questions
Who should write the business case — finance or the program team?
Both, working together. Finance brings rigor to the ROI calculation; the program team brings the operational realism about what's actually achievable, which finance alone often can't assess.
Should a business case include soft benefits at all?
Yes, but they should be clearly separated from hard, dollar-measurable benefits and given an honest, appropriate measurement approach — burying soft benefits inside a hard-dollar total undermines the credibility of the whole business case.
What happens if actual results don't match the business case?
A mature process documents the variance and the reason for it rather than quietly revising the original numbers after the fact — that documented gap is valuable data for the next program's business case.
Instagram