Last updated 2026-08-05
The post-project review that changes the next project
The short answer
Most post-project reviews fail for a structural reason, not a discipline one. They ask a team to remember, months after the fact, what it expected to happen, after everyone already knows how the story ended. The fix does not live in the review meeting. It lives at the approval gate, before the project starts, which is the only moment nobody yet knows the answer. Almanexa records the expected benefit there, and every decision that changes the plan as it happens, so the review that follows is a comparison instead of a memory exercise.
Why the review usually fails
Hindsight rewrites memory without anyone intending it to. Ask a team what it expected once a project has already landed, and the answer tends to sound close to what happened, because that is how memory works, not because anyone is lying. Call it a post-project review, a post-implementation review or a project retrospective, the failure mode is identical: a memory exercise held too late. The Project Management Institute finds that 83 percent of organizations lack maturity in benefits realization, so the expected benefit sits in the business case and nobody ever checks it again. A separate 2023 study put the cost of poor knowledge management at roughly 2.4 million pounds a year per organization, which is exactly what a lessons learned programme exists to prevent and exactly what most of them fail to do. Programmes that depend on someone remembering to circle back rarely survive contact with a calendar either: research on quarterly goal programmes found around 60 percent abandoned within a year, 70 percent within two.
Record the expected benefit at the gate
Fix it at the moment the project is approved, not at the moment it closes. When a project gets its sign-off, record the expected benefit in Almanexa as a number, the date it should be visible by, and how it will be measured. This is usually already sitting in the business case. The only change is that it gets recorded as a locked expectation rather than a paragraph nobody revisits, so there is something specific to grade later instead of a general sense that the project went fine.
Capture the decisions that change the plan
A project is not one decision, it is dozens, and each one deserves the same treatment as the original business case: what was decided, what the team expected to happen because of it, recorded at the time it was made, not reconstructed afterward.
- Scope gets cut. Record what the cut is expected to save or cost, at the moment it is cut.
- A vendor gets swapped. Record what the new one is expected to deliver instead.
- A deadline slips and gets defended. Record what the slip is expected to protect.
By the time the project closes, you have a chain of graded decisions instead of one blurry verdict on the whole effort.
The review becomes a comparison, not a discussion
With the expectations already on record, the review stops being a meeting where people try to agree on what they meant months ago. It becomes a comparison: here is what we expected, here is what happened, here is the gap. That is a shorter meeting and a more honest one, because nobody is defending a memory anymore. They are reading a record.
What leaves the review
The review should produce an approved lesson, not just a summary. A lesson is attached to the specific type of decision it affects, whether that is vendor selection, scope changes or estimation, and it needs a sign-off from someone who was not the author of the original decision, never the same person who made the call. That second approver is a small piece of project governance, and it is what makes the lesson trustworthy to a team that was not in the room. Once approved, Almanexa writes it to a tamper-evident record, and the next project meets that lesson before it makes the same call, not after.
Read what decision memory is for the record this stands on, or see why lessons learned programmes fail for the habit this replaces.
Questions we hear
- When should the review happen?
- Twice, in effect. The expected benefit is recorded when the project is approved, before work starts, because that is the only moment nobody yet knows the outcome. The review itself can still happen at the end or at any governance milestone; what changes is that it now compares against something recorded months earlier, not a memory.
- Who should attend?
- Whoever can speak to what actually happened, plus at least one person who was not involved in the decisions under review. That second, different approver is what turns a discussion into a sign-off: the lesson is only approved by someone with no stake in defending the original choice.
- What if the expected benefit was never written down?
- Start now. A decision cannot be graded retroactively, an expectation written after the outcome is known is not a prediction, so the project already underway will not get a clean comparison. The next project can, if you record its expected benefit at the approval gate. That is the one that benefits.