The question no one can answer
At the evaluation of a municipal service-delivery project, three years and two reorganisations after it started, someone at the table asks the simplest question there is: what was the goal again? Silence. The original project manager now works for a different municipality. The business case lived in a SharePoint environment that was decommissioned during the last reorganisation. There is a final report, there are quarterly updates, there is a satisfied alderman — but there is nothing left to test against.
Four frameworks, one unspoken assumption
OECD DAC, the UK's Gate 5 review, PRINCE2 practice and Stufflebeam's CIPP model were developed independently of each other, for very different sectors. Yet they arrive at the same building blocks: testing benefits against the promise, independent validation, criteria set in advance, action-oriented lessons. That first point — testing against the promise — assumes something rarely made explicit: that the promise is still findable, legible and unchanged at the moment of evaluation. None of the four frameworks describes what to do if it isn't. They silently assume it simply is.
Why that assumption usually doesn't hold
The Dutch parliamentary Commissie-Elias concluded that too little thought goes into the how and why before ICT projects start, and the basic rules that followed apply only to a project's start: a business case, a go/no-go decision, prior justification. Nowhere is it laid down that those same documents must still exist at completion, let alone in the same form. A three-year project typically survives a few staff changes, at least one interim scope adjustment, and sometimes a reorganisation that reshuffles the entire archive. By the time an evaluation happens, the original promise has often already been rewritten several times — or is simply gone.
The result is an evaluation that doesn't test but talks. Instead of "were the agreed-upon benefits realised," the question becomes "how do we feel about it now" — a fine conversation, but not an evaluation in the sense OECD, Gate 5, PRINCE2 and CIPP intend. The Netherlands Court of Audit already noted in 2013 that mutual organisational learning was still in an early stage; a lost baseline is one of the quiet reasons it stays that way. You cannot learn from a comparison you can no longer make.
What this doesn't solve
A preserved baseline doesn't guarantee learning — who picks up the recommendations afterwards is a separate question, with a separate answer. But without a preserved promise, that question can't even be answered: you wouldn't know where the lesson should come from in the first place.
What to do about it in practice
The fix isn't at the evaluation stage — it's at the start. Record the original goals, assumptions and success criteria in a document that sits apart from the project administration that keeps changing — not a living page that shifts with every adjustment, but a dated version that never gets overwritten. Assign someone to keep that document, independent of whoever happens to be running the project at the time. And when the project closes, pull it up literally before the conversation starts, so the evaluation tests against what was promised — not against whatever has since become the comfortable story.
That is exactly where a tool like EvaluatieScore proves its worth: not by deciding whether a project succeeded, but by making the question "which promise are we testing against" unavoidable before any judgment gets made.