Visit Website →
← Back to blog

Teams: Run Post Implementation Reviews at 60–90 Days

September 5, 2026
Teams: Run Post Implementation Reviews at 60–90 Days

A post implementation review is a structured, evidence-based evaluation held after go-live to confirm whether a project's expected outcomes were actually realised. It compares what was promised against what happened, using data and stakeholder feedback rather than memory or opinion. The single most important action is naming an owner for every finding, because a review with no owners is just a document nobody reads twice.

TL;DR:

  • Conduct PIRs 60 to 120 days after go-live, depending on project size and complexity, to allow operations to stabilize and provide meaningful insights.
  • Ensure a diverse review team, including sponsors, operators, and users, with independent facilitation to promote candid feedback and avoid bias.
  • Collect comprehensive evidence, such as performance data, benefits metrics, operational logs, user feedback, and residual risks, to support accurate evaluation.
  • Create a focused report with clear findings and a simple action register, assigning specific owners, realistic due dates, and follow-up governance checkpoints.
  • Emphasize honest, blame-free discussions by setting ground rules, safeguarding against political sensitivity, and embedding PIR outcomes into continuous governance cycles.

Table of Contents

What does a post implementation review actually cover?

A post implementation review, often shortened to PIR, checks four things: outcomes against original objectives, benefits realisation against the business case, whether the process itself worked, and what risk remains once the project team disbands. It is not a status update dressed up in past tense. It asks whether the thing you built is doing what it was meant to do, six weeks or six months after everyone stopped watching it closely.

That distinguishes a PIR from a post-mortem, which usually happens straight after a failure and focuses on what went wrong operationally. A PIR happens regardless of whether the project succeeded, and it looks forward as much as back. It also differs from routine project closure, which tends to tick off contractual and administrative loose ends: final invoices, sign-offs, resource release. A PIR evaluates whether the implementation delivered intended benefits and compares actuals against the original business case, which closure paperwork rarely does with any rigour.

For smaller projects, a PIR can sit inside an existing governance checkpoint rather than run as its own event. Larger or higher-risk programmes deserve a standalone review with its own plan, timeline, and facilitator, because folding it into a routine steering meeting almost guarantees it gets fifteen rushed minutes at the end of an agenda.

Scope typically includes:

  • Delivery performance: scope, schedule, and cost against the approved baseline.
  • Benefits realisation: has the project produced the value the business case promised?
  • Process effectiveness: did governance, communication, and change control actually work?
  • Residual risk: what unresolved issues or dependencies remain live after go-live?

Why running a PIR is worth the time it costs

Skipping a PIR is cheap in the short term and expensive over three or four projects. The value shows up in three places: sharper future business cases, fewer repeated mistakes, and a governance function that actually learns.

A PIR calibrates whether benefits projections were realistic in the first place. If a business case promised a 20% reduction in processing time and the real figure came in at 8%, that gap tells you something about how future estimates should be built, not just how this project performed. Organisations that skip this step tend to keep making the same optimistic assumptions project after project.

The review also captures what worked, which gets undervalued next to lessons about failure. A team that hit its milestones because of a particular stakeholder engagement approach should have that documented and repeated, not lost when the project closes.

Concrete benefits include:

  • More accurate benefit forecasting on the next comparable project.
  • Fewer repeat failures, because root causes get named rather than assumed.
  • Stronger governance maturity, since PMOs start treating reviews as a source of evidence rather than a formality.
  • Better prioritisation, as leadership sees which project types actually deliver against their promises.

When should you run a post implementation review?

Timing decides whether a PIR captures useful evidence or captures fog. The typical window sits at 60 to 90 days after go-live, long enough for operations to settle into a new normal but short enough that people still remember the detail behind decisions.

Major transformations, think enterprise-wide system rollouts or multi-site healthcare implementations, usually need longer: 90 to 120 days before a first full review, because early data is noisy and teething problems can mask genuine performance. For these, a staged approach works better than one big review. Run an initial stabilisation check around the 90-day mark, then add a benefits checkpoint after a suitable period that revisits the original business case assumptions once the full benefit cycle has had time to show up in the numbers.

Watch for practical readiness signals rather than sticking rigidly to a calendar date: has usage stabilised, have support tickets settled into a normal pattern, has at least one full reporting cycle passed? Running the review once operations have settled but while memories are still fresh reduces recall bias considerably, so don't wait so long that the team has moved on to three other projects and forgotten why a decision got made.

Who should take part, and who should lead it?

The review needs a mix of people who can see the project from different angles: the sponsor, an operations representative living with the outcome daily, delivery leads who know what actually happened during build, and genuine user representatives rather than their managers speaking for them.

Facilitation matters more than most teams expect. PMI recommends treating the PIR as a distinct activity and flags end-of-project fatigue as a real risk to honesty, because a delivery team that has just spent eighteen months on something is rarely its own most objective judge. An independent facilitator, someone with no stake in defending the project's decisions, tends to surface more candid input. Structured techniques like timeline mapping and affinity grouping also help draw out detail that a straight discussion misses.

The PMO or governance sponsor owns the process itself: setting the timeline, making sure the right data gets collected in advance, and holding the group accountable for turning conclusions into an actual action register rather than a debrief that is forgotten quickly.

What evidence should you actually collect?

A PIR is only as good as the evidence behind it. Opinions in a room produce a weaker review than opinions backed by numbers, so the collection phase deserves more time than most teams give it.

  1. Compare objectives against actuals. Pull the original scope, schedule, and cost baselines and lay them against what was delivered. Where did the project land within tolerance, and where did it drift?
  2. Gather benefits metrics. Usage data, KPI trends against targets, and satisfaction scores from the people actually using the output. If benefits tracking was never properly instrumented during delivery, that gap is itself a finding worth recording, with a remediation action for the next project.
  3. Pull the operational trail. Change logs, defect backlogs, and training completion rates tell you whether the rollout was smooth or held together with workarounds nobody escalated.
  4. Collect direct user feedback. Short interviews and targeted surveys catch issues that dashboards miss, particularly around usability and workload impact.
  5. Run a gap analysis. Line up what was promised against what landed, and be specific about the size of each gap rather than describing it as "roughly on target."
  6. Record residual risk. Note every unresolved issue, dependency, or workaround still live at the point of review, with an owner attached to each one.

Using a combination of document review, interviews, surveys, and hands-on system testing produces more reliable findings than relying on a single source. A defect backlog alone will tell you where the software broke; it won't tell you whether the people using it trust it. You need both.

For construction and facilities programmes specifically, this evidence stage often surfaces gaps in how operational efficiency was tracked day to day, which is worth flagging early rather than discovering it during the analysis session.

How do you run a PIR from start to finish?

A PIR that produces real change follows a sequence, not a single meeting. Rushing straight to a discussion without preparation is the most common way these reviews turn into a talking shop that changes nothing.

  1. Define scope and success criteria first. Decide exactly what the review will judge: which objectives, which benefits, which timeframe. A PIR with no boundary tries to cover everything and ends up covering nothing well.
  2. Plan data collection and stakeholder engagement. Line up surveys, short interviews, and any hands-on system tests two to three weeks before the review session, not the day before. Chasing data during the meeting itself wastes the room's time and produces shallow analysis.
  3. Analyse the evidence before you convene anyone. Run a variance analysis: where did actuals diverge from plan, by how much, and why? Push past the first answer to the root cause. "The vendor was late" is rarely the full story; the more useful question is why the delay wasn't caught earlier.
  4. Draft the PIR report. Structure it with an executive summary, a performance overview, the lessons learned, and clear recommendations. Recommended report components include an executive summary, performance overview, stakeholder perspectives, lessons learned, and recommendations tied to specific owners, which keeps the document usable rather than encyclopaedic.
  5. Build the action register and embed it in governance. Every recommendation needs a named owner, a realistic due date, and a priority. Then, critically, put a follow-up checkpoint on the governance calendar. Without that step, even a well-written PIR gets filed and forgotten.

Pro Tip: Send the draft findings to participants 48 hours before the review session, not on the day. People give more honest, considered feedback in writing when they've had time to think, and the live session becomes a discussion of conclusions rather than a first read of raw data.

Programmes with formal assurance structures often fold PIR outputs directly into existing project assurance reporting, which avoids creating a parallel governance track that nobody quite knows how to prioritise against the main one.

How do you run a PIR from start to finish? — overview diagram

Turning findings into an action register that gets used

A PIR report that nobody acts on has failed, regardless of how well-written it is. The report itself needs to be short enough that a sponsor will actually read it: an executive summary with the top three findings, a performance overview against the original baseline, stakeholder perspectives, and a set of recommendations that are specific rather than aspirational.

Keeping the report concise, with a one-page action register attached, tends to hold governance attention far better than a long narrative document that buries the three findings that actually matter under forty pages of context.

The action register itself should stay simple:

  • Owner: a named individual, never a team or department.
  • Action: specific enough that success is obvious when it's done.
  • Due date: realistic, tied to the next relevant governance cycle.
  • Priority: ranked, so a busy sponsor knows what to look at first.

Feed the benefits findings back into the organisation's benefits tracking process, not just the project file. If this PIR revealed that a certain type of estimate consistently runs optimistic, that insight belongs in the next business case template, not buried in a report nobody outside the original team will ever open. Programmes rebuilding delivery processes off the back of PIR findings often draw on structured process improvement approaches to make sure the change sticks rather than fading after a few weeks.

How do you keep a PIR honest instead of performative?

The biggest threat to a useful PIR isn't bad data. It's a room where nobody wants to say what actually happened, because admitting a mistake feels riskier than staying quiet.

Set ground rules before the session starts: the review is about improving the next project, not assigning blame for this one. That single framing shift changes what people are willing to say out loud.

  • Open the session by stating explicitly that findings feed process improvement, not performance reviews.
  • Balance candid internal discussion with independent facilitation on sensitive or high-profile programmes, where internal politics can quietly shape what gets said.
  • Give every finding a named owner and a timeline that's actually achievable, not a wish list.
  • Put a governance checkpoint on the calendar to review progress against the action register. Skipping this is how good PIRs become filing exercises.

Pro Tip: If a finding is politically sensitive, don't soften the language in the report to make it more comfortable. Soften the delivery of it in the room instead, and keep the written record accurate. A watered-down report is useless to the next project team trying to avoid the same mistake.

Organisations without an internal facilitator with the standing to run a sensitive review sometimes bring in outside support; guidance on different types of consulting engagement is a useful starting point for scoping what that looks like.

Keystone's practical perspective on PIRs in complex programmes

A consultancy with extensive experience has spent many years working inside governance and reporting problems across healthcare, construction, and facilities management, sectors where a poorly run review has real operational consequences, not just a documentation gap. The recurring trade-off in these programmes is time versus rigour: teams under pressure want to close the project and move on, but skipping evidence collection guarantees the next business case repeats the same optimistic assumptions.

The Videra platform is built around that tension. It captures evidence as work happens rather than reconstructing it after the fact, automates the reporting layer of a PIR, and keeps action registers visible inside existing governance rather than as a separate spreadsheet someone forgets to update.

Three lessons from running PIRs in the field

Perfect data almost never arrives on schedule. If 80% of your evidence is solid and the remaining 20% would take another month to chase, proceed with a caveat noted, rather than delaying the whole review.

Sponsor time is the scarcest resource in any follow-up governance cycle, so book it before the PIR session, not after. And some of the highest-value actions are small: a missing field in a change log, a training gap for one team, closed within a week rather than debated for a quarter.

— Peter

How Keystone helps you run PIRs that actually change things

Most teams don't fail at PIRs because they lack templates. They fail because evidence lives in six different systems, findings never get a named owner, and the action register dies the week after the review. Keystone's consultancy work pairs with the Videra PM platform to fix exactly that gap, mapping workflows so evidence is captured as the project runs, then using AI-powered reporting to draft the performance overview and lessons learned sections automatically rather than from memory weeks later.

Keystoneconsulting

For healthcare programmes specifically, Videra Healthcare is built around NHS-style governance cycles and lifecycle tracking, so PIR findings sit inside the same audit trail regulators expect to see. If your last review produced a good report and a dead action register, get in touch through Keystone Strategic Consultants and ask about a working demo of how Videra tracks findings through to closure.

Sources

For deeper technique guidance, PMI's analysis of post-project review practice covers facilitation and the fatigue risk in more depth than most practitioner blogs attempt. On timing specifically, the staged review approach for major transformations is worth reading in full if you're planning a 12-month benefits checkpoint. For report structure, the breakdown of PIR components is a useful template starting point before you adapt it to your own governance format.