Post-Implementation Review: What Actually Went Wrong and Why

Why Most PIRs Generate No Learning

There are four structural reasons why most post-implementation reviews fail to generate organisational learning:

Timing. PIRs conducted immediately after go-live capture delivery team fatigue, not considered reflection. The team is exhausted, some members have already left or moved to new assignments, and the organisation's attention has shifted to hypercare. The richest PIR insights come from a review conducted 3-6 months post-go-live, when the dust has settled, adoption data is available, and the genuine operational impact of implementation decisions can be assessed.

Scope. Most PIRs review the delivery process (did we deliver what we said we would?) rather than the business outcomes (did the programme achieve what it was supposed to achieve?). A PIR that says "we delivered on time and on budget" while the adoption rate is 40% and the business benefits have not materialised has measured the wrong thing.

Psychological safety. Participants in PIRs are usually asked to reflect on decisions they made. Without strong psychological safety — the genuine belief that honest reflection will not be used against them — they will report what is safe to report, not what is true. The most important failures are usually the most politically sensitive ones, and they will not surface unless the review explicitly protects candour.

Action commitment. PIR findings that are not converted to committed actions with owners and timelines are not lessons learned; they are lessons noted. The difference between an organisation that learns from its PIRs and one that doesn't is whether the findings produce change. If the same findings appear in every PIR, the organisation is noting, not learning.

The Three-Stage PIR Model

Stage 1 — Data collection (individual, anonymous). Before any group discussion, collect individual written responses to three questions: (1) What went well that we should deliberately repeat? (2) What created the most significant problems, and what was the root cause? (3) What decision, made differently, would have most changed the outcome? Collect these anonymously — or at minimum, with a commitment that responses will be aggregated rather than attributed. Anonymous collection surfaces concerns that would not emerge in a group setting where social dynamics influence disclosure.

Stage 2 — Root cause analysis (group, facilitated). Present the aggregated themes from Stage 1 to a group that includes delivery team, business stakeholders, and sponsor representation. For each major theme, conduct a structured root cause analysis — five whys or fishbone diagram. The goal is to get from "the data migration took too long" to "the data migration took too long because the data quality assessment was conducted at architecture phase rather than discovery, so the team did not know about the duplicate record problem until week 8 of the migration." The second version is actionable; the first is not.

Stage 3 — Action planning (committed owners). Convert each finding into an action with a named owner and a completion date. Actions should address system causes, not individual behaviour. "Train the delivery team on data migration assessment" is a systemic improvement. "Tell the next project manager not to underestimate data migration" is not — it relies on individual behaviour change rather than process change. Review the action list 90 days after the PIR to assess completion. If actions are not being completed, the PIR has generated paperwork, not learning.

Five Root Cause Categories

Analysis of Salesforce programme PIRs consistently identifies five root cause categories. Knowing these categories in advance allows you to structure the investigation rather than letting it meander.

Requirements and scope. The most common category. Includes: requirements that were too high-level and produced misunderstood scope, requirements that changed materially without a formal change control process, and scope that was added incrementally ("scope creep") without corresponding schedule or budget adjustment. The systemic fix is a more rigorous discovery process and a formal change control mechanism — not better requirements writing by individual consultants.

Stakeholder engagement. Includes: sponsor disengagement at critical decision points, business SMEs who were not available when needed, and political resistance that was not surfaced or managed. The systemic fix is an explicit stakeholder engagement plan with defined commitments from each stakeholder and a governance mechanism for escalating non-compliance.

Technical estimation. Includes: integrations that were more complex than estimated, data migrations that took longer than projected, and custom development that exceeded effort estimates. The systemic fix is better estimation methodology — including discovery spikes before committing to estimates for complex technical work — and contingency budgeting for known unknowns.

Adoption and change management. Includes: insufficient training, process change that was inadequately communicated, and user resistance that was not anticipated. The systemic fix is treating adoption and change management as funded workstreams with their own milestones and resources, not as activities bolted on to the technical delivery.

Governance and decision-making. Includes: decisions that were made by the wrong people, decisions that were escalated too late, and decisions that were made but not documented or communicated. The systemic fix is a decision authority matrix (RACI) defined before the programme begins, with an explicit escalation path for decisions that cannot be made at delivery level.

Creating Psychological Safety for Honest Reporting

Psychological safety in a PIR is not created by saying "this is a safe space." It is created by the specific behaviours of the leaders present — primarily the sponsor and the programme manager.

The sponsor needs to model vulnerability: share a decision they made that contributed to problems, and what they would do differently. This permission from authority is what makes it safe for others to be equally honest. A sponsor who sits in the PIR as an evaluator will produce a PIR full of carefully managed disclosures.

The facilitator needs to enforce a "no name, no blame" norm: observations about what went wrong are directed at processes, decisions, and systems — not at individuals. When participants start attributing problems to individual performance, the facilitator redirects: "What process or structure allowed that individual to be in that position, or make that decision without adequate support?"

Document the PIR outcomes and findings, and share them with the team. The act of sharing findings — rather than locking the PIR report in a governance folder — demonstrates that the review was genuine. If the findings are shared, participants will know their candour was treated seriously, and future PIR participants will trust the process.

Converting Findings to Lasting Improvement

The test of a PIR is not whether it produces good findings. It is whether those findings change what the organisation does next time. Three mechanisms convert findings to lasting improvement.

Process change. Findings that identify missing or inadequate processes should produce updated process documentation. If the finding is "we didn't have a data quality assessment process in discovery," the output is a data quality assessment process document that is now part of the standard discovery methodology. Not a note to "remember to do data quality assessment" — a documented, repeatable process.

Template and artefact updates. Findings that identify gaps in standard artefacts (project charter, requirements template, risk register) should produce updated templates. These templates are the most durable form of organisational learning — they encode lessons into the tools that the next team will use from day one.

Programme initiation checklist. Maintain a programme initiation checklist that is updated after every PIR. Before the next programme starts, the checklist is reviewed: "In our last PIR, we found that adoption planning was insufficient. The initiation checklist now requires an adoption and change management plan as a gate to phase 2 approval." This mechanism ensures that lessons from one programme actively influence the next one.