How to Complete a Great Postmortem Analysis Reliably

The quality of a postmortem rests entirely on the analysis.

Get the analysis right and teams will consistently improve on every project.

Do the analysis wrong and teams get stuck in an endless treadmill, repeating the same mistakes.

When I’ve asked folks on my team to complete the analysis part of a post-mortem, I get these kinds of response:

“The project failed because customers didn’t want it. We need to try something else next time.”

No detail, no deep understanding of what went wrong, no real learnings for next time, and no genuine action steps. Most folks default to this type of broad and useless summary of a project when asked to do an analysis.

While this used to frustrate me, I now understand why this happens. Asking someone for an “analysis” is an extremely broad request. Broad requests get broad responses and a wide range of outcomes.

What does a great post-mortem analysis look like?

A great post-mortem analysis will have:

A comprehensive list of issues that could have been better.
Correct identification of the few, major issues that held the project back.
If the project went well, accurately picking the items that produced success.
Non-obvious learnings that the organization can act on.
Accountability for action steps that will improve results on the next project.

I now structure my post-mortems in a way that gets people to check off each of these items reliably.

What methods are there to get a great post-mortem analysis?

The 5 Whys Analysis

5 Whys is a classic technique for any type of analysis and it does work for post-mortems.

Instead of explaining why something happened and then moving on, we ask why it happened 5 times in a row. That forces us to get to the root cause for why problems are occurring instead of only trying to fix symptom-level problems.

For example, let’s say that a marketing campaign didn’t hit its goal because an email was sent late. Here’s how the 5 whys would work:

Result of the campaign = the marketing goal was not met.
Why? Because an email wasn’t sent on time.
Why? The email manager forgot about the email.
Why? There weren’t any reminders during the day of the email.
Why? The marketing manager hasn’t built a system to send reminders to the team.
Why? It hasn’t been a priority until now.

By asking “why?” 5 times in a row, we’ve found a solution that can permanently fix the problem. A reminder system for marketing emails will reduce the chances that a marketing email is forgotten about in the future.

Once you teach this method to your teams, it’s pretty easy to add to your post-mortems. Simply add a ‘5 Whys” section the end of your post-mortem template.

That said, I don’t use the 5 Whys myself. I’ve found that teams run into a few problems with them.

Not Enough Time for Every Item

The 5 Whys is a very time-intensive process, especially with a group. When I’ve tried to do 5 Whys on every item, the meeting easily goes on for several hours. And running a bunch of rounds of 5 Whys back-to-back gets tedious for everyone, folks start to disengage. I’ve found that I can only get two rounds of 5 Whys out of a group before the quality drops significantly.

The Deeper Whys Get Generic

In my experience, teams have a tendency to get really generic as they go deeper into the 5 Whys. The first few levels are tangible but then it gets broad and unhelpful. For example, a new product launch might fail and folks will start explaining the failure being the result of a shifting market that no longer wants this type of product. Instead of making the jump that the internal product development processes aren’t discovering market needs accurately, the team can get stuck on how the market is shifting. The deeper the root problem, the more likely this is. Teams do get better at this over time with lots of coaching.

Lots of Problems Have Simple Fixes

Not every problem needs a deep analysis to uncover the root solution. On any large project, all sorts of problems come up. Most of them are small and there are usually 1-2 major items. 5 Whys works really well for major items that need root analysis but it’s overkill for all the smaller problems. Smaller items only need 1-2 levels of Why analysis to get permanently fixed. Let’s say someone didn’t forward critical info to the whole group because they clicked “reply” instead of “replay all” on an email. All that person needs to do is default their email to “reply all” and the problem is solved. No need to dig any deeper than that.

Root Causes Aren’t a Linear Ladder

The 5 Whys proceed in a 5 step linear process, like going down a set of stairs or a ladder. Each step logically leads to the next one. For situations that have straight-forward cause and effect, this works really well. But when the situation is uncertain and complex, I see root cause more like a tree. Multiple explanations are influencing the results, each branching off into their own root causes. The 5 Whys encourage teams to only explore one branch. And if a weak branch is selected early, the rest of the 5 Whys don’t help to uncover a better root cause.

Not Helpful with New Projects

On any new project, there’s always a ton of mistakes and problems. That’s to be expected, the team is learning for the first time how that type of project works. A 5 Whys process gets redundant really fast when the root cause is almost always “we had no idea how this worked before we got into it.” I prefer using 5 Whys on well-established processes that have more difficult and persistent root causes to discover.

My Post-mortem Analysis

To dodge the common problems of the 5 Whys, I use a different method that’s based on three sections that I add to the end of my post-mortem templates.

Team Feedback

I place the team feedback section right after the summary of the project. So folks have a chance to review everything that we shipped along with the results. Then they can offer feedback on anything that they like.

This is open-ended, I always let teams fill this section out however they want. I do expect each of the post-mortem participants to fill out this feedback before the post-mortem meeting where we have a deep discussion.

It’s a chance for every team or individual on the project to get their grievances heard. It’s also the perfect way to surface all the minor problems that need to get addresses but can be easily missed.

Sometimes, teams will add tons of feedback. This tends to happen when they endure the brunt of another team’s mistake or a crisis hits them particularly hard. Whenever a team uses this section to dump a ton of feedback, I’ll make sure their concerns get addressed so their frustration doesn’t continue to build.

When things go well for a particular team, their feedback is often a single line.

Why did we get the results that we did?

This is the first section that I leave open until the post-mortem meeting. We fill it out together during the meeting itself.

By waiting until the meeting, I can guide the team to a much stronger answer. I can also push the group to focus on the right problems, dig deeper, and explore alternative explanations instead of blindly accepting the first one that comes up.

Deep discussions like this don’t happen by accident. I find that I have to probe and ask a lot of follow up questions during the meeting for several months before the teams start having these discussions on their own. In other words, I take on the responsibility of leading the meeting and showing the team what excellent analysis looks like.

Be careful, one of the mistakes I’ve made in the past is to give the teams answers without nudging the discussion along with questions. If I make this a habit, the team will only improve as long as I’m in the meetings. But if I need to step out, the team becomes lost. Giving answers doesn’t help the team build the skills to do the analysis on their own. While the slower Socratic method feels like a waste of time in the short term, it does pay off in the long run. After a few months, I’m able to step out of the post-mortem meetings and let the team do the analysis on their own.

What action steps are we committing to?

I also leave the action steps blank until the meeting. It would be pointless to have someone fill this out before there’s agreement on why we got the results that we did. I also want everyone in the room while action steps get selected and assigned. This helps everyone feel part of the process.

This section only needs 10 minutes or so during the post-mortem meeting. I keep it simple and list out each action step and assign an individual owner. An example looks like this:

Design and implement a new product idea research process – Sue, Head of Product
Refactor CSS template on sales pages to reduce the chance of mistakes from manual work during each launch – Jill, Front-end Dev
Reach out to 10 customers that purchased during the launch and look for trends for why they purchased – Jose, Product Manager
Invite Director of Sales to Product roadmap meetings to get earlier input from Sales on the roadmap – Sue, Head of Product
Assign top three bugs from the new product to the engineering team and get resolved – Emma, Engineering Manager
Change customer support scheduling so more folks are available during product launches to handle the influx of support tickets – John, Customer Success Manager

I then wrap the meeting by asking each person with an action step to add that task to their own work queue.

Why This Postmortem Analysis Works

The three sections above seem simple, maybe even too simple.

They would be too simple if I had a team merely fill out the sections without pushing them. The key is to spend the bulk of the post-mortem meeting working through the “Why did we get the results that we did?” section. The better that discussion, the more effective the action steps will be. And if the action steps are effective, the team will greatly improve their results from project to project.

This post-mortem analysis does depend on my ability to nudge the team towards a deep discussion during the meeting. After a few months, they’ll have a good feel for what this looks like and I can take a less-involved role during these meetings.

It’s just enough structure to guide the team to a great post-mortem analysis without any busy work.