In addition to published reports of best practices, we all have our own collections of lessons learned from our personal experiences or those of our colleagues. Canceled projects or those that struggled to deliver a product provide a rich source of insights that can save your team grief on the next project—if you take the time to glean and apply those lessons. The most effective way to reap this harvest of knowledge is through a project retrospective. (See Chapter 15.) During a retrospective, project participants reflect on the experiences of the previous project, phase, or iteration. Some of these reflections will lead to lessons regarding different approaches to try the next time around. Successful projects are even more valuable, identifying effective solutions to common problems and suggesting actions to repeat on future projects.
Don’t expect all project managers and team members to read the complete report from every retrospective and draw their own conclusions. For the maximum organizational leverage, accumulate and share lessons learned from your retrospectives, process appraisals, and risk-management experiences. Organize the lessons-learned repository to make it easy for future project managers to find what they’re looking for. The time you spend accumulating lessons and studying that collection will be amply repaid on every project that finds effective shortcuts and avoids repeating past problems.
I like to write lessons in a neutral way. That way it isn’t obvious whether we learned each one because we did something brilliantly or because we made a foolish mistake. The knowledge itself is more important than how we acquired the knowledge.
The template in Figure 14-1 provides a structure for collecting lessons from multiple projects within your organization. Table 14-3 describes the information that should go into each lessons-learned record. Accumulating insights from multiple projects in a structure like this (or, even better, in a searchable database) facilitates sharing these lessons across all projects and teams. Building a lessons-learned collection is not free. However, it takes far less time to record knowledge than to acquire that knowledge. You can always add more information to the repository, such as searchable keywords, but the information in Table 14-2 will get you started. NASA has made a public lessons-learned database available at http://www.nasa.gov/offices/oce/llis/home/. There you can see an alternative style for documenting lessons learned and read some actual lessons from the space program.
Following are a few simple examples of lessons you might learn on a project. Grow your own list of lessons and pass them along to anyone who might benefit from your own experience. And be sure to refresh your own memory when you dive into the next project. You don’t have time to relearn these lessons the hard way on every project.
Inspectors need to be trained before you can expect them to be highly effective at finding defects and to participate constructively in a positive inspection experience.
It will take twice as long for new team members to get up to speed and become fully productive as you think it will.
Requirements specifications that are going to be outsourced for implementation must be more detailed and clearly written than those that will be implemented locally because there are fewer opportunities for informal interactions to resolve ambiguities and answer questions.
Plan more time than usual for review cycles when the review participants are geographically separated.
Table 14-3. Lessons Learned Data Field Descriptions
Column | Description |
|---|---|
ID | A unique identifier for each lesson. This could be a simple sequence number but a more meaningful label or tag is better. |
Date | The date the lesson was entered into the repository. |
Project | The name of the project that contributed this lesson. |
Description | Description of the lesson learned, including the risks of ignoring the lesson. |
Activity | The project life cycle activity, work product, or other subject category to which this lesson applies. Some possible choices are: Concept Proposal, Requirements, Architecture, Prototyping, Hardware, Design, Construction, Unit Testing, Integration, System Testing, User Acceptance Testing, Certification, Installation, Maintenance, Process, Planning, Estimation, Tracking, and Management. |
Contact | The name of a person the reader could contact to learn more about this lesson. |
Recommendations | Suggestions for implementing the lesson on a future project or for taking process improvement actions based on the lesson. |