Why do post-mortems so rarely prevent the same problems from recurring?
Why Most Post-Mortems Fail to Prevent the Next Failure
Post-mortems are designed to turn failure into organisational learning. Most accomplish neither. Understanding why reveals something important about how organisations actually change.
The ritual that does not work
After something goes wrong, most organisations run a post-mortem. They gather the people involved, walk through what happened, document lessons learned, and file the report. Then, six months later, something similar happens again. This is not a coincidence.
Why they fail: three structural problems
Problem 1: The timeline is wrong. Most post-mortems happen too late and stop too early. They happen after emotional intensity has faded — good for objectivity, bad for accuracy since memory degrades fast. And they stop at "what went wrong" rather than following through to "what will we change and who owns it."
Problem 2: Root cause analysis stops too early. Most post-mortems identify the proximate cause and call it the root cause. The project slipped because the estimate was wrong. Why was the estimate wrong? Why did no one flag it? Why does uncertainty feel risky to surface? Real root causes are almost always systemic — implicating process, incentives, and leadership behaviour. The analysis stops when it starts to feel uncomfortable.
Problem 3: Action items go to the wrong people. Post-mortem action items are typically assigned to the people closest to the failure. But most systemic problems require changes that those people do not have the authority to make. If your post-mortem action items do not include at least one that requires leadership sign-off, you have not identified the real root cause.
What actually works
The organisations that genuinely learn from failure treat failure as a system output, not a people problem. They build failure review into their rhythm, not just their crisis response. And they measure whether action items get done — a post-mortem is complete not when the report is filed, but when the changes have been implemented and tested.