Page 194 -

Postmortem Reports

After the project is done, there is a lot of important information out in the organization
that can help a project manager run future projects better. There is a brief period after the
software is released to the users when everyone is done with the tasks, but when they still
have a lot of strong opinions and remember specific details about how the project went. If
this information is documented in a way that can be used to help in the future, it will be a
valuable resource for the organization.
A postmortem report is an overall account of the team’s experience in building the software,
and of the experience of the users and stakeholders in working with the team. The report
should contain an honest assessment of how the team members, users, and stakeholders
perceived the end product and assessed the decisions made throughout the project. The
purpose of the postmortem report is to highlight the team’s successes and identify any
problems that should be fixed in future releases.

Often, a project manager will gather the project team together with anyone who had any-
thing to do with the software project into a large meeting so they can talk about the
project. This is rarely effective—it just turns into a big, useless meeting (see Chapter 5). In
the same way that people are uncomfortable criticizing each others’ work or taking that
criticism for individual work products, they can be equally uncomfortable doing it for the
entire project. This is especially true when it comes to taking criticism about the project
from people outside of the team.

A much more effective way to gather this information is to rely on the quality assurance
team members, who have expertise gathering and objectively reporting both positive and
negative information about the project. In the same way that they assess the health of a sin-
gle build and write a report that describes it, they can assess the health of the entire project
and write a postmortem report that describes the results of that assessment. The project
manager can then gather the team, users, and stakeholders together to review the results.

One effective way to gather information for the postmortem report is to use a survey. It is
important that this survey covers every phase of software development, so that nobody is
left out or singled out. The survey should be constructed so that participants can respond

anonymously. Respondents should be asked for both a numeric rating and for their
thoughts and comments. Table 8-7 shows some typical questions that might appear on a
postmortem survey.

186 CHAPTER EIGHT