Fast Post-Mortems

When it’s time for a post-mortem meeting, do people in your office groan and make excuses? Do your coworkers complain that they’re too busy with client work to attend? Do post-mortems feel like a chore with no payoff?

I think everyone agrees that post-mortems are a great idea, in theory. When you finish a project, you get everyone from the team together to talk about what went well and what went poorly. Ideally, the knowledge gained is shared with the rest of the company, and you can avoid making the same mistakes over and over.

In reality, however, I’ve found that most offices either skip post-mortems entirely, or they’re so poorly run that everyone resents them. In many cases, the post-mortem meeting is run by the project manager or team lead, who is understandably motivated to find the project was a success.

The Problems with Post-Mortems

Many times I’ve sat in post-mortems where the project encountered significant problems that badly needed to be addressed, only to see the PM sweep those problems under the rug, declaring the project a success because it turned a profit and the client is happy.

Another problem I’ve seen is where management tries to standardize the results of the post-mortem by having everyone fill out a survey. Asked to rate the project’s success by metrics such as profitability, client reaction, and quality of work can also result in serious problems being ignored, because they don’t fit neatly in any of the survey categories.

The largest problem that I’ve run into, however, is when the post-mortem is delayed until the project is finalized, with the last check written and the final client handoffs complete. This can frequently be months after the designers completed the comps, and weeks after production was finished. In the meantime, everyone involved has started working on new projects, and it can be hard to remember exactly what went wrong.

Faced with an hour-long meeting to discuss a project that finished a month ago, or a lengthy form to fill out, and a team leader whose only success metric is profitability, it’s understandable that your team might be looking for reasons to skip the post-mortem.

The Solution: Fast Post-Mortems™

I have been testing a post-mortem process meant to address these problems for several months now, with promising results. I call it the Fast Post-Mortem™ (the trademark is just for fun). The basic rules for Fast Post-Mortems are:

  1. Only 15 minutes long
  2. Have a neutral moderator
  3. Have clear conclusions, and share them

15 Minutes Long

By limiting these meetings to 15 minutes, you are doing two things. First of all, you’re addressing the “I’m too busy to waste an hour in a post-mortem” argument. Even the busiest person on your team should be able to spare 15 minutes.

Secondly, by setting a time limit, you’re limiting how much everyone can talk. In an hour-long meeting, the tendency is to let everyone talk about everything, and frequently the conversation detours into unrelated topics. In a 15 minute meeting, you’ve got enough time to go around the table only once.

Since each person only has a minute or two to speak, they have to limit themselves to sharing the most important feedback they have. In my experience, this is a wonderful way to focus on problem areas. If several members of the team have the same feedback, then you’ve got a real problem that needs addressing.

Of course, you’ll need someone to enforce these rules, which brings us to the:

Neutral Moderator

I can’t emphasize this enough: having someone who worked on the team run the post-mortem is a very bad idea. You need to create an environment where everyone can speak their mind, and if your feedback is about the person running the meeting, that won’t happen.

The good news is that you don’t need anyone with special training or anything. You just need someone who wasn’t on the team who’s willing to take notes and facilitate the discussion.

If you’re going to run a Fast Post-Mortem, your jobs are:

  1. Keep the meeting moving. Give everyone a chance to talk, and if anyone’s taking too long, be prepared to cut them off. If your team is particularly bad about rambling on, don’t be afraid to use an egg timer, or sing the jeopardy theme as their time is up.
  2. Keep clear notes. Ideally, on a whiteboard, so everyone can see what you’re writing. Don’t write down everything people say, try to rephrase it into a generic takeaway like “more frequent checkin meetings” or “if the client misses a deadline, our deadlines must shift.”
  3. Share the key takeaways with the rest of the company (more on that in a minute).

I like to start these meetings by standing up and giving a brief explanation of what a Fast Post-Mortem is. Even if most of the teammembers have been to one before, it’s helpful to recap the rules. Explain that you will go around the table only once, and that everyone only has a minute or two to speak, so they should limit themselves to their most important feedback. Also, remind the team that the whole point of a post-mortem is not to pat yourselves on the back, but to learn from your mistakes. So while it’s nice to say “I think the project went well,” that’s not helpful feedback. Encourage them to focus on what went wrong.

Lessons Learned

Which brings us to the lessons learned. A post-mortem is pointless if the knowledge isn’t shared. I like to take the three or four biggest issues that were raised, and write them up in an email that I send to the whole company. The idea is that over time, clear patterns will emerge. If you see three post-mortem summaries in a row talking about missed deadlines, then clearly that’s something for the company to work on.

I hope that these guidelines are helpful to you in making post-mortems more effective for your company, as they have for me.


No Comments on “Fast Post-Mortems”

You can track this conversation through its atom feed.

No one has commented on this entry yet.

Leave a Reply

HTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>