Project Management 101 : Software project postmortem

Software project postmortems are again one of those elusive things which project management professes to doing but seldom realizes how to do.  Very similar to the treatment of agile. Everyone claims to be agile but has no clue of how to go about being agile. The following is part 1 of doing PROJECT POSTMORTEMS.

Project Management 101 – What works and whats PMP

Software Project Postmortem

The basic thing that guides every aspect of the project postmortems is PLANNED V/ s ACTUALS.

To determine the degree of goodness OR Badness of a project delivered it is imperative that we have this data. Without this conducting a postmortem would be futile. We need to have a chronological track of what was ‘planned’ at each stage and what was the ‘actual’. This can be achieved by maintaining a regular status reports (preferably weekly). If you do not have this data then its simple.

DO NOT INVEST THE TIME IN DOING A POSTMORTEM.

It will not be possible to draw any conclusive action items since we DO NOT have the metrics to support it. From the literature that we I have come across I’ve noticed that often the focus areas are not ones which yield measurable metrics. This is where the planned v/s actuals guidance is useful.

Normally one needs to look at the cumulative trends of the project dashboard over the project lifecycle (grrroaan now we need project dashboards… ) Well we do…. Its simply a set of metrics that are ascertained and measured regularly. The postmortem is simply the task of plotting it on a graph against your actual plan. These could include:

1. Requirement stabilization velocity – Can be tracked by changes that had to be made to the specs over the course of the project.
2. Code velocity
3. Defect Densities (new, closed, re-opened) over the course of a project.
4. Milestone dates planned v/s actuals.
5. Estimation deviations.

Once the trending graphs for these are drawn, the participants can analyze the reasons for +ve and -ve trending. If you have benchmarks for these trend graphs it could be compared to identify potential process improvement areas.

More detailed discussions will follow in later posts in PM 101 series. If you have any areas that you wish to see covered drop a comment.

If you enjoyed this post, make sure you subscribe to my RSS feed!