Post-Mortem: “Bones” for Dead Software Projects

Rest In Peace (R.I.P. from Latin requiescat in pace) is a sentence that typically appears on Christian tombstones. Software development projects usually have the same destiny. Once they are finished, often the best thing that will happen is a little celebration for the project team.

Nobody will formally look back at a project to understand what went well or wrong and why those things happen, so that this project can actually rest in peace and lessons learned could be used for the next projects. There is however an activity to analyze project after their completion. It is called “post-mortem” analysis (so the RIP reference is not far) or “retrospective” in the agile approach.

If you have not heard about this practice or never performed such activity, you should not be ashamed. I have never seen its implementation in my software development life. Even in an early Agile survey published by Version One, where a large majority of respondents are using an Agile approach, only 39% of the participants were using retrospectives. Why?

The first explanation is that time is a rare resource in software development organizations. It is often associated to money in budget-driven companies. As there is a sense of urgency, people try to use their available time for the more essential (for them) activities. It is sometimes already difficult to justify taking some time to think before coding, that trying to have time to think after coding could seem a utopia. It is also difficult to tell as a project leader that you will spend some man/days after the project’s completion to think about what went wrong. Are you not supposed to do things right in the first time?

Our difficulty to create a context for constructive criticism is another issue faced if you try to institute some “post- mortem” reflections. This is mainly due to the difficulty to separate the problems from the people that are associated to them. This is an important issue in organizations where professional excellence is a driver for monetary gains and career evolution. Will you speak openly about project problems if part of your (or your colleague) salary is a bonus linked to achieving certain professional goals? Maybe not…

There are however techniques that could help you to profit from lessons learned without creating personal issues, so that your past projects could really rest in peace and everybody could improve from a shared experience. You will find more resources about post-mortem or retrospectives for software development projects in the following articles:

* Postmortem Culture: Learning from Failure

* What is a Software Post-Mortem and How Do You Write One?

* Why Most Project Management Post-Mortems Fail and How to Fix Them

* Best Practices for Postmortems: A Guide

* Refactoring Your Development Process with Retrospectives by Rachel Davies

This article was originally published in September 2007 on the platform blog.martinig.ch. It is reproduced here with permission, as this platform is discontinued.