1. Involve all contributors. If others were involved in your project, arrange a project review meeting. If you were the sole contributor, set aside time to reflect on your experience. Document the good, the bad, and the ugly aspects of the project. Note all grievances, and solicit ideas for future improvement. I recommend using a project review questionnaire with three parts. First, use a one to ten rating system to quantify subjective feedback. Secondly, include targeted questions for specific areas that might need improvement. And finally, use a free form comments section for open-ended feedback.

2. Document the postmortem in writing. Document the postmortem details in writing. While it is perfectly acceptable to create a simple text document for small projects, I recommend using HTML for large projects. The document can then be published on an intranet, so everyone in the company has easy access to it. This way you can provide links to additional resources such as design documents, schedules, and archived files. It also makes it easy to create a collection of postmortems over time, with links between related sections of different documents. For a multi-release product, include additional data on each upgrade. A series of postmortems can ultimately evolve into a valuable record of your hard-earned wisdom.

3. Begin with a project overview. Begin the postmortem document with a brief overview of your project, including a design overview, estimated budget, and project start and finish dates. Describe the product's purpose, intended customer, and other general information.

4. Include project details. Document the quantifiable details of your project. Include your schedule and budget estimates as well as the true outcomes. List the number of lines of source code in the release as well as the lines of reused code. Document the size of the media and system requirements for the end user. List any known bugs or compatibility problems. Note which development tools were used and their version numbers, including any mid-project upgrades. List everyone who worked on the project, and document their contributions.

5. Document what went right. Document what went right with your project. Did the final product turn out better than expected? Did you experience an occasional stroke of luck? List at least ten things that turned out well for your project. For my last project, I had the most luck with quality assurance. I paid tremendous attention to code quality, and I was able to keep the program virtually bug-free throughout its entire development. Consequently, I was able to spend very little time on debugging, allowing me extra time to improve the quality of the product.

Suggestions (cont.)