You learn from your failures. Not your mistakes (because you can gloss them over), and not from your successes (because they’re hard to reproduce).

You learn from your failures. In one of my last companies we had a saying: if we aren’t failing every week, we aren’t trying hard enough. Failure is a good thing, learn from it.

You learn from your failures. As an individual, a team, a company, hell even a relationship. When you well and truly fall on your face and it hurts is when you take a step back and learn because you never want to hurt like that again.

Which is where the project “post-mortem” (or debrief) comes in. Some companies do this when an issue is too big to ignore and it turns into a blame fest. Some do it every project but it’s just procedural and nothing is learned. Others try not to upset anyone in the room because after a failure can be an emotional time.

The Value of Learning

Real debriefs have real value, and you should never let a good failure go to waste. It is a chance to evaluate the people, technologies and processes that led to the failure.

I’ve been involved in dozens of project debriefs across a fair number of companies and agencies, and wanted to distill my learning on this both to get feedback from the world on how you do post-mortems as well as maybe just to help folk who are struggling with this issue. No, it isn’t rocket science, but open learning is almost never a bad thing!

Three Rules of the Debrief

There is a fundamental problem with most debriefs. They are too long, too personal, not actionable and demotivational. If you are going to run a debrief you need to focus. Get everyone to agree to these rules up front:

1. Keep it short: The tendency is for these to be 2-hour long meetings where you delve into everything. 2-hour meetings are always a fail because you never want to repeat them. Try to keep these discussions focused. Your first one might be long, but aim towards an hour.
2. Keep it professional: Especially in big projects that fail, there is the temptation to either attack someone else, defend yourself (or both). The moderator (independent non member of the team) may have to enforce professionalism brutally, but agreeing to this rule helps keep things from escalating into an argument.
3. Keep it actionable: Too many debriefs get lost in the minutiae. The goal of the debrief is to come out of it with things you can change, not just a list of what went wrong and who’s fault it was.

Three Tips for Successful Debriefs

1. Post-Its Are Your Friend: It is too easy to kill conversation. Whenever someone raises something irrelevant  (like an issue during the timeline phase), put it on a post-it and put it to the side. You never want to lose an idea to the ether, or ignore feedback after all.
2. Run by an independent: Someone in the project running it means someone with a stake, and something to lose. Independent moderators focus on value (and value their time more because they have nothing to prove). Ideally this would be someone with relevant expertise to keep things on track.
3. There are no seniors: In a debrief, everyone is equal. Don’t allow seniority, expertise or personality to allow someone to dominate the conversation or detract from team learning.

Three Phases of the Debrief

Since most debriefs lack focus, here is what you should be covering:

1. The Timeline: Develop a timeline of what happened. Both right and wrong, what was the story arc of the project? Every project has a story, so tell that story. If people start to get blamey or emotional or focused on the negative, shelve that til the next portion of the exercise.
2. The Issues: Dave Fleet once ran this section using post-its, and I’ve become a fan of this approach. Hand out a whack (technical term) of post-its to each person. And have them list every issue they can think of. Then put them all on a big board and group them. These issues can be actual challenges, technical issues, process issues, management issues, anything. Remember Rule 2: keep it from being personal (ie: not “Doug let the servers go down”, but “Server Uptime”).
3. The Actions: Actions matter. If there are issues identified in phase 2, they should have an action associated with them. Keep actions SMART. When you produce a list of actionable items, assign someone to check up on them in a month.

Ending the Meeting

At the end of every meeting, you should always know if the meeting has been valuable. So close off with focusing on wins not just fails. While the purpose of the debrief is to learn  from mistakes, anytime you leave a meeting talking about mistakes for an hour is demotivational. End with the wins and successes to remind you and your team that while things went wrong, that failures aren’t the whole story.

What Do You Do?

So this is what I like to do. What do you like to do? Do you love/hate debriefs? Had good/bad experiences with them?

Let me know in the comments!