Post-Mortems, Pre-Mortems and Mid-Mortems

George Santayana stated that “Those who cannot remember the past are condemned to repeat it”. Nowhere is this more evident than in the execution of projects in any industry if the lessons of previous projects are not remembered. It is important to have a good systematic process to review projects when they are completed, no matter how successful or unsuccessful they were. There are learnings from both successful and unsuccessful projects that will help when carrying out future projects by repeating the things that went well and avoiding the pitfalls.

It is useful to have a formal post-mortem of each project. An input to this could include the ‘Lessons Learned Register’. This is described in the PMBOK Guide as a record of impact, recommendations, and proposed actions with situations encountered during project execution. It can record challenges, problems, realized risks and opportunities. It is helpful to keep this record from the start of the project. Otherwise the project post-mortem may involve only those involved in the latter stages of the project and concentrate more on issues encountered later on.

One issue with projects is that they nearly all obey Hofstadter’s Law “It always takes longer than you expect, even when you take into account Hofstadter’s Law”. The timing of the project, and sometimes the cost, especially in regulated industries usually overruns. This is as a result of unknown unknowns (see last article) and optimistic planning. Often in order to get the go ahead for a pet project the proposer will present optimistic timelines to management because it is easier to get forgiveness for a project overrun than permission to run a project over a long timeframe.

In order to have meaningful project post-mortems there needs to be management commitment to the process. If there is a specific project management group in the company, they should organize it. Otherwise, the manager of the project manager should make sure if happens.

Mike Gunderloy, a consultant in the IT industry, has come up with nine suggestions to improve a software post-mortem. These are also applicable to projects in regulated industries.

1. Plan for post-mortems. There needs to be time and resources committed to it. The process needs to be taken seriously and supported by the managers of the people who need to take part. Often managers do not want the process to take place because they only want to focus on the success of the project and not highlight anything than they or their teams could have done better.

2. Keep it close in time. Schedule the post-mortem soon after project completion. The longer the delay the poorer the memories and the less likely it will be valuable. For longer projects it may also be useful to have mini post-mortems after each stage.

3. Record the project details. In the future readers of the post-mortem may not fully understand the nature of the project.

4. Involve everyone. If only a few are involved details and perspectives will be missed. If too many are invited to a big meeting, many of the shyer participants will not contribute, especially if the contribution could be taken as criticism by another attendee. The organizers of the post-mortem should seek the input of many people involved in the project and this does not have to be one big meeting. If they have time they could talk to each individually.

5. Get it in writing. The results of the post-mortem needs to go into a written report or knowledge will become lost or distorted.

6. Record successes as well as failures. Most projects are successful, at least partially and this needs to be acknowledged as well. You need to know that some tasks and approaches are worth repeating in future projects.

7. It is not punishment. Make sure that the process is presented to learn how to do the job better and is not linked in any way to individual performance reviews. If participants suspect scapegoating the process will not be successful.

8. Create an action plan. There is little point in the process if there are not actions to implement the learnings in future projects – plan to repeat the good aspects and to counter the difficulties.

9. Make it available. The report is not much use if very few can learn from it. When I was an active pilot, I found it useful to read accident reviews. Make the learnings available to all project managers.

The Pre-Mortem

The post-mortem approach can also be applied to projects before they are completed by using a brain-storming technique called a pre-mortem. Early in a project execution invite the main team members to a brainstorming session. The participants are told that they are in the future and that the project has failed. They are invited to suggest why.

The team members will come up with many scenarios for why the project failed. Your company was beaten to market by a competitor, a comet hit the factory, a virus caused most of the world to go into extended lockdown. Think imaginatively and come up with multiple scenarios. When you think about outlandish events, more likely events that you had not thought of may come to mind. Many mundane failure causes will be raised as well like not having right people, high engineer turnover, corporate squeeze on capital funds, or regulatory objections.

Afterwards review the scenarios. Decide how likely they are. Is there anything you can do now that would prevent them causing a complete failure of the project? This is a useful risk analysis tool. When people imagine a real future situation, they see things from a different perspective than conventional risk analysis.

Mid-mortems are also useful. This is a project review that combines elements of post-mortem and pre-mortem and can be carried out at any stage of a project execution. Part of the mid-mortem is a mini post-mortem analyzing execution of the project to date. And part of it is future speculation of how the project will go in the future.

Include scenario analysis in the mid-mortem process. If you already carried out a detailed pre-mortem, review its scenarios during the mid-mortem.

There is no better guide to executing a project well than the knowledge of how a good project from the past was run. If you never ran this type of project before carry out a detailed pre-mortem. The next best guide is knowledge of how badly run projects were executed so you can avoid the pitfalls. Make sure you do not repeat mistakes from the past just because you did not know about them.