Post Mortem is the feedback meeting at the end of a project or the written report of that meeting. 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. Sometimes you may think you've completed a software project, but you aren't truly finished until you've conducted a project postmortem. Most shops are far too busy rushing ahead to the next project to spend any time thinking about how they could improve and refine their software development process. And then they wonder why their new project suffers from all the same problems as their previous project.
The name comes from the medical term which some people feel gives the practice a negative connotation. But the practice is common in the Computer Games Industry where a project is considered "dead" once the game has been approved for publication. A Post Mortem 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. To make a long story short post mortem is a little discussion after a project or important part of the project. The team discusses what was done well and what was screwed. Before the discussion, one person gets feedback from all team members to bring food for thought. Outcomes are used in future projects.
A postmortem should occur within 1-2 weeks of project completion. However, smaller postmortems can be conducted following the completion of any major milestone during the project cycle. If you conduct the postmortem too soon, people may not be done wrapping up loose ends.
The purpose of a postmortem is to “learn from past experience.” Another purpose is to carefully analyze a project once it has ended and identify what went well and what went poorly so you can do better on subsequent projects. Another purpose of a postmortem is to give closure to a project. The closure issue is important for team members who are breaking away and moving to different projects or to wrap up a particularly long or tough project cycle (sense of completion). The goal of a postmortem is to draw meaningful conclusions to help you learn from your past successes and failures. Despite its grim-sounding name, a postmortem can be an extremely productive method of improving your development practices.
Also, all managers should leave the workshop for at least some of the time. A neutral third party is good. A trusted senior developer will sometimes do. 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.
Good questions to ask in the next postmortem meeting:
- What was the best thing about the project?
- What was the worst thing about the project?
- If you could have changed one thing, what would it have been?
- How well did our toolchain work?
- Which of the documents that we did add value? Which didn't?
- Do we have a project which met all objectives or not?
- What went badly? Do we have disappointed users?
- What went well? Do we have a happy customer?
- Do we have a successful project or not?
- What should be done differently?
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 not enough attention was paid to analysis and design up front. The QA manager will say that there was not enough documentation. Quite often we all know that Bob screwed up something in the project badly, but Bob is the senior person and has been known to take it out on the peons. So the peons learn to keep their mouths shut (i.e., they are now being dishonest to avoid pain). As we’ve been learned by experience above process rarely brings a clear message. He failed. She misunderstood the task. They forgot to agree on something. And even in those rare examples, that kind of knowledge is most likely useless. Yes, this time PM sucked. So what? Are you happy now? We better go back to find the solution, then.
Example of the postmortem meeting process:
- Duration: The postmortem should be anywhere from 2 hours to one entire day.
- Room: The room should contain a round or oval shaped table so that everybody is ‘equal’. Reserve the room at least one week in advance.
- Preparation: Send out the agenda (this checklist/framework) at least one week prior to the date of the postmortem meeting to allow participants preparation time.
- Ask for ideas from all participants.
- Deadline: Request that participants email in their issues (the good, bad, and ugly aspects of the project) at least two days before the meeting. This ensures the agenda creator has ample time to write-up the agenda.
- Focus: Stick to matters related to the process. Stick to the issues and not attribute blame. If a topic goes on and on for over 7-10 minutes, then stop it and proceed onward.
- Time Limits: Keep each topic limited to about five minutes.
- Facilitator: There should be a neutral person facilitating the postmortem to ensure that participants stay on focused, do not argue, etc.
- Recorder: Somebody should be selected as the note-taker for the postmortem meeting. The entire purpose behind the postmortem meeting is to learn how to improve the processes. As such, the facilitator is often an excellent candidate for recording the group’s discussion. It is recommended that the recorder use a large flip-chart on which to take notes. This will focus the discussion on a topic by topic basis, rather than individual vs. individual.
- Writer: Somebody should be selected to compile the notes, and write up a Recommendation Report summarizing the key points derived from the postmortem meeting. Email out this report within one week following the meeting.
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. To summarize, make your post-mortem successful by carefully preparing in advance, analyzing the project systematically, producing actionable findings, and actively sharing the results.
I've just seen that having separate meetings with the devs, the business owners, the testers, the project manager(s), etc. reveals dramatically more candid tellings of the story of the project than the typical approach of getting everyone together. On several of my last projects, I would love to have seen a neutral person go through those meetings and compile a report, "independent counsel" style. I suspect that the result would be FAR more informative and would work better for fixing the problems.
Example of issues and problems on the project:
- No updates in the documentation. Even basic software workflow is not covered completely with all steps.
- Bad collaboration between different time zones.
- No replies for some emails with issues for a long tie. No updates on paper or emails.
- Strange explanations of why issue exist in the system, for example: try to click in some other control, try to wait 6 seconds, we should clear cache etc.
- Requirement changes on the fly, in the call or meetings, but not in emails to all team members or specification.
- Bad process of work. Development -> Testing -> Fixes -> Regression -> Development.
- No collaboration between testers and developers (meetings with all team members is not counting).
- Gold plating features - http://en.wikipedia.org/wiki/Gold_plating_(software_engineering)
- Developers are not testing their code. Even happy path was not tested completely for most of the features.
- Lack of resources.
Post-mortem meetings are seemingly more important in these days of rapid process change brought about by new methods such as Agile and Rapid development. Post-mortem meetings also present a dilemma. They are clearly necessary so that an organization may identify what they are doing right, as well as what needs improvement. The challenge is to conduct them in such a fashion that they do not negatively impact team dynamics and morale. Post-mortem meetings need to be viewed not as a necessary evil, but as a positive growth experience for the organization and the individuals involved.
I generally respect most things out of the Pragmatic Programmers, and this one's no exception. If you reflect on your project more often, and the team has more of a stake in the way they operate, then the project has a better chance of success. See how to mine the experience of your software development team continually throughout the life of the project. The tools and recipes in this book will help you uncover and solve hidden (and not-so-hidden) problems with your technology, your methodology, and those difficult “people issues” on your team. But traditionally, retrospectives (also known as “post-mortems”) are only held at the end of the project—too late to help. You need agile retrospectives that are iterative and incremental. You need to accurately find and fix problems to help the team today.
Post mortem or retrospective best practice examples:
- Design and run effective retrospectives (post mortem).
- Learn how to find and fix problems before they occur.
- Find and reinforce team strengths on each iteration.
- Address people issues as well as technological as early as possible.
- Use tools and recipes proved in the real world.
References
Summary
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 Mid Project Reviews. Definitely when a project is finished. But when you run a project which lasts three quarters you won’t remember all the issues you had to resolve during the first phases after all. Then it’s quite a good idea to run post mortems after each important milestone. The difference between average programmers and excellent developers is not a matter of knowing the latest language or buzzword-laden technique. Rather, it can boil down to something as simple as not making the same mistakes over and over again. Fortunately, there's a powerful tool that any developer can use to help learn from the past: the project postmortem. Don't make the mistake of omitting the project postmortem from your project. If you don't conduct project postmortems, then how can you possibly know what you're doing right-- and more importantly, how to avoid making the same exact mistakes on your next project? Working for yourself is very rewarding in many ways, including sometimes even financially.
