5 Ways to Kill a Post-Mortem

Software projects fail.

One of the techniques you could apply to a project not going well is a post-mortem. A meeting where the critical participants meet to discuss what is going wrong. Preferably when there is still time to salvage things. But before you run a post-mortem of a project, here are some things you would want to consciously avoid. Hopefully as a project lead or in similar capacity, this will help you facilitate the meeting and shape positive outcomes. It starts with you. 

The Final Blame-Game

The idea of a post-mortem is to take an earnest look at some of the things that went wrong and understand why and how to avoid them. In brief, make mistakes, but please make new mistakes.

If the meeting degenerates into blame-fixing, then you are headed in the wrong direction. Rule the meeting politely but iron glove. Don't let it become a mudslinging match.

If you have been deeply involved in the project, chances are high that you would have your own frustrations as well. Keep them under control. Appoint a watcher. Pre-discuss with your watcher that should you lose control in the heat of things, watcher makes a signal ("Is it Monday today?") to remind you and get you back.

Let loose over some beer

An often-asked question is, "Should I take the team to our favorite watering hole to allow people to relax and be more open ?".

Err on the side of caution. Stick to a formal atmosphere. I am not recommending mandatory business attire, but setup a proper meeting, let people know the time and purpose in advance. Restrict the meeting to the critical few, the ideal size of effectiveness ranging between 3 - 10.

Let's keep the beer-party to celebrate when things are fixed and we succeed, shall we ?

Anything short of brutal honesty..

will impede success. Having said that, this is one of the things you will not have much control over. Candor in an organization is a non-trivial task. The few things you can do are to listen without prejudice, repeat the value of candor, and have an iron-hand over anybody resorting to an aggressive defense in the meetings.

Almost always, candor starts with the leadership. If you fail to explicitly demonstrate candor (maybe by owning up your own shortcomings), why will others do the same ? Furthermore, what ethical right would you have to expect people to be candid if it does not start with you ?

I fixed the process

We, software engineers are great at creating processes. The crux of our profession is to create procedures for inanimate (well, until now) machines to obey. So we happily create processes to fix other broken processes.

Remember, a post-mortem is not only about fixing processes.

At a post-mortem, pay close attention to the personal and interpersonal behavior of the team. Who gels well with whom ? Who can confide in whom ? Who will refrain from giving you bad news just because you may think he is incompetent ? Who will refrain you from giving bad news just because she will be happy to see you fail ? Who is not pulling their weight on the team ?

Processes are important and many a times they need to be fixed. But if you are oblivious of the interpersonal dynamics that makes up a software team and consequently can make or break a project, prepare for further failure.

The One-time PM

Unlike human autopsy, be certain of failure if the post-mortem is a one-time event without follow-ups. In that sense, the word post-mortem is a bit of a misnomer. Make sure people understand that there will be follow-ups, better yet, schedule them up-front, to make sure the right metrics are improving and the needle is moving in the right direction. A word of caution: if the problem was anything major in the first place, be prepared that the first couple of follow-ups may not show remarkable progress.

Persevere.