A municipality of around eighty thousand residents completes the migration of its HR system in 2023. The project runs four months over schedule, the test phase gets shortened, and the supplier only joins the table late in defining acceptance criteria. The evaluation that follows is solid: three recommendations, clearly formulated, properly filed. Two years later, the same municipality starts a comparable migration, this time for the financial system. Test phase too short. Supplier brought in too late. Acceptance criteria decided after the fact.
Nobody had ignored the evaluation. Nobody had even missed it — it simply wasn't in the place the next project manager would look.
A process, not a good intention
American researcher Williams described this pattern precisely back in 2007: without targeted effort and a designated process, lessons rarely make it into an organization's broader policy. That is a different observation from "nobody reads evaluations." They do get read, written, and sometimes even discussed. What's missing is the translation step — from an observation in a project report to a change in a template, a procurement condition, or a quality requirement that the next project manager automatically runs into.
A lessons log is, in that sense, an act of filing, not a learning process. The difference lies in who picks up the recommendation once the project is closed and the team disbanded. Without that owner, an evaluation sinks back to the status of a PDF in a project archive.
What the four frameworks say about it
OECD DAC, the UK's Gate 5 review, PRINCE2 practice, and the CIPP model were each developed independently, for very different sectors, and yet arrive at the same building blocks: testing benefits against the original promise, independent validation, criteria set in advance — and action-oriented lessons learned. That last word, action-oriented, is what makes the difference. A lesson that leads nowhere isn't a lesson, it's a note.
Action-oriented means: a recommendation gets a follow-up action, an owner, and a deadline, just like any other project action item. Not "we'll take this on board," but "the quality officer updates the acceptance template before 1 October, and that template is mandatory for the next IT tender."
Three steps that make the difference
For project managers and PMOs who recognize this pattern, three adjustments help, without needing a new system:
First: log every evaluation recommendation separately in a central register, apart from the full report. A twenty-page report doesn't get consulted; a line in a register with a status does.
Next: assign an owner to each recommendation who is not the project team. The team disbands after delivery — the recommendation only survives that if someone outside the project is responsible for it.
Finally: review templates, checklists, and procurement conditions against that register at least once a year. That is the moment a lesson actually becomes policy, instead of staying history.
The municipality in the example didn't need an extra evaluation to prevent the second mishap — the first evaluation was already enough. What was missing was a process that let the recommendation land after everyone had already moved on to the next project.