At the closing meeting for a new case-management system at a mid-sized municipality, there is applause: delivered on the agreed date, within the budget of just over a million euros, every agreed piece of functionality built. The project manager gets a pat on the back and the next assignment. Nobody asks the question that still matters a year later: did the thirty percent shorter processing times promised in the business case actually materialise?
That is not an exception. It is the pattern on which after-the-fact evaluation usually stumbles: projects are closed based on whether they delivered what was agreed, not on whether they delivered what was promised.
Two different promises
A project plan promises something different from a business case. The plan promises scope, time and money: this system, by that date, for that budget. The business case promises a benefit: shorter processing times, lower costs, higher customer satisfaction. A project can succeed on the first promise and stay completely silent on the second, and that happens structurally, because after delivery nobody still has the mandate to measure the benefit.
The Dutch Court of Audit already noted this in 2013 for the national government's ICT projects: benefits realisation is monitored too little. Not because nobody considers it important, but because after go-live there is no designated moment left at which anyone still asks the question. The project is finished, the team has disbanded, the next tender is waiting.
What four frameworks have in common
OECD DAC, a widely applied, transferable framework for evaluation developed within development cooperation, puts the benefits-against-promise test first: not "was it delivered" but "did it do what it was supposed to do". The UK's Gate 5, PRINCE2 practice and Stufflebeam's CIPP model, developed independently of each other, arrive at the same core. Four different traditions, one conclusion: an evaluation that only looks at delivery is evaluating the wrong thing.
The question missing at handover
The practical problem is not that organisations lack criteria. The project plan is full of criteria, they are just the wrong type. Scope, time and money are easy to check at delivery: the system runs or it does not, the invoice is there or it is not. A benefit such as 'thirty percent shorter processing time' is only measurable after a period of real use, by which time the go-live has long been celebrated and attention has already shifted to the next project.
That explains why ex-ante testing, mandatory for national government ICT since the Elias committee, is standard practice, while ex-post testing of benefits is not: the first belongs to the moment when everyone is still watching, the second to the moment when nobody is watching anymore.
For a project manager who wants to break this pattern, the first step is not a more elaborate evaluation process, but a different question at delivery: not 'did we build what was agreed', but 'which benefit from the business case will we still test six months from now, and who will do it'. Without that second question, 'on time and within budget' remains the only answer that ever gets given.