The term post-mortem is latin for "after death", and originally referred to a medical examination of a corpse to determine the cause of death. The term has, more colloquially come to refer to any "after the fact" analysis and discussion of a recently completed process or event, to see what lessons we can learn from it.
Such analyses are have been going on for a very long time. Five thousand years ago Egyptian doctors recorded wounds, treatments and results to build up a body of knowledge about what did and did not work. During the middle ages, engineers from all over Europe would flock to the site of a collapsed cathedral to attempt to learn lessons that would prevent similar fates from befalling their own cathedrals. Military strategists have long studied every battle ever recorded so that they could learn lessons without having to suffer defeats.
The above examples all seem focused on understanding what we did wrong ... and historically (and perhaps psychologically), failure has proven to be one of our best teachers. But we also want to learn from our successes. Every task we do can be an experiment where we try new things. Some experiments will not turn out the way we had hoped, but some will turn out better than we could have imagined. In organizations that are serious about getting better at their jobs, retrospective reviews are an important part of every project.
The goals of a post mortem review are very simple:
Exploring what we did wrong is frightening ... and in some organizations it is dangerous. If admitting having made mistakes opens us to criticism or discipline, we are unlikely to make such admissions. This strategy is ultimately self-defeating, since failing to understand a past mistake usually condemns us to repeating it again in the future. Organizations that are serious about improvement understand this, and take trouble to create a process and culture wherein it is safe to explore mistakes.
When we enter into a post-mortem process, we must all accept a few basic premises:
It is absolutely essential that everyone involved completely accept this "no blame, we are here to learn model". Many organizations go to great trouble to create such safe environments. The FAA, for instance, has an Aviation Safety Reporting System, whereby pilots who make "mistakes" can gain immunity from regulatory discipline if they report those incidents to the ASRS.
In highly stressed environments, built up fear and anger may make it very difficult to get people to discuss (or even to objectively look at) a recent project. In situations like this, the organization may be in serious need of healing, and it may be necessary to have the process managed by a professional facilitator. In healthier settings, it may be "just another meeting" where the goal is simply to gather opinions and formulate recommendations. The types of questions that should ultimately be explored are:
Even in non-threatening environments, gathering this sort of input can be a delicate process. It is important that everyone be given the opportunity to speak, and that the meeting not be monopolized by the people with the strongest opinions and loudest voices. As in brain-storming, the early phases should be non-critical:
You can talk about your own experiences, but you are not allowed to comment on somebody else's experience.
After we have given everybody the opportunity to express all of their thoughts, we can then enter a second phase where we compare, combine, sift, sort, and synthesize punch-lines out of the raw material developed in the first phase.
People are often hesitant to complain about problems or concede errors when their managers are present. Thus, it is often a good idea to conduct separate post-mortem for people at different levels in the management hierarchy. Higher level managers need the output of the post-mortem process to make sure that the needed lessons are learned. It may actually be counter productive for the managers to be present as people are exploring the events of the project.
The process of conducting a post-mortem is, in many respects, a brain-storming process. Many ideas and issues will be explored, and most of them will not prove worthy of capturing. Explorations of how things went wrong may be heated and/or cathartic ... but publishing the details of those stories would be antithetical to the goals of the process.
A Post Mortem report is not a compendium of stories that came out in post mortem meetings. All of those stories need to be examined, reconciled, filtered, distilled, prioritized, and synthesized into cogent punch-lines. They then need to be organized into a few key points, with examples of problems that occurred and recommendations for how to deal with them in the future.
A good post-mortem report clearly describes problems, and opportunities for improvement, and it does so without blaming people or rehashing heart-breaking stories. In many organizations, it is common for post-mortem reports to be widely distributed, so that many people have the opportunity to learn from every project.
There is no one best format or technique for post-mortem reviews, and there is no authoritative list of questions to be explored. Every organization has to evolve a post-mortem style that fits in with their culture and mission. Some may involve a weekend of drum circles and trust exercises at a forest retreat, while others are just 30 minutes of prepared power-point presentations in the main conference room.
A good post-mortem meeting is any meeting where people honestly share and explore their experiences with the intent of learning from them and doing better next time. Everything else is just a matter of style.