Post implementation review: checking whether the thing actually worked

A post implementation review is held after a project or change has been live long enough to judge it: did it produce the benefits that justified the spend, was the estimate anywhere near right, is the thing being operated as designed, and what should the organisation do differently next time. It is distinct from closing a project down, which is administrative, and it is the step most often skipped — because by the time the answer is knowable, everyone involved is on the next thing.

What a post implementation review should cover

• Benefits claimed in the business case, measured against what actually happened.
• Cost and schedule against the original estimate, and against the first re-baseline.
• Whether the solution is being used as designed, or worked around.
• Defects and incidents since go-live, and whether support load matched the forecast.
• Decisions that turned out well or badly, separated from the people who made them.
• Changes to the delivery process itself, with an owner for each.
• Whether the benefits still being claimed are worth continuing to track.

Why most reviews are useless

Three reasons, and they are all fixable. It is held too early, usually at go-live, when nothing about benefits is knowable yet — three to six months is the usual window. It is run by the people who delivered the work, which turns it into a defence rather than a review. And its output is a document rather than a change: every genuinely useful review produces at least one amendment to how the next project is estimated, governed or tested, assigned to somebody with a date. Without that, the review was a retrospective ceremony.

Compare against the original business case, not the re-baselined plan. Re-baselining is sometimes legitimate, but reviewing against the last approved version is how a project that doubled in cost gets recorded as delivered on budget.

Running one that is worth the time

1. Schedule it at approval time, three to six months after go-live, with a named owner who was not the delivery lead.
2. Pull the original business case and the original estimate before talking to anybody.
3. Measure the benefits with the same definitions used to justify the work — not with new, friendlier ones.
4. Interview users rather than only the project team, and ask what they work around.
5. Separate findings about the solution from findings about the process that delivered it.
6. Convert each process finding into one change with an owner and a date, and report closure.

Ettex Docs holds the review itself as a document per project — business case figures, actuals, findings and recommendations — while the resulting actions live in a register with owners and dates. Pairing the two is what makes the exercise differ from lessons learned collected and never applied.