Review a failure by reconstructing when reality first stopped matching the team's assumptions, what information was available at that point and why the first reasonable opportunity to respond was missed.
Judge decisions using what people could reasonably have known at the time. Then assign a small number of concrete changes to named owners. Avoiding blame does not mean avoiding accountability.
Separate blame from accountability
A blame-focused review starts with the final outcome and looks for a person to associate with it. This may identify an individual mistake, but it often leaves a more useful question unanswered: Why was the problem able to continue?
A review without accountability is not useful either. People should still explain their decisions, acknowledge mistakes and take ownership of corrective actions. If someone knowingly ignored relevant information or bypassed an agreed responsibility, record that plainly.
The distinction is practical. Blame reduces the explanation to a person. Accountability identifies who decided what, what they knew, what responsibility they held and what they must do differently.
Reconstruct the failure in five layers
Start with a timeline rather than opinions about motives. Build it from records such as emails, approvals, project updates, customer messages and system entries where these are available.
Separate the reconstruction into five layers:
Facts: What can be verified? Record events, dates, commitments and results. "The supplier confirmed a two-week delay on 4 April" is a fact. "The supplier was unreliable" is an interpretation.
Original assumptions: What did the team expect to be true? This may include expected demand, staff availability, delivery times, costs or customer decisions.
Decisions: What was decided, by whom and when? Include decisions to continue with the current plan, not only decisions that visibly changed it.
Available information: What did the decision maker know, or have a reasonable opportunity to know, at that moment? Keep later discoveries separate.
Warning signs: What suggested that an important assumption might no longer be valid? A warning sign may be a missed milestone, an unusual result, an unanswered dependency or repeated uncertainty from the person closest to the work.
Keeping these layers separate prevents hindsight from rewriting the situation. Information discovered after the outcome may explain what happened. It does not prove that an earlier decision was obviously wrong.
Mark two different moments on the timeline
Identify two points during the review:
- The first meaningful deviation from an important assumption.
- The first reasonable opportunity to reconsider the plan, escalate the issue or reduce the impact.
These moments are often different.
Consider a hypothetical project that finishes late. The original plan assumed that a key specialist would be available for two days each week. Their workload increased, and their actual availability fell below that level. This was the first meaningful deviation.
The delay did not become unavoidable on that day. The team may still have had time to change the scope, assign another person or move a dependent milestone. The first reasonable opportunity to respond could have been the next weekly project review, when the reduced availability was known but the delivery plan remained unchanged.
The final missed deadline is only the visible result. The more useful review question is why the plan was not reconsidered when the assumption about availability stopped being true.
This distinction also prevents the review from focusing only on the last person who touched the work. A final error may have made the failure visible, while the practical opportunity to prevent or limit it occurred much earlier.
Find out why the warning did not produce action
For each warning sign, determine what happened to it. Four different situations require four different responses:
- It was not visible. The team had no reliable way to detect the change. The response may be a new check, threshold or reporting point.
- It was not passed on. Someone saw the issue, but the information did not reach the person who could act. The response may be a clearer escalation route or handover rule.
- It was misunderstood. The information arrived, but its significance was unclear. The response may be a better definition of what requires attention or a clearer presentation of the risk.
- It was consciously ignored. The warning was understood, but someone chose not to act. The review should examine the reasoning, authority and responsibility behind that decision.
Do not group all four under "poor communication". That phrase hides the mechanism of failure. A missing signal, a broken handover and a deliberate decision are different problems.
Turn findings into a small set of changes
A long action list can make the review feel thorough while weakening ownership. Prioritise the changes that respond directly to the points where the failure could reasonably have been detected, escalated or limited.
Define each action through three elements:
- Change: What will be introduced or done differently?
- Owner: Who is responsible for introducing and maintaining it?
- Trigger: In which situation does the new rule apply?
For the delayed project, "communicate capacity problems earlier" is too vague. A usable action would be:
The project manager must review the delivery plan when a critical team member's expected availability falls below the level used in the current estimate.
This states what must happen, who owns the response and what triggers it. The rule can later be checked against real work.
Also distinguish between the owner of the corrective action and the people expected to follow the new process. If everyone owns an action, nobody has clear responsibility for putting it in place.
Before closing the review, ask:
What will be done differently, who owns the change and when will the new rule apply?
If the team cannot answer all three parts, the review has not yet produced an actionable result.
Frequently asked questions
Should a failure review identify individual mistakes?
Yes. Record individual decisions and mistakes when the evidence supports them. The purpose is not to avoid naming responsibility. It is to assess the decision in context and determine what should change. If someone knowingly ignored relevant information or failed to carry out an agreed responsibility, state that clearly.
How soon should the review take place?
Hold it when enough evidence is available to reconstruct events, but before records and details become difficult to recover. Immediate operational work may need to come first. Preserve relevant messages, approvals and system records so the later review does not depend only on memory.
What if the team disagrees about what was known at the time?
Use records where possible and separate verified information from recollection. If the evidence remains incomplete, state the uncertainty rather than presenting one person's memory as fact. The missing record may itself reveal a weakness in how decisions are documented.
How many corrective actions should the review produce?
There is no fixed number. Use a small, prioritised set that addresses the identified points of failure. Each action should have a named owner and a clear trigger. Do not add general reminders such as "be more careful" unless they are converted into a specific change that can be applied and checked.