A post implementation review is a structured assessment carried out after a project has gone live, comparing what the project actually delivered against what it promised. It is usually run somewhere between one and six months after go-live, once the thing you built has been in real use long enough to judge. The output is a short report: what was delivered, whether the benefits in the business case have started to appear, what the project cost against its forecast, and what the organization should do differently next time.
It is often shortened to PIR, and in change management the same three letters mean the same review applied to a single change rather than a whole project. The review is not a performance appraisal of the project manager, and it is not the closure paperwork. Closure confirms the work stopped cleanly. The post implementation review asks the more uncomfortable question: was any of it worth doing.
Key takeaways
- Run it after go-live, not at handover. One to three months is typical for most business projects, three to six for anything whose benefits build slowly.
- Someone other than the project manager should facilitate it. Self-assessment produces polite findings.
- Anchor every question to the original business case. Without that baseline the review turns into opinions about how the project felt.
- Separate three things: did we build it, did it work, and did it pay. Most reviews only answer the first.
- The report should be short. Two to four pages with owners and dates beats a forty-slide deck nobody opens.
- A lesson with no owner is not a lesson. It is a sentence.
- PIR findings belong in the portfolio forum, not in a folder. If nothing changes upstream, stop running them.
What is a post implementation review?
A post implementation review is a formal evaluation of a completed project, held after the deliverables are in live use, to determine whether the project met its objectives and delivered the value it was approved on. It looks backward at delivery performance (scope, cost, schedule, quality) and forward at benefits, and it produces recommendations that are meant to change how the next project runs.
The distinction that matters is between output and outcome. The output is what the project handed over: the system, the process, the building, the migration. The outcome is what changed in the business because of it. A project can hit every milestone, land on budget, and still deliver nothing, because the output was never the point. The post implementation review is the only governance event that is specifically designed to notice that.
Most organizations have some version of this in their methodology. It appears as the closing gate in a stage gate process, as a mandatory step in change management, and as a required review in public sector and regulated environments. In practice the step is written into the process and skipped in the field, because by the time it is due the team has been reassigned and nobody owns it.
When should a post implementation review be conducted?
Run the post implementation review once the deliverable has been in genuine use long enough to produce evidence, but soon enough that the people who built it can still remember why they made the decisions they made. For most projects that window is one to three months after go-live. For projects whose benefits accrue slowly, such as a process change or a platform migration, three to six months is more honest.
Two timing mistakes are common. The first is holding the review at handover, which is really a closure meeting in disguise: nothing has been measured yet, so the review can only discuss how delivery felt. The second is waiting a year, by which point the team has dispersed, the memory of the decisions is gone, and the evidence has been overwritten by everything else that happened.
A practical compromise for larger programs is two passes. A short delivery retrospective within a couple of weeks of go-live while the detail is fresh, then the benefits-focused review a few months later. Keep them separate. Mixing them produces a meeting where the delivery grievances crowd out the benefit question every time.
| Project type | Run the PIR | Why |
|---|---|---|
| Software or system rollout | 4 to 12 weeks after go-live | Adoption and defect rates stabilize; early usage data is available |
| Process or operating model change | 3 to 6 months | New behavior takes at least a quarter to settle |
| Cost reduction program | 2 to 4 quarters | Savings show up in actuals, not in the plan |
| Construction or physical asset | 3 to 6 months after occupancy | Running costs and defects surface in use |
| Single change request (ITIL sense) | Within days | The question is narrow: did the change work and did it break anything |
Who is responsible for the post implementation review?
The project sponsor owns the review, the PMO usually facilitates it, and the project manager contributes evidence rather than grading their own work. That separation is the single biggest determinant of whether the findings are usable. When the project manager runs their own post implementation review, the report tends to conclude that the project went well given the circumstances.
The room should include the sponsor, the business owner who now lives with the result, one or two people from the delivery team, a representative of the end users, and whoever will inherit support. For anything with a compliance dimension, add the relevant control owner. Keep it under about eight people. Above that it becomes a presentation.
The project sponsor matters here more than anywhere else in the lifecycle, because the sponsor is the person who signed the business case and is therefore the only one who can credibly say whether the promise was met. If the sponsor has moved on and nobody replaced them, that fact is itself a finding worth writing down.
The post implementation review process, step by step
- Retrieve the baseline. Pull the approved business case, the original scope statement, the approved budget and schedule, and the benefits profile. If any of these cannot be found, note it and carry on; that gap will explain a lot of what follows.
- Gather evidence before the meeting. Actual cost, actual dates, change requests approved, defects raised since go-live, usage or adoption data, and whatever benefit measures exist. The meeting is for interpretation, not for data collection.
- Survey the people who were not in the delivery team. Users and operational staff see different failures than the project did. A short questionnaire sent a week ahead gets you honest input that nobody will volunteer in a room with the sponsor in it.
- Hold the review session. Ninety minutes is usually enough with the evidence pre-read. Work through outputs, then delivery performance, then benefits, in that order, because the first two are factual and warm people up for the third.
- Separate causes from complaints. "Requirements kept changing" is a complaint. "We approved the business case before the operating model was agreed, so requirements moved for four months" is a cause you can act on.
- Assign owners and dates to every recommendation. Anything without both is deleted from the report.
- Report upward and close. Send the report to the sponsor and the governance forum, log the outstanding benefit measures with whoever tracks them, and formally close the project record.
Steps 1 and 2 are where most reviews quietly fail. If the baseline was vague, and many are, the review cannot conclude much. That is worth saying plainly in the report, because it is the finding most likely to improve the next project: the quality of the closing review is capped by the quality of the project business case that opened it.
Post implementation review questions
These are the questions worth asking, grouped so the session moves from fact to judgment. Cut the ones that do not apply rather than asking all of them badly.
Outputs: did we deliver what we said?
- What was in the approved scope, and what was actually handed over?
- Which requirements were descoped, and who approved the descoping?
- Are the deliverables in live use, partially in use, or shelved?
- What quality issues have surfaced since go-live, and at what rate?
Delivery: how did it go?
- Final cost against approved budget, and what explains the variance?
- Final delivery date against the approved date, and where did the time go?
- How many change requests were raised, and what drove them?
- Which risks in the register actually materialized, and which real problems were never on it?
- Were the right people available when the plan assumed they would be?
Benefits: did it pay?
- Which benefits in the business case have started to appear, and what is the evidence?
- Which benefits are now clearly not going to arrive, and why?
- Who owns each remaining benefit measure, and when is the next measurement due?
- What is the ongoing run cost, and was it in the original case?
- If we were asked to approve this project again today with what we now know, would we?
Organization: what should change?
- What would we do the same way again?
- What decision, made earlier, would have saved the most time or money?
- Which of our own processes got in the way?
- What should a project like this be required to have before approval next time?
That last group is the reason the review exists. The first three groups describe one project. The fourth changes the portfolio. A review that produces four lessons about one project and nothing about the system that produced it has not earned its hour.
What goes in the post implementation review report
Keep it to two to four pages. The audience is a sponsor and a governance forum, both of whom will read the first page and skim the rest. A workable structure:
| Section | Contents | Length |
|---|---|---|
| Summary and verdict | What the project set out to do, what it delivered, and a plain judgment on whether it met its objectives | Half a page |
| Delivery performance | Baseline against actual for cost, schedule, and scope, with the reasons for variance | A table plus a short paragraph |
| Benefits status | Each benefit from the business case, its current status, the evidence, the owner, and the next measurement date | One table |
| What worked | Practices worth repeating, stated specifically enough to copy | Three to five bullets |
| What did not | Root causes, not symptoms, and not individuals | Three to five bullets |
| Recommendations | Each with a named owner and a due date | A table |
| Outstanding items | Open defects, unreleased resources, contracts still running, benefits still to be measured | A short list |
Two rules keep the report honest. Name causes, not people: the report is read by people who were in the project and it will stop being useful the moment it becomes a place where blame gets recorded. And do not soften the verdict. A review that concludes every project was broadly successful teaches the organization nothing and will be cancelled within two years, correctly.
How to tell whether the benefits actually landed
This is the hard part, and it is where most reviews retreat into anecdote. The difficulty is attribution. Sales went up after the new system launched, but sales also went up in the two regions that never got it. Handling time fell, but the team also lost two people and stopped doing a task. Proving that the project caused the change requires a comparison you have to set up in advance.
The practical options, in descending order of rigor: a genuine control group, where part of the organization keeps the old way for a period; a before-and-after comparison with the known confounders written down and adjusted for; and a stakeholder judgment, which is what you fall back on when neither of the first two was arranged. Say which one you used. A number presented without its method invites more confidence than it deserves.
For software rollouts you generally have more options than you think, because teams that ship behind feature flags and measure releases against a holdback group can answer the attribution question with data instead of argument. Where that was not set up, the review should record it as a recommendation for next time rather than pretending the before-and-after chart settles it.
Whatever the method, the review is a checkpoint and not the end of benefit tracking. Most benefits in a business case are profiled over two or three years, so the post implementation review can only report on the early part of the curve. The rest belongs to benefits realization management, with the measurement schedule set out in the benefits realization plan. The review's job is to hand those measures to a named owner and make sure someone is still watching.
Post implementation review vs lessons learned vs project closure
These three overlap and get used interchangeably, which is why organizations sometimes do all three badly instead of one well.
| Post implementation review | Lessons learned | Project closure | |
|---|---|---|---|
| Core question | Did it deliver the value it promised | What should we do differently | Is everything properly finished |
| Timing | 1 to 6 months after go-live | Continuous, plus a session at the end | At handover |
| Owner | Sponsor, facilitated by the PMO | Project manager | Project manager |
| Main output | A verdict and recommendations | A log of transferable insights | Signed acceptance, released resources, closed accounts |
| Looks at benefits | Yes, centrally | Rarely | No |
Lessons learned sits inside the post implementation review as one section, but it is also collected throughout delivery rather than only at the end, which is the better practice. Much of the raw material is already sitting in the project's RAID log: the risks that turned into issues, the assumptions that proved wrong, and the dependencies that slipped. Reading the RAID log back at review time is the fastest way to find real causes rather than remembered ones.
What is a PIR in change management?
In change management, and particularly in ITIL practice, a post implementation review is the assessment carried out after a change has been deployed to confirm it achieved its intended result, caused no unintended damage, and can be formally closed. It is the same idea applied at a much smaller scale, so it happens within days rather than months, and it is often a checklist completed by the change owner rather than a meeting.
The scope is narrower: did the change do what the change request said, were there incidents attributable to it, did the back-out plan need to be used, and should anything about the change process itself be adjusted. Major or failed changes normally trigger a fuller review with the change advisory board. Routine standard changes usually get a light confirmation or none at all, which is the correct trade.
Why post implementation reviews get skipped
The reasons are consistent across organizations, and none of them are that people think reviews are a bad idea.
The team is gone. At go-live the project manager is already on the next thing and the delivery team has been redeployed, so by the time the review is due there is nobody left whose job it is. The fix is calendar-based: schedule the review date at approval, in the business case, and make the sponsor the owner rather than the project manager.
Nobody wants the answer. If a review might conclude that a project the executive sponsored did not pay for itself, there is a quiet incentive not to hold it. This is the real reason reviews get deprioritized, and it is fixed structurally rather than culturally: make the review a mandatory condition of project closure and of releasing the final budget tranche, so skipping it is visible.
Nothing happened last time. Teams stop contributing to a process whose output disappears. If the previous four reviews produced recommendations that were filed and never actioned, the fifth will be attended by people going through the motions. The countermeasure is to give the findings a standing slot in the portfolio review meeting, where the people who can actually change the intake and approval rules are sitting.
Where a PMO wants this to hold, it needs to be written into the operating model rather than left to good intentions, which is what a project governance framework is for: the review becomes a gate with an owner and a trigger, not a recommended practice.
Common questions about the post implementation review
What is the purpose of a post implementation review?
The purpose is to establish whether a completed project delivered the objectives and benefits it was approved on, and to convert that finding into changes that improve future projects. It has two audiences: the sponsor, who needs a verdict on this investment, and the organization, which needs to know what to do differently next time.
When should a post implementation review be done?
Hold it once the deliverable has been in live use long enough to produce evidence, typically one to three months after go-live for a system rollout and three to six months for a process or operating model change. Earlier than that and there is nothing to measure. Much later and the team who could explain the decisions has dispersed.
What is the difference between a post implementation review and lessons learned?
A post implementation review is a formal evaluation of whether the project met its objectives and delivered its benefits, owned by the sponsor. Lessons learned is the narrower practice of capturing transferable insights, owned by the project manager and collected throughout delivery. Lessons learned is one section of a post implementation review, not a substitute for it.
Who should attend a post implementation review?
The sponsor, a PMO facilitator, the project manager, the business owner who now runs the result, a user representative, and whoever inherits support. Add a compliance or control owner where relevant. Keep the group under about eight people so it stays a discussion rather than a presentation.
What questions should be asked in a post implementation review?
Ask four groups of questions: what was actually delivered against the approved scope, how delivery performed against budget and schedule, which business case benefits have appeared and which will not, and what the organization should change before approving a similar project. The fourth group is the one that creates value beyond the single project.
What should a post implementation review report include?
A summary with a plain verdict, delivery performance against baseline, a benefits table with owners and next measurement dates, what worked, what did not with root causes, recommendations with named owners and due dates, and outstanding items. Two to four pages is enough for the people who will actually read it.
How long should a post implementation review take?
The session itself should run about ninety minutes if evidence is circulated in advance. Preparation, gathering actuals and survey responses, usually takes a few days of part-time effort. If the review needs a full day, the scope is too broad or the data was not collected beforehand.
Is a post implementation review the same as project closure?
No. Project closure happens at handover and confirms the administrative work is finished: acceptance signed, resources released, contracts and accounts closed. The post implementation review happens later and asks whether the delivered result was worth the investment. A project can be cleanly closed and still be a failure.
Who is responsible for conducting a post implementation review?
The project sponsor is accountable for it and the PMO normally facilitates it. The project manager supplies evidence and takes part but should not run it, because a team assessing its own work reliably produces gentler findings than an independent facilitator would.
The review is worth exactly as much as the decisions it changes. If the recommendations land in a document library and the next project is approved on the same thin business case with the same optimistic benefit profile, the hour was wasted no matter how well the meeting ran. The organizations that get value from this treat it as an input to the approval process rather than as the end of the delivery process, which usually means tightening what a business case has to contain before it is approved and reporting the pattern of findings, not the individual reports, into the forum that decides which projects get funded. For the wider picture of how a PMO closes that loop, see the project portfolio management process.
Last updated August 2026.