How to Conduct a Post-mortem Meeting

We already talked about the pre-mortem, a tool intended to prevent failure instead of learning from it. This is the perfect and desired scenario, of course.

But let’s be honest: shit will hit the fan.

No matter the extent of the disaster, when your project fails, you can still take solace in that you’ll learn from it.

But to really learn from it and make it helpful in the future, you have to formalize the process a bit. The post-mortem is the perfect tool for that.

Most people know what is a post-mortem: the examination of something after it happened to find out why it succeeded or failed. A post-mortem is usually performed at the end of a project, and lessons learned can be applied for further projects.

Any project, success or failure, will lead to lessons learned in some way, although the second may be especially prolific in this regard. Even when a project is a total failure, a post-mortem represents the opportunity to learn and move forward, and to avoid repeating the same mistakes over and over again.

How to Conduct a Post-mortem

Here are the steps to follow to conduct a successful post-mortem. Prior to the meeting, invite the project team and brief them on the plan. Send the questions you will address in advance so people can think about it and know what to expect.

Want to make sure you run a super-productive post-mortem meeting? Send a survey to the project team before the meeting to gather lessons learned and dig through them during the meeting. This also allows you to gather feedback from people who cannot attend or will not be invited to the post-mortem meeting (in the case of a very large project).

Make sure you have a white board in the room and bring some pens and paper.

And then, follow these steps:

1. Start the meeting by summarizing the project mission and initial objectives: People may be working on many projects or already have been reassigned to new ones and a refresh will be helpful for everyone. Remember, people forget things.
2. Present the project outcomes: Present key outcomes of the project, and any evaluation you have at hand (from the client by example).
3. Generate discussion on lessons learned: Prompt the team with questions like: Are you proud of the project deliverables? What went wrong? Why? What could we have done better? What went well? What can we do to replicate it/make it consistent?
4. Generate lessons learned and solutions: Propose a set of lessons learned and solutions. You want to make sure the meeting is solution-oriented, and uplift the level of discussion so it’s not just complaining. Record all lessons learned on a white board.
5. Wrap-up: Thanks everybody for their honesty and input.

Here are three key rules to make sure the discussion remains constructive. It may be a good idea to display them on a board so everybody can see them at any moment. First, we want people to be honest and comfortable to say things straight (rule #1). But it’s not a place to blame specific people, which would not contribute to create a climate of trust and be useless at that point (rule #2). And finally, the whole point is to stay solution-oriented (rule #3). It is so easy to criticise, but the point of this meeting is to come up with lessons learned and solutions, not a bunch of complaints. 

And the most important thing: make sure to follow up with a report and share it with the right people.

Too often, post-mortems are part of the companies’ processes; they are held, reports are written, and then nothing is done with that. Lessons learned stay in a report that is not read by anyone. New projects are undertaken without referring to lessons learned from similar projects.

What a waste!

The aim of a post-mortem is not only to act as a closing meeting for the project. After all, as stated in the article “A defined process for project post-mortem review”, lessons learned the hard way on past projects are, if nothing else, risks for future projects. Or in other words: “A post-mortem that doesn't impact future action is a waste of time.”

From my project management experience, this is where we have a problem. We do hold post-mortem meetings. We gather brilliant insights that could make the difference for further projects. And then, we forget about it, bury them in a folder or an electronic document management system in which finding the relevant information is an impossible task.

And then, we wonder why we repeat the same mistakes over and over again.

The problem is also that often, lessons learned relate to the organization level, not the team. So if they stay within the team, issues will remain.

For example, one lesson learned I saw over and over in post-mortem meetings relates to human resource availability. Not having the right people at the right time brings big challenges that reach beyond the boundaries of the project. Not only will the project be delayed, cost more money and fail to meet the needs of its stakeholders, but it will impact other projects as well.

Here’s why: if your project is delayed due to missing key resources, other projects that rely on the same resources will be as well when people work on your project at unplanned time (when they’re supposed to be working on another project, which will then go through the same issue as you). We tend to get a domino effect, where one resource issue on a project leads to planning-related issues for a larger number of projects.

This leads to a crisis mentality, where people have to work on what becomes an emergency instead of preventing such complications from happening.

But the solution to that has to come from organizational processes, and the team can’t do much more than share this challenge (and pray that something is done about it).

Actually, this is such an acute issue in organization that we built software to solve it, you can check it out here.

All this to say: when something has to change at the organizational level, make sure to notify the right people about it, as the top management or the head of the corresponding department.

Make sure something is done about it, follow-up on the issue, and keep your team informed about it. This is not only the decent thing to do to make sure the organization improves, but it will prove to your team that you consider their input and do everything in your power to make things happen.

This may sound unrealistic especially in a large organization, but let’s try to be an agent of change instead of giving up already. Who knows, we may have more power than we think when we give it an honest try.