Looking Back on What Worked and What Didn’t: Conducting a Project Post Mortem

“Insanity: doing the same thing over and over again, but expecting a different result.”—Attributed to Albert Einstein, German-American physicist.

Looking Back on What Worked and What Didn't: Conducting a Project Post Mortem by  Laura Stack #productivityIf the first thing that comes to mind when you hear the term “post mortem” is a medical examiner or the novel by Patricia Cornwell, then you’re in good company. But the term is useful for more than describing autopsies; it also has a long history of use as a business term, at least when applied to recently finished projects. The idea here is to examine the entire venture, from beginning to end, and identify two categories of actions: things you and your team did right, and things you did wrong.

That said, don’t treat a project post mortem as a blame game. Use the process as a teachable moment so you can move forward confidently, having learned from experience. Moreover, a post mortem isn’t just for failed projects. You can also benefit from autopsying projects where everyone walked away happy. Every little thing you discover can lubricate your team workflow processes so you work together even more successfully in the future.

Looking Back

In recent years, the term “project retrospective” has become popular among those who find “project post mortem” a bit too graphic. That’s fine, but I think “post mortem” has a more visceral impact (to coin a phrase). It also helps the participants take the process more seriously, and makes them more likely to remember the project’s lessons.

In any case, the process has become a standard part of many white collar work processes, particularly in the software field. Indeed, the Scrum and Agile Project Management methods often include mini-post mortems/retrospectives at the end of each stage of a project. The reasoning is thus: why not incorporate process improvement into the project as you go along, rather than wait until the next project?

Even if you take the traditional route, which works best for most non-software industries, I recommend you include a post mortem in your project plan from the very beginning. Actively plan to learn. Don’t just do it when you can afford the time, or you’ll probably leave it for the projects that fell apart, lost money, or die on the vine—those most likely to devolve into finger-pointing sessions that accomplish nothing and waste time and money better spent moving onward and upward. Whether the project is big or small, make the post mortem a step in the wrap-up. What you discover may prove only of general use, or you may uncover a gem crucial to successfully completing the next project. Either way, the time isn’t wasted.

Rules of the Road

The project retrospective is one of the most important meetings your team can participate in, and one of the few that’s not a waste of time—as long as you follow the standard guidelines for an efficient meeting. You’ll need a facilitator: someone who controls who speaks and how long, guides the discussion, and blocks those who want to blame and point fingers. Some experts recommend choosing someone who has no stake in the project or is otherwise neutral, but how often can you find someone outside your team to take on the role? Short of hiring someone specifically to facilitate meetings you’ll either have to appoint someone, or the team lead will have to act as facilitator. It’s also a good idea to have someone take the minutes, so you can convert what you learn into a permanent form that’s more easily taken to heart.

Keep these points in mind:

  • Conduct the post mortem as soon after the project’s completion as possible. The longer you wait, the more likely the details will grow hazy in people’s minds.
  • Prepare an agenda, just as you would for any important meeting.
  • Prepare a list of questions for each participant.
  • Ask everyone to enter the meeting with a relaxed, constructive mindset.
  • Make them all aware of the rules of engagement: e.g., no blaming, sniping, or sarcasm.
  • Make sure everyone participates.
  • Keep the meeting relatively short; anything more than an hour or so will drag.
  • Create a list of takeaways the team members can take action on.
  • Share your results with other teams.

The ultimate goal is to have a constructive discussion of how to improve your performance as a team. This requires a firm hand and a disciplined response. If you let the participants point fingers and blame each other for what went wrong, your post mortem may result in dissension, resentment, and institutionalized errors. Nor should you gloss over mistakes to make your team feel better; that just sets you up for failure down the line. Be blunt and honest with each other and yourselves.

If your post-post mortem report doesn’t result in a list of lessons learned and no one benefits from the experience, you’ve wasted your time. So before heading in, make sure everyone knows what to expect, and take the process as seriously as a medical examiner would take a human post mortem—whether the project in question has been the greatest success of your professional life, or your most abject failure.

 

© 2016 Laura Stack. Laura Stack, MBA, CSP, CPAE is an award-winning keynote speaker, bestselling author, and noted authority on employee and team productivity. She is the president of The Productivity Pro, Inc., a company dedicated to helping leaders increase workplace performance in high-stress environments. Stack has authored seven books, including Doing the Right Things Right: How the Effective Executive Spends Time (January 18, 2016). She is a past president of the National Speakers Association, and in 2015 was inducted into its exclusive Speaker Hall of Fame (with fewer than 175 members worldwide). Stack’s clients include Cisco Systems, Wal-Mart, and Bank of America, and she has been featured on the CBS Early Show and CNN, and in the New York Times. To have Laura Stack speak at your next event, call 303-471-7401 or visit her website.

 

 

Share: