Post Mortem
Post MortemAlso known as: AfterActionReport, or Project Review.
Description: A PostMortem is the feedback meeting at the end of a project, or the written report of that meeting. The name comes from the medical term which some people feel gives the practice a negative connotation. But the practice is common in the ComputerGamesIndustry (and others?) where a project is considered "dead" once the game has been approved for publication. A database of game postmortems is available at GamaSutra.
A PostMortem report should be held as soon as possible after the close of the project so that important issues don't get forgotten. It is also possible to hold interim postmortems (PreMortem) which can help your current project as well as your next.
Problems: A problem with a failed software development project post-mortem is that there is usually no clear reason for failure--things apparently just didn't work out. Without clear causes, people tend to analyze the failure according to their individual ideas of how the project "should" have gone. The waterfall proponent will say that no enough attention was paid to analysis and design up front. The QA manager will say that there was not enough documentation. The CM manager will say that there was too much change. The XP guy will say that too much analysis was done, that too much documentation was produced, and that there should have been more frequent iterations. The architect will complain that the designs weren't implemented as specified. The developers will say that they were overworked. The managers will say that the developers didn't focus enough on the most important tasks. The marketing people will say that the development team didn't pay enough attention to their suggestions.
Whoever ends up writing the post-mortem report will conclude that the proper course of action to prevent similar failures is to do whatever it is the author thinks everybody ought to be doing anyway.
Another problem with post-mortems is that the invited people are usually the ones with the least amount of objective perspective on the project. People from other projects aren't invited, but they could share a lot of observations. The HR manager isn't invited, but she could tell you that nobody has taken a vacation in eighteen months (except for the project manager, who took four weeks off), and that sick-day usage has risen steadily over the past few months. The receptionist isn't invited, but she could tell you that nobody ever answered their phones when the customers or support people called. The developers who quit in frustration six months ago aren't consulted. The junior programmer in the cubicle right outside the QA lab probably overheard some interesting information.
Discussion
Another name for an autopsy -- you cut up the dead thing and report on what you find. Often used for an AfterActionReport, but it has rather more unfortunate connotations. It's a good name for the analysis of a dead project that failed for some reason. --RaySchneider
I recently saw a discussion of an idea which could well go under the name of PreMortem. -- LaurentBossavit
I don't have a problem with the name post-mortem. Even successful projects don't live forever - only until they succeed completely. But if you are worried, call it a PostProjectReview or some such.
Where I do have a problem is with the concept that you should wait until after the project - that way you lose half the value. Much better to have MidProjectReview?s.
Either way, how to structure your reviews? Try the following.
Ask three questions of each person and discuss the answers:
PS. Some more suggestions:
The main challenge is to start people talking. Because this is largely an exercise in being critical it's hard to get it started, but once started, it develops its own momentum.
EditText of this page
(last edited March 5, 2004)
or FindPage with title or text search