| As software projects progress, many decisions are made and activities conducted that use the information available at the time. These decisions and activities are conducted in the project's best interests. Given the context of time and the project's progression, you can determine, in retrospect, whether the decisions made were the right ones. Where does this information come from? Consider the following sources: The project risk list. The Rational Unified Process emphasizes the importance of risk management. If the project actively managed its risks, there should be a list of risks, along with the information gathered to explain the risks. A risk mitigation plan also should be available. The data obtained through the execution of the various disciplines employed on the project. A review of the Requirements Management, Configuration and Change Management, Testing, Project Management, and so on can help identify lessons learned for subsequent projects. If your project uses automated tools for these disciplines, you may be able to capture metrics during and after the project to spot trends and trouble spots. You'll read more about this later in the chapter. Analysis of the role of consultants. Were any consultants used on the project? Were the results satisfactory? Interviews and discussions with team members. Speak to members of the project team after their role on the team has concluded. Candid discussions with team members after the stress of the project is over can yield some useful insight. The proposal. Review the proposal that was developed when the team was bidding on the project. What assumptions were made in the original proposal? Which assumptions held true, and which ones did not? Should any assumptions have been added? Were any clues overlooked that could have foretold the challenges that were encountered? Original estimates. Review the estimates produced for the proposal for bidding on the project. How close did the estimates come to the actual amounts?
Much of the data useful to the study of a project after its conclusion can be collected during the project. A suggested practice is to publish selected data in a public area, such as near printers or break rooms. This helps keep project personnel informed of the project's status. Note that the primary purpose of the project postmortem is to help the organization make subsequent projects more successful. Much of the information described here may come too late to help you effectively manage the current project. Instead, use the lessons learned from each iteration to guide the current project from iteration to iteration. |
