A verification checklist for transformation business cases, focused on the claims that fail unnoticed after approval: baselines, benefits ownership, capacity and exit points.
Transformation cases fail in predictable places, and almost none of them are the technology. This checklist walks the case through those places before the money is committed. No download wall, no email capture. Copy the table and use it.
Last reviewed 3 July 2026 · Free and ungated
Put the business case to selected senior operators who have both delivered and inherited transformations like this one. A confidential report back, through a complimentary first report.
Challenge the assumptions before committingA transformation business case differs from an ordinary investment case in one decisive way: the organisation itself is both the instrument and the subject of the change. That means the case can be financially sound and still fail, because the constraint is not capital but attention, capability and change tolerance. A checklist built for capex approval will not catch that.
| Item to verify | What you are actually checking | The case fails this check when… |
|---|---|---|
| Baseline honesty | Whether "current cost" reflects reality or was inflated to flatter the savings | Nobody can show how the baseline was measured, or finance did not sign it off |
| Benefit ownership | Each benefit line has a named executive whose budget will shrink when it lands | Benefits are owned by the programme, which will be disbanded before they mature |
| Cost completeness | Backfill, change management, data cleanup and decommissioning are all priced in | The case covers licences and the integrator, and little else |
| Capacity check | The people the plan depends on have had their day jobs reduced accordingly | Key people appear in the plan at 50% while still owning full-time roles |
| Sequencing logic | Value arrives in stages, with each stage justified even if the next never happens | All benefit is realised in the final phase, making early phases unfalsifiable |
| Integrator dependency | What the organisation can run without the integrator eighteen months in | Knowledge transfer is a line item, not a plan with names and dates |
| Change load | What else the affected functions are being asked to absorb in the same window | This is the third concurrent "top priority" for the same operational teams |
| Kill criteria | Defined conditions under which the programme stops or restructures | The case has gates in name, but no gate has ever stopped anything here |
| Benefit tracking | How and when realised benefits will be measured, and by whom | Measurement is deferred to a post-implementation review nobody has scheduled |
| Funding profile | Whether spend can actually be released in tranches as evidence accumulates | The full amount must be committed up front to secure vendor pricing |
The checklist belongs between the case being drafted and the case being socialised, because once the executive team has seen a headline number it becomes the anchor for everything after. Finance runs the baseline and cost rows; the operational executives named as benefit owners each verify their own line, in writing; the sponsor sees the completed checklist last, not first. If the sponsor completes it, you have measured enthusiasm, not readiness.
When the consultancy that would deliver the transformation also helped write the business case, no internal review can fully unwind that conflict. This level of structural interest often warrants independent challenge before the recommendation is taken to the board. Operators who have owned a transformation of comparable scale, and carried its benefits case for the following three years, can tell you which lines in yours are load-bearing and which are decoration.
A clean checklist means the case is well built, not that the strategy behind it is right. The check it cannot run is whether this transformation, at this scale, now, beats the alternatives. That question needs people with no stake in the answer.
The gate-review chair or PMO, not the programme. It should be re-scored at every stage gate, because the interesting signal is which answers have degraded since approval. Capacity and change load usually go first.
No. Their answers will be professionally reasonable and structurally self-interested, particularly on dependency, knowledge transfer and sequencing. Ask them to respond to your completed version instead. The gaps between the two documents are the negotiation agenda.