Nine steps to IT post-mortem excellence

Most IT project post-mortems are exercises in finger-pointing and assigning blame. Here are nine steps to make them useful.

Why IT failure post-mortems donÂ’t matter

Conventional IT wisdom holds that post-mortems are essential to ensuring future project success. Sadly, many corporate post-mortems are a waste of time, accomplishing little besides finger-pointing and assigning blame.

Here's what says about the post-mortem issue:

Most teams don't use postmortems. The teams that do don't always get value from them. Frequently, postmortems have a habit of either turning into "the blame game" or whitewashing mistakes. A bad postmortem can create dissension and institutionalize mistakes.

On the other hand, well-run post-mortems help a project team create a culture of continuous improvement. Embedding a culture of ongoing, positive change inside a project delivery organization is the best way to ensure long-term success.

Post-mortems are an important link in this chain of positive improvement.

Running a successful post-mortem isn't magic, although it does require thoughtful planning. Consultant Mike Gunderloy offers a list of nine steps to post-mortem excellence:

  1. Plan for post-mortems. To get the most value out of this activity, you need to take it seriously. The postmortem should be a scheduled activity, with time for a meeting of the team to discuss the lessons learned and time for someone (or some group) to write the postmortem report.
  2. Keep it close in time. Don't let memories fade by scheduling the postmortem too long after the end of the project. Ship the software, have the celebration, and then roll right into the post-mortem.
  3. Record the project details. Part of the post-mortem report needs to be a recital of the details of the project: how big it was, how long it took, what software was used, what the objectives were, and so on.
  4. Involve everyone. There are two facets to this. First, different people will have different insights about the project, and you need to collect them all to really understand what worked and didn't. Second, getting everyone involved helps prevent the post-mortem from degenerating into scapegoating.
  5. Get it in writing. The project manager needs to own the process of reducing the post-mortem lessons to a written report, delegating this if necessary.
  6. Record successes as well as failures. It's easy for a post-mortem to degenerate into a blame session, especially if the project went over budget or the team didn't manage to deliver all the promised features.
  7. It's not for punishment. If you want honest post-mortems, management has to develop a reputation for listening openly to input and not punishing people for being honest.
  8. Create an action plan. The written post-mortem should make recommendations of how to continue things that worked, and how to fix things that didn't work. Remember, the idea is to learn from your successes and failures, not just to document them.
  9. Make it available. A software post-mortem locked in a filing cabinet in the sub-basement does no one any good. Good organizations store the supply of post-mortems somewhere that they're easily found.

To summarize, make your post-mortem successful by carefully preparing in advance, analyzing the project systematically, producing actionable findings, and actively sharing the results.

Follow these steps and your next post-mortem will be one of the few that actually are useful.

[Image via Coding Horror.]