When one person is strategist, seller, operator, and reviewer, a project failure can feel like a judgment on the whole person. That makes honest learning harder. A useful postmortem separates identity from the operating system: what happened, what conditions produced it, and what will change next time?
Run the review soon after completion, cancellation, or a meaningful incident. Keep it short enough that you will actually use it.
Start with the intended result
Write down:
- the original outcome;
- the acceptance conditions;
- the planned time and cost;
- the actual result;
- what the customer or user experienced.
Do not begin with a list of mistakes. First establish the difference between intention and evidence.
Build a neutral timeline
Record a small number of turning points: important decisions, new information, delays, reversals, and recovery actions. Use dates and artifacts where possible.
A neutral timeline often reveals that the final problem began earlier: an ambiguous kickoff, an untested assumption, a missing approver, or too many simultaneous commitments.
Ask five learning questions
What worked and should be repeated?
Name the condition, not just the result. “Early prototype review exposed a false assumption” is reusable; “prototype went well” is not.
What surprised us?
Include positive surprises. An unexpectedly easy step may reveal an asset worth standardizing.
Where did reality diverge from the plan?
Look at scope, estimate, dependency, quality, communication, and capacity.
Which warning signal appeared first?
Find the earliest observable sign, not the moment the consequence became painful.
What is the smallest system change?
Choose a concrete change: add an acceptance example, reduce simultaneous projects, move review earlier, restrict access, or create a resume note. “Communicate better” is too vague.
Limit the actions
Select no more than three changes and assign each a trigger. Update the actual onboarding brief, estimate checklist, or operating rhythm. A lesson stored only in a retrospective document is unlikely to affect future behavior.
Include wins and near misses
Document what almost failed even if the result succeeded. Near misses reveal fragile success. Also record which choices protected the outcome; resilience deserves to become repeatable, not merely remembered as luck.
Avoid these traps
Do not use hindsight to pretend an uncertain outcome was obvious. Do not assign every failure to personal discipline. Do not generate twenty action items. Do not publish sensitive details that were meant for private learning.
A decision log helps a postmortem compare later results with the evidence and expectations available at decision time.
Copy this postmortem
Intended outcome:
Actual outcome:
Customer impact:
Key timeline:
What worked:
What surprised us:
First warning signal:
Root conditions:
One to three system changes:
Owner / trigger / review date:
FAQ
Should I run a postmortem after a successful project?
Yes. Success can hide excessive effort, luck, or risk. It can also reveal practices worth repeating.
How do I find the root cause alone?
Ask why the condition existed, then look for a controllable system factor. Do not force one root cause when several conditions interacted.
Should the client see the postmortem?
Share the parts that improve trust, explain impact, or require joint change. Keep private personal notes, security details, and unrelated business information internal.
Convert experience into operating memory
Reflection is valuable only when it changes the next project. PlanovAI can connect outcomes, decisions, risks, and artifacts across time so lessons appear where future choices are made instead of disappearing into an archive.