EvaluatieScore Blog
Insights on learning value, project evaluations and AI
An evaluation that's not on the calendar never happens
Evaluations rarely fail because of unwillingness — they fail because no moment for them was ever scheduled. What four evaluation frameworks and Williams' research say about that, and how to fix it.
Read more →Independent evaluation doesn't start with an external auditor
Four frameworks call for independent validation, but in practice that often means an auditor or no one at all. Between those extremes lies a range of workable forms, if you choose one in time.
Read more →Which promise are you testing against, if no one remembers what it was?
Four evaluation frameworks assume you test against the original promise — but after reorganisations and staff turnover, that promise is often nowhere to be found. What that means in practice for anyone evaluating a project.
Read more →A recommendation without an owner disappears by itself
An evaluation with good recommendations rarely changes anything, because no one outside the project team owns the follow-up. Three concrete steps make sure a lesson actually lands in policy.
Read more →Why the Lesson from This Project Never Reaches the Next One
An evaluation can be independent and thorough and still go nowhere: without a designated process, a lesson rarely crosses over to the next, comparable project.
Read more →What an evaluation actually delivers — and what remains unproven
There is little hard evidence that a good evaluation leads to better subsequent projects. What is demonstrable: four independently developed frameworks point to the same four building blocks for a meaningful evaluation.
Read more →The PRINCE2 Practice Produces a Lessons Log. Rarely an Evaluation.
PRINCE2 projects routinely produce a lessons log, but that isn't the same as an evaluation. Three small additions — criteria set in advance, an independent reader and an owner for follow-up — make the difference.
Read more →Why the yardstick for a project needs to exist before the project starts
Four independent evaluation frameworks arrive separately at the same building block: success criteria set in advance, not filled in afterwards. What that actually requires from a project evaluation.
Read more →Four independent frameworks, the same four building blocks for an evaluation
OECD DAC, the UK's Gate 5 review, PRINCE2 practice, and Stufflebeam's CIPP model were developed independently of each other — yet they converge on the same four building blocks for an evaluation.
Read more →The blind spot of self-evaluation is a lack of independence
Four independently developed evaluation frameworks point to the same thing: whoever led the project shouldn't be the only one judging whether it succeeded. What that means for your next evaluation.
Read more →Why we don't make a hindsight-bias claim
Hindsight bias and self-serving bias are appealing explanations for why evaluations often turn out too positive. Our own source research found no evidence specifically about ex-post project evaluations — so we don't use that claim.
Read more →Why 'we'll debrief on it afterwards' is not an evaluation
An informal debrief feels like an evaluation, but it usually lacks the essential ingredient: a pre-set question, scope and criteria. That distinction is the first category on which EvaluatieScore assesses a report.
Read more →From plan to evaluation: the entire project lifecycle in six tools
CaseCheck for the business case, PlanScore for the plan of approach, RisicoRadar for risks, StakeholderScan for the environment, RapportageScore during execution, and EvaluatieScore for the evaluation afterwards. One coherent suite spanning a project's entire lifecycle.
Read more →'The mutual learning process is still in its early stages' — what the Court of Audit already saw in 2013
In 2013, the Dutch Court of Audit concluded that central government's learning capacity around IT projects was still immature. Has that improved since, or do we still recognise the pattern in most organisations?
Read more →The gap between ex-ante and ex-post: why every major IT project is tested beforehand, and almost never afterwards
The Elias committee made sure major IT projects are now tested beforehand as a matter of course. What happens to a project afterwards is, in the Netherlands, nobody's assigned responsibility. That instrumental gap is the sharpest finding from our source research.
Read more →The CIPP model by Stufflebeam asks four questions for a structured retrospective
Context, Input, Process, Product. The CIPP evaluation model by Daniel Stufflebeam offers a methodological foundation for project evaluation — including a requirement that most evaluation reports skip: the meta-evaluation.
Read more →Gate 5: how the British government independently checks whether promised benefits actually materialised
The UK Infrastructure and Projects Authority has an assurance moment specifically designed to check, after delivery, whether benefits have been realised: Gate 5. It is one of the few authoritative examples of a genuine ex-post review moment.
Read more →Documenting is not the same as learning
A lessons-learned report that disappears into a drawer changes nothing. Williams (2007) examined why lessons from projects rarely land in an organisation's broader policy — and what is actually needed.
Read more →Six OECD DAC questions for every project evaluation
Relevance, coherence, effectiveness, efficiency, impact, sustainability. The OECD DAC criteria were developed for development cooperation, but they are six questions that belong in almost every project evaluation.
Read more →Benefits-realisation governance falls through the cracks after delivery
Every business case promises benefits. A project gets delivered. And then? In most organisations, benefits realisation governance falls through the cracks at exactly the moment the project team is disbanded.
Read more →