Your business case promises a benefit. Who exactly has to do something differently for it to arrive — and has anybody asked them?
Benefit cases rarely fail loudly. A target is restated, then extended, then folded into a later programme’s case, and at no point does anybody record that the original investment did not produce what it promised.
The reason is usually visible from the start, if anybody looks.
No business case is realised by a system. Every benefit requires somebody to do something differently, and those requirements are assumptions. They are rarely written down, never tested, and they are the part that fails.
The exercise takes an afternoon. Take each benefit and write one sentence naming who has to do what differently. Then ask three questions about it.
Is this assumption written down anywhere, or is it implicit in the calculation? Is it in that group’s interest? Does anything contradict it — a target, an incentive, a policy pointing the other way?
An assumption that fails the first test is fixed by writing it down and giving it an owner. One that fails the second needs a decision about redistribution. One that fails the third is a governance action, and no amount of project effort will touch it.
In most implementations at least one assumption fails at least one test. It is nearly always the largest benefit.
Chapter 8 of Built to Be Used works through the three questions with a completed example.
#BusinessCase #BenefitsRealisation #ChangeManagement
This article accompanies the book Built to Be Used.