Post-Implementation Review: Steps, Template, and How to Check the Benefits Actually Arrived

Quick answer: A post-implementation review checks whether a finished project actually delivered what it promised. It runs 6 to 18 months after go-live, once benefits have had time to appear. It covers three things: how well the project was managed, whether the business case came true, and what to change next time.

Most post-implementation reviews are a meeting where people say nice things, write a lessons document, and file it.

The review that matters asks a harder question: did the business case come true?

In the worked example below, a project came in $17,535 under budget. Its payback period still slipped from 17 months to 23.

The cost control was very good. The benefits arrived at 66%. Only one of those two numbers was ever reported to anybody.

This guide gives you the steps and the benefits arithmetic. It also gives you a way to stop your lessons dying in a document nobody opens.

What Is a Post-Implementation Review?

A PIR, short for post-implementation review, is a structured look back at a finished project. It runs after the project has closed. By then the thing it built has been in real use for a while.

It answers three questions, and most reviews only answer the first. The second is benefits realisation, and it matters most:

Question	What it examines	Often called
How well did we run the project?	Time, cost, scope, quality against the plan	Project evaluation
Did we get the benefits we promised?	Actual results against the business case	Benefits review
What should we change next time?	Process, templates, estimates, suppliers	Lessons learned

In UK government practice, PIR covers all three together: the project evaluation, the benefits review and the lessons learned report. That’s a useful way to think about it. The three have different audiences and different timing.

Why the benefits question gets skipped

It’s the awkward one.

The project manager has usually moved on. The sponsor approved the business case and may not want it reopened. And the honest answer is often “we got some of it.”

So the review quietly becomes a lessons-learned meeting about process. That’s useful, but much less valuable. Nobody approved the project because of the process. They approved it because of the numbers in the business case. The PIR is the only point where anyone checks those numbers against reality.

What a PIR is not

Not this	Why
A performance appraisal	It reviews the project, not the people
A blame exercise	A review people fear is a review that gets nothing true in it
Part of the project	The project is closed. The review is a separate, usually funded, piece of work
A one-off	On large projects, benefits get reviewed more than once as they emerge

When Should You Run a Post-Implementation Review?

Six to eighteen months after the project closes, for most projects. That’s the range UK government guidance uses, and it reflects a real constraint: benefits take time to show up.

Why timing is genuinely hard

Too early	Too late
Benefits haven’t appeared yet	The team has dispersed
People are still learning the new system	Nobody remembers the detail
Performance often dips right after go-live	Other changes have muddied the data
You measure the disruption, not the result	The findings are too late to help the next project

That third point catches people out. Almost every rollout makes things worse for a while. People are learning. Workarounds are being unpicked. Old habits are breaking.

A review at six weeks measures the dip and concludes the project failed.

A practical timing rule

Wait until the new way of working has been through at least one full business cycle. What counts as a cycle depends on the business:

Business cycle	Wait at least
Monthly process (invoicing, payroll)	3 months
Quarterly reporting	6 months
Annual cycle (budget, audit, academic year)	12–15 months
Seasonal business	Through one full season

Capture lessons early, review benefits late

The way to resolve the tension is to split the two:

Lessons: capture them as you go. Keep a running log during the project, while details are fresh and the team still exists. Don’t wait for the review to start remembering.

Benefits: measure them late. They need time, and they need the dip to have passed.

That split is the single most useful scheduling decision in this whole subject. A lessons log kept during delivery plus a benefits review a year later beats one big meeting at either time.

What’s the Difference Between a PIR, Lessons Learned, a Retrospective, and Project Closure?

Four things that get confused, and they happen at different times for different reasons.

	Project closure	Lessons learned	Retrospective	Post-implementation review
When	At the end of the project	During and at the end	Every sprint	6–18 months after closure
Looks at	Admin completeness	Process and practice	How the team worked	Whether benefits arrived
Who runs it	Project manager	Project manager	Scrum master	The sponsor, or an independent reviewer
Main output	Closure report	Lessons log	Actions for next sprint	Benefits report and actions
Audience	Project board	Future projects, PMO	The team itself	The business and how it invests next
Is the project still running?	Just ending	Yes	Yes	No — long closed

How they fit together in sequence

  Project running ──► retrospectives every sprint
                 ──► lessons logged continuously
                      │
  Project ends   ──► PROJECT CLOSURE
                      handover, final accounts, sign-off
                      │
  6–18 months    ──► POST-IMPLEMENTATION REVIEW
  later               did the business case come true?

Closure is paperwork. Contracts closed, documents handed over, accounts settled, team released. It confirms the project is finished. It doesn’t confirm that it worked. Our project closure guide covers that step.

Retrospectives are in-flight and team-facing. Every sprint, fast, aimed at next sprint. See agile task management and planning.

Lessons learned is about practice. What should we do differently as an organisation.

The PIR is about value. Was this a good investment? It’s the only one of the four that could conclude “we shouldn’t have done this.”

The confusion that costs the most

Treating the closure report as the PIR. Closure happens when the project ends, which is exactly when benefits haven’t arrived yet.

So a closure report can honestly say “delivered on time and under budget” about a project that goes on to deliver two thirds of its promised value.

Both statements are true. Only one of them is the reason the money was spent.

What Are the Essential Steps for a Thorough Post-Implementation Review?

Ten steps, in this order. Steps 3 and 4 are where the value is, and they’re the two most often skipped.

#	Step	What you do	Typical effort
1	Commission it	Sponsor appoints a reviewer and sets the scope	1 hour
2	Gather the baseline	Business case, charter, final budget, closure report	2–4 hours
3	Measure the benefits	Actual results against each promised benefit	1–3 days
4	Explain the variances	Why each benefit over- or under-delivered	1 day
5	Review delivery performance	Time, cost, scope, quality against plan	half a day
6	Gather stakeholder feedback	Interviews and a short survey	2–3 days
7	Check what happened to the risks	Which happened, which were missed entirely	2 hours
8	Hold the review session	Walk the findings through with the group	2 hours
9	Write the report	Findings, variances, actions	1–2 days
10	Convert lessons into changes	Each lesson becomes a change to a named artefact, with an owner	half a day

Where to spend the effort

Step 2 decides whether the review is possible at all. You need the original business case with its numbers.

Maybe it doesn’t exist. Maybe it stated benefits as adjectives rather than figures. Then there’s nothing to measure against, and that finding belongs in the report. It’s the most important lesson available.

Steps 3 and 4 are the review. Everything else is supporting material. If you only have two days, spend both of them here.

Step 6 needs both methods. A survey gives you breadth and a number. Interviews give you the reason behind it. Six to ten interviews across different roles will surface things no survey question would have thought to ask.

Step 10 is what separates a review from a document. Covered in its own section below, because it’s where most reviews fail.

Three things to collect in step 2

Document	What you need from it
Business case	The promised benefits, with their numbers and dates
Project charter	Objectives, scope, success criteria
Final budget and closure report	Actual cost, actual dates, scope changes

Your project performance evaluation plan is where the measures should already be defined. Write that properly at the start and step 3 becomes a data-gathering job. Skip it and step 3 becomes an argument about what to measure.

How Do You Check Whether the Benefits Actually Arrived?

This is the part the templates skip. Here’s how it works, with real numbers.

The method

Step	What you do
1	List each benefit the business case promised, with its number
2	Find the actual figure for the same measure, now
3	Calculate the variance for each one
4	Convert to money where you can
5	Work out the payback again, using actual cost and actual benefits
6	Explain each variance

Step 5 is the one that produces the headline. It’s also the one nobody does.

A worked benefits review

This reviews a CRM implementation budgeted at $188,715 and delivered for $171,180. Review run at 12 months post go-live.

Benefit by benefit:

Benefit promised	Target	Actual at 12 months	Achieved?
Quote turnaround time	5 days → 1 day	1.5 days	Partly
Sales admin time saved	6 hrs/week per rep	4 hrs/week per rep	Partly
Lead conversion rate	18% → 24%	20%	Partly
Retire 2 legacy tools	$14,000/year saved	1 of 2 retired, $9,000 saved	Partly
Duplicate records	12% → under 2%	3%	Nearly

Every line says “partly.” That’s typical, and it’s not a disaster. But it adds up to something that needs stating in money.

The financial benefits, calculated:

	Promised	Actual
Admin hours saved per week	6 × 12 reps = 72 hrs	4 × 12 reps = 48 hrs
Value per week at $35/hour	$2,520	$1,680
Value per year (48 working weeks)	$120,960	$80,640
Licence savings per year	$14,000	$9,000
Total annual benefit	$134,960	$89,640

Shortfall: $45,320 per year. Check it: the admin gap is $120,960 − $80,640 = $40,320, and the licence gap is $5,000. Together, $45,320 ✓

Benefit realisation rate: $89,640 ÷ $134,960 = 66.4%.

Now recalculate the payback

	Calculation	Result
Promised payback	$188,715 budget ÷ $134,960/year	16.8 months
Actual payback	$171,180 actual ÷ $89,640/year	22.9 months

The payback period slipped by just over six months.

The finding that matters

Look at the two facts side by side:

Fact	Looks like
Delivered for $171,180 against a $188,715 budget — 9.3% under	A well-run project
Benefits arriving at 66.4%, payback 6 months later than promised	A disappointing investment

Both are true. The project was managed well and the investment fell short.

That gap is the best argument for running a PIR at all. Project managers are measured on cost and schedule, and this one would have scored well on both.

But the value came from the benefits, and nobody was measuring those. By the time anyone could, the project had been closed for a year and everybody had moved on.

Coming in under budget does not mean the investment worked. It’s worth saying plainly, because most project reporting implies the opposite.

What Happens When the Benefits Didn’t Arrive?

A 66% realisation rate is a finding, not a verdict. The useful work is explaining why, because the reason determines what you do about it.

Reason the benefit fell short	What it tells you	What to do
The estimate was optimistic	Your business cases are over-promising	Apply a discount to future estimates of the same kind
The thing wasn’t adopted	The build worked, the change didn’t	Invest in adoption, not more features
It’s still arriving	Too early to judge	Set a date to re-measure
The baseline was wrong	You never knew the “before” figure	Fix how baselines get captured
Something external changed	Not the project’s fault	Document it, adjust the measure
The benefit was never measurable	The business case was vague	Fix the business case template

Diagnosing the example

Two of the five benefits in the worked review have a specific, actionable cause:

Admin time: 4 hours saved instead of 6. Interviews found reps still re-keying data into a reporting spreadsheet, because that one legacy tool was never retired. Notice this is the same root cause as the licence shortfall. One unretired tool caused both the $5,000 licence gap and a chunk of the $40,320 admin gap. One unfinished task, two thirds of the total shortfall.

That’s the kind of finding only a benefits review produces. In a lessons-learned meeting it would have shown up as “we didn’t quite finish retiring that tool,” filed as a minor note.

Lead conversion: 20% instead of 24%. No clear cause found. This is an honest “we don’t know,” and the action is to re-measure at 24 months rather than invent an explanation.

The most valuable action a PIR can make

Finish retiring the old tool. It’s a small piece of work, it’s already paid for, and it unlocks a measurable chunk of the shortfall.

Reviews often recommend process improvements for future projects. Spotting unfinished work on this one is worth far more. A benefit that’s two thirds arrived is usually cheaper to finish than a new project is to start.

Write down the blunt version

If the business case wouldn’t have been approved at the actual numbers, say so. Plainly, once, without drama:

“At $89,640 annual benefit and 22.9 months payback, this project would still have met the company’s 24-month threshold, but with no margin. At a 20-month threshold it would not have been approved.”

That sentence is worth more to the next investment decision than any process lesson in the report. It’s also the sentence most reviews leave out.

Who Should Run the Post-Implementation Review?

Not the project manager. This is the most important choice in the whole exercise.

Role	In the review
Sponsor	Commissions it, chairs it, owns the actions
Outside reviewer	Does the work — from the PMO, another project, or external
Project manager	Contributes, doesn’t run it
Business owner of the new capability	Supplies the benefits data
Users	Interviewed and surveyed
Finance	Confirms actual costs and validates benefit calculations
PMO	Supplies the template, receives the lessons

Why not the project manager

Not because they’d lie. There are three problems:

1. They’re being assessed. Asking someone to grade their own project is asking a lot.
2. They’ve moved on. By month twelve they’re running something else, and this is extra unpaid work.
3. They know too much. They’ll explain away gaps whose history they know, without meaning to. An outsider asks the naive questions, and the naive questions are often the good ones.

Why the sponsor has to chair it

The sponsor approved the business case. So they’re the only person who can say “we got two thirds of what I signed up for.”

They’re also the only one who can act on the actions. That includes the awkward one about how future business cases get written.

A PIR chaired by the PMO with no sponsor in the room produces a document. A PIR chaired by the sponsor produces decisions. Same findings, completely different outcome.

Getting finance involved

Have finance confirm the actual cost and check the benefit figures. Two reasons. Their numbers are the ones the business believes. And a figure they’ve validated can’t be argued away later.

What Questions Should You Ask in the Review?

Organised by what you’re trying to find out.

About the benefits

• Which benefits were promised, with what numbers, by what date?
• What’s the actual figure for each one today?
• Where’s the gap, and why?
• Is any benefit still arriving? When should we re-measure?
• Would this have been approved at the actual numbers?

About delivery

• Final cost against budget, and where the variance came from
• Final dates against plan
• What scope changed, and who approved it
• How much contingency was used

About adoption

• What proportion of intended users are actually using it?
• What are people still doing the old way, and why?
• What workarounds have appeared?
• What would make them use it properly?

The workarounds question is the most productive one in the list. Every workaround marks a gap between what was built and what people needed. And it’s described precisely, by the person who found it.

About the risks

• Which identified risks happened?
• What happened that nobody had on the list?
• Was the contingency about right, too much, or too little?

About process

• What would you do differently?
• What should we keep doing?
• What took far longer than expected?
• What did we learn about this supplier?

The two questions worth asking everybody

“If we ran this project again, what’s the one thing you’d change?” Simple, and it surfaces the thing each person has been thinking about for a year.

“What do you wish someone had told you at the start?” This one beats asking what went wrong. It doesn’t require anybody to criticise anybody.

What Goes in the Post-Implementation Review Template?

POST-IMPLEMENTATION REVIEW

Project:
Closed on:              Review date:        Months since close:
Commissioned by:        Reviewer:
Contributors:

1. SUMMARY
   Three to five sentences. Include the benefit realisation rate
   and the actual payback period. Say the uncomfortable thing here.

2. WHAT THE BUSINESS CASE PROMISED
   | Benefit | Measure | Baseline | Target | Target date |

3. WHAT ACTUALLY HAPPENED
   | Benefit | Target | Actual | Variance | Still arriving? |

4. BENEFITS IN MONEY
   | | Promised | Actual | Variance |
   | Annual benefit  |  |  |  |
   | Project cost    |  |  |  |
   | Payback period  |  |  |  |
   Benefit realisation rate: actual ÷ promised = ____%

5. WHY THE VARIANCES HAPPENED
   | Variance | Cause | Evidence | Avoidable? |
   Causes: optimistic estimate / not adopted / still arriving /
   wrong baseline / external change / never measurable

6. DELIVERY PERFORMANCE
   | | Plan | Actual | Variance |
   | Cost / End date / Scope / Contingency used |

7. ADOPTION
   Intended users:        Active users:        %:
   Known workarounds:
   What people still do the old way:

8. RISKS
   Risks that happened:
   Events nobody identified:
   Was contingency about right?

9. STAKEHOLDER FEEDBACK
   Survey responses: __ of __      Interviews: __
   Themes:

10. RECOMMENDATIONS — THIS PROJECT
    Unfinished work that still pays.
    | Action | Owner | Due | Benefit unlocked |

11. LESSONS — CONVERTED INTO CHANGES
    | Lesson | Artefact to change | Change | Owner | Due |
    No lesson is accepted without an artefact, an owner and a date.

12. SIGN-OFF
    Sponsor: __________  Date: ______
    Actions logged in: ________________

CHECKS
[ ] Every promised benefit has an actual figure or a reason it has none
[ ] Payback worked out again with actual cost and actual benefits
[ ] Realisation rate stated as a percentage
[ ] Every variance has a named cause
[ ] Finance has confirmed the cost and benefit figures
[ ] Unfinished work that still pays is listed separately
[ ] Every lesson names an artefact, an owner and a date
[ ] The sponsor has signed it

Section 11 is the one that makes this template different from the others. The next section explains why.

How Do You Stop Lessons Going Into a Graveyard?

Every organisation has a folder of lessons-learned documents. Almost nobody reads them. This is the most reliably wasted effort in project management.

The reason is simple. A lesson written as a sentence changes nothing. It has to become a change to something people actually use.

Convert every lesson into a change

Weak lesson	Converted into a change
“We should have involved the finance team earlier.”	Add finance to the mandatory consultee list in the project charter template. Owner: PMO lead. Due: 30 Nov.
“Data quality was worse than expected.”	Add a mandatory data-quality assessment to the business case template for any migration project. Owner: Head of PMO. Due: 15 Dec.
“We never finished retiring the old tool.”	Add “legacy system retired and licence cancelled” as a mandatory closure checklist item. Owner: PMO. Due: 30 Nov.
“Training was too early.”	Change the implementation plan template so user training sits in the two weeks before go-live, not during build. Owner: Change lead. Due: 31 Jan.
“We underestimated migration by 40%.”	Apply a 1.4× multiplier to migration estimates in the estimates guide. Owner: PMO. Due: 15 Dec.
“Communication could have been better.”	Not accepted. Too vague to convert. Ask what specifically was missing, and convert that.

The rule

No lesson is accepted into the report without a named artefact, a named owner, and a date.

That single rule does more than any amount of good intention. It forces each lesson to be specific enough to act on. And it gives the PMO a short list of template changes instead of a long document of observations.

Notice the last row. “Communication could have been better” gets rejected. Not because it’s wrong, but because it can’t be converted.

Sending it back produces something usable: which communication, to whom, that didn’t happen.

What counts as an artefact

Artefact	Example change
A template	Add a mandatory section or field
A checklist	Add an item that must be ticked
An estimates guide	Change a rate or add a multiplier
A policy or gate	Add a check before approval
A standard agenda	Add a recurring item
A supplier record	Note what to watch next time

If a lesson can’t be written as a change to one of these, it’s just a note. Notes like that are fine. They just don’t belong in the actions.

Close the loop

Three months after the review, check whether the artefact changes were made. Six changes with owners and dates is a thing you can audit in ten minutes.

That ten-minute check is what turns a lessons process from theatre into a system. Without it, you’ve simply written a better-formatted document for the same folder.

How Do You Keep the Review Blameless and Still Honest?

These pull against each other. A review people fear produces nothing true. A purely comfortable one produces nothing useful either.

Do	Don’t
Review decisions, not people	Name individuals in findings
Ask what was known at the time	Judge choices using what you know now
Separate “went wrong” from “someone got it wrong”	Let the two blur together
Let the sponsor own uncomfortable findings	Leave the reviewer defending them alone
Interview privately, report in themes	Attribute quotes
State the numbers plainly	Soften figures to protect feelings

The distinction that makes it work

Be gentle about people and precise about numbers.

“The migration estimate was 40% low” is a fact about an estimate. “Sana got the migration wrong” is a fact about a person.

The first improves your estimates. The second makes everybody careful in next year’s review.

Those two sentences describe the same event, and only one of them is useful.

Three practical safeguards

Interview privately first. People tell an interviewer things they won’t say in a room with their sponsor present. Report themes, not sources.

Give people the draft before it’s final. Not to let them veto findings. To let them correct facts. It also removes the surprise, and surprise is what makes people defensive.

Have the sponsor present the awkward parts. Say the finding is “our business cases over-promise.” That has to come from the person who approves business cases. From anyone else it reads as an accusation. From them it reads as a decision.

What Are the Most Common Post-Implementation Review Mistakes?

1. Running it too early. You measure the post-go-live dip and conclude the project failed.
2. Never running it at all. By far the most common. The project closed, everyone moved on.
3. Skipping the benefits. It becomes a lessons meeting, which is the less valuable half.
4. The project manager runs it. They’re being assessed, they’ve moved on, and they know too much.
5. No sponsor in the room. Produces a document instead of decisions.
6. No baseline to measure against. If the business case had no numbers, there’s nothing to compare. That’s a finding in itself.
7. Not working out the payback again. The headline number, routinely left out.
8. Reporting cost performance as if it were value. Under budget and under-delivering are compatible.
9. Lessons with no owner. Straight to the graveyard.
10. Vague lessons accepted. “Communication could be better” can’t be acted on.
11. Missing the unfinished work that still pays. The cheapest action available, routinely overlooked.
12. No follow-up. Nobody checks three months later whether anything changed.

Best Software Tools for Conducting a Post-Implementation Review

Five jobs, five kinds of tool. Most reviews need three of them.

Job	What to look for	Type of tool
Finding the baseline	Searchable archive of charters and business cases	Document management or your PMO repository
Collecting feedback at scale	Anonymous responses, simple analysis	Survey tools
Running the session	Everyone contributing at once, remote-friendly	Whiteboard or collaboration tools
Getting actual numbers	Reports on the same measures as the business case	BI or reporting tools, plus the finance system
Tracking the resulting actions	Owners, dates, visible status	Project or task management platforms

Six features that matter more than the brand

• Anonymous survey responses. The single most valuable feature in the list. People are markedly more honest when their name isn’t attached.
• Searchable business cases. If you can’t find the original numbers, the review can’t happen. This is a document-management problem, not a review problem.
• Reports matching your business case measures. If the case promised “quote turnaround under 1 day,” something has to be able to report quote turnaround. Set that up at project start, not at review time.
• Action tracking outside the report. Actions living only in a document are actions that don’t happen.
• Version history on templates. So you can see which lessons actually changed the template, and when.
• A reusable review template. So the next PIR is comparable to this one.

The honest answer about tools

No tool fixes the two real problems, which are that nobody schedules the review and nobody can find the business case.

Habit solves both, not software. Put the PIR date in the project plan at kickoff. File the business case where it will still be findable in two years.

A spreadsheet, a survey tool and a shared document will run a perfectly good review. A brilliant platform with no appointment in the calendar will not.

There’s one thing worth setting up. At project start, define how each promised benefit will be measured, and where that number will come from.

Do that and the review becomes a few hours of data gathering. Skip it and no tool will save you. A project performance evaluation plan is where that belongs.

Our project management tools page covers the wider set, and project control process covers measurement during delivery.

How Does Writegenic AI Fit In?

A post-implementation review produces a lot of writing, and most of it has to be read by people who weren’t involved.

Writegenic AI can help you:

• Draft the review report from your findings and figures
• Write the benefits summary in plain language for people who won’t read the tables
• Convert vague lessons into specific artefact changes with the owner-and-date structure
• Draft the interview guide and survey questions for stakeholder feedback
• Write the blunt paragraph — the one saying what the numbers mean, without drama
• Draft the review invitation explaining what it is and isn’t, so people arrive unworried

It also helps with the documents the review draws on. The project charter. The closure report. And the meeting agenda for the session itself.

Explore AI for project management or sharpen your instructions with the prompt generator.

Draft with the tool, keep the judgement. AI can structure a review, write the report and turn a vague lesson into a specific one. It cannot tell you that one stakeholder will read a finding as an attack. Or that your sponsor needs the payback number privately, before the meeting. Or whether 66% counts as a let-down or a relief in your business.

The findings are arithmetic. What you do with them is politics, and that part is yours.

Try Writegenic AI free

Frequently Asked Questions

Related reading:

• Project Closure: Guide for Project Completion
• Project Performance Evaluation Plan
• Project Charter Templates With Real Examples
• Project Control Process: Steps + Template
• What Is Stakeholder Engagement Plan: Steps + Template
• Agile Task Management and Planning