In the abstract for “A Defined Process For Project Postmortem Review” authors Bonnie Collier, Tom DeMarco, and Peter Fearey state “Conventional wisdom in the software industry decrees that it’s good practice to conduct a postmortem study at the end of each project. Some would even suggest that this is not just a useful undertaking, but one of the fundamental principles of successful software development. The rationale authors most often cite for postmortem analysis is that only by analyzing our shortcomings can we learn to do better.We must begin by cataloguing such failures and learning from their patterns. The success of the postmortem-or of any learning process-demands a context that makes organizational learning possible. Participants are empowered when they know that each issue raised during the postmortem process must be added to the risk database and evaluated methodically on each subsequent project.”
While this is all true, most corporate postmortems are a waste of time, accomplishing little besides finger-pointing and assigning blame. In this series of articles, I will be going through the importance of postmortems and how we should go about them.
Part 1: A PostMortem takes Courage
Everyone loves to win. In fact there is nothing better after a win than having a post game party where everyone gets together and congratulates each other, slapping each other on the back and giving high fives. But is this all that should be done at the end of the game? How do you go forward to the next game ensured that you will experience the same success? Every coach knows that no matter how the game went or how perfect they feel their teams performance was, there is still some learning to be done. Some time must be spent reviewing the film and calling out what was done well, what could use some help, and even if they need to fill gaps on their team. This review will help to fine tune the performance of the team and ensure that in future games, whether they are against easier or more difficult opponents, the team will avoid making its past mistakes and continue to refine the things that they do so well.
This review is even more important if the team loses. The coach would never just let the team slink home, hoping that they will do better next time.
At the end of technical projects, we should be doing the same. We should be gathering together to review what was successful and unsuccessful. We call this meeting a post-mortem and we use it to determine process improvements with the hope of mitigating future risks and promote best practices.
A post-mortem is not easy, especially in the case of a project that struggled or failed. I would even say that a post-mortem takes courage. Courage to dig into and relive the struggles. Let me be clear though, this is not about chastising any of the team members. We have all see the movie where the coach chews out one of the players in front of the rest of the team at halftime. We know that player isn’t going to delivering much in the next half of the game. A good postmortem takes courage to point out the weaknesses of our team but not to pin blame. Courage to admit what you and your teammates already know – that the team is not perfect and that you need to work on certain parts of your game.
If you are feeling less than courageous about the idea of conducting a post-mortem on your recently finished project, take heart. Your entire team was at the game. They already saw many of the areas that they struggled with. There will probably be no surprises. Just like the sports team, everyone already knows where they failed they just need to own it and create a plan to overcome it next time.
Next up: A PostMortem takes Optimism