Project Post Mortems

Another couple of days and the current cycle comes to an end: We are indeed releasing the next iteration of a product. Of course it doesn't end there, as most software products don't ever really finish. No matter though, it is a nice time to take a step back, pause and evaluate how things went this time around.

It's time for a post mortem of sorts.

Now, if things didn't go quite ideal, then the temptation is great to focus on all the things that went wrong. This is especially so, if someone else can be blamed. That's (at least with some creativity) pretty much always the case. Other teams perform similar reviews and in the end, when notes are compared, everything sort of boils down to various groups blaming each others, either rightfully or less so. This is terribly unproductive.

Therefore, my big goal for this round of post mortems will be to pay special attention to the things that went right. Yes, there might be issues worth talking about that did not go well at all. Not quite disastrous, but possibly far from ideal. Those will need to be addressed, simply to help not to repeat similar things in the future. We'll start with the positive things though.

Developers, designer, etc. can be a tough crowd. They like to claim emotional detachment, whenever it appears appropriate to say, but most of them don't like criticism. Managers, especially those who were busy marketing their latest idea of an improved process? This can be an altogether difficult audience for however well-intended criticism.

If the emphasis is on only negative issues, those topics may well dominate the discussion. In fact there might not even be time to discuss the good parts of the project. Ugly blame games keep everyone busy, people become defensive, professional discussion turns into personal arguments and what could have been a constructive conclusion of the release, turns into a pretty unpleasant experience for most people involved.

Certainly, we don't want that.

Overall, there are in fact three items on my agenda for the post mortem:

  1. State positive experiences, especially those involving other teams. Everyone likes good news. The product is out the door after all, so there's nothing wrong with patting each others shoulders.
  2. Discuss those areas that need improvements. This needs to happen in a non-threatening manner. Most often it really does not matter who was responsible for a particular issue. On the grander scale of things, everyone is on the same team. Everyone should understand that they should be interested in solutions for the future rather than tearing apart the past.
  3. Make sure all issues, incl. action plans are in writing. We'll need a reference and at the next post mortem it will be useful to look back and compare.

Let's hear some of your experiences with post mortems and some of the things to which you especially pay attention to make sure your post mortems are successful these days.

This is one issue that

This is one issue that actually required very little convincing. One day, several months back, my manager surprised me by bringing up that idea without me having evangelized the issue beforehand. Most people in the office appear to not like the term "post-mortem" either, but no matter the label, the goal remains the same: Review and figure out what we did well and where we can improve.