Why Bother with a Project Postmortem?

As just discussed, you can draw upon many sources of useful information from completed projects. Taking the time to distill the lessons learned from each project experience is worthwhile. Examining past performance, extracting lessons learned, and incorporating them back into the processes the organization uses are basic tenets of continuous improvement. Yet, many organizations do not take the time to do this. As work on a project winds down, the participants are eager to move to the next project. As a result, the people with the knowledge needed to record the project's experiences may no longer be available. At best, the information may be passed on, but only by word of mouth. Documenting this information is a better way to distribute these best practices uniformly across the organization. Accordingly, an organization's management must encourage this activity if they want the organization to improve. Why bother? Consider the following motivations:

• Project staff members come and go, but the organization's capabilities and understanding should be cumulative. Another way of putting this is that each member of a project team learns how to conduct (or how not to conduct) a project. A fact of life in any business is that these team members eventually move on to other activities. They change positions, get promoted, or join other companies. You do not want valuable information on lessons learned to walk out the door or, worse yet, walk through your competitors' doors. Instead, the information should be preserved and made available for future team members to review and understand.

• Project teams do not remain intact from project to project. As each new project begins, new people will be on the project who were not involved in previous projects. Without access to the lessons learned, they may repeat the same mistakes made in earlier projects.

• As the software services market evolves, organizations will continue to be squeezed to produce higher-quality software at a lower cost. Examining previous projects is one important aspect of a continuous-improvement program to enable the organization to remain competitive.

• If the contracting organization can retain artifacts created on a project, they can be harvested and cleansed for use on future projects. This way, future project teams do not have to start from scratch.

• Applying lessons learned to the software project estimation process used during proposal development provides a couple benefits. First, it helps the organization avoid projects that are destined to be unprofitable. Second, by honing the estimation process to be both precise and accurate, the organization can price a bid more aggressively. When the organization has confidence in its estimation and costing abilities, it has less need for a "padding factor" to add to the cost if it has underestimated the work. This allows the organization to be more competitive.

This last item, concerning the software estimation process, may seem to contradict earlier statements in this book. Given the creative and uncertain nature of software projects, it is still not possible to accurately estimate the cost and time needed to complete a software project in the beginning stages. Yet, as the development organization becomes more fluent and comfortable with an iterative development process, it will recognize how the estimation process becomes easier and more accurate after some iterations are completed. The most difficult aspect is explaining to and convincing the client why it is not possible to give a complete, accurate, and precise estimate before the work begins. In the past, the client has probably used contractors who provided these estimates up front. As a result, clients are not easily convinced that this cannot be done reliably. Clients often explain that they must have this information to plan their expenditures in advance. This is a valid issue. This is where the concept of staged contracts is useful (as explained in Chapter 3, "Getting Started: Request for Proposals (RFPs), Proposals, and Contracts"). Figure 15-2 illustrates this. Most early estimates are unreliable and unrealistic. This is partly because the estimates are produced without a good understanding of the system to be built. It's also partly because of wishful thinking, competitive pressure, and the human tendency to overestimate the ability to build a complex product from scratch. It is far better to estimate during or near the conclusion of the Elaboration phase. By the end of the Elaboration phase, information useful to the estimation process can assist with developing the estimate, yet competitive pressure still exists to balance the estimation effort. The amounts shown in Figure 15-2 are not meant to be exact. In other words, estimating the remaining effort at the end of Elaboration doesn't guarantee an accuracy of plus or minus 30%, as the figure implies. You may be able to do considerably better (or worse, depending on your estimation skills!). It is helpful to create a chart similar to Figure 15-2 and populate it with the results of periodic estimates taken during each project's duration. This will help you understand and refine the team's ability to estimate.

Figure 15-2. Accuracy of project estimates over time

Derived from Agile & Iterative Development: A Manager's Guide. Used with permission.