Projects can derail in many ways. You can avoid making many classic mistakes if you study the literature available on both project management and technical work in your field, as well as the lessons your own teams have learned on previous projects. Sure, everyone’s very busy when you’re launching a new project, and taking the time to study existing bodies of knowledge doesn’t seem like real work. However, examining the lessons of the past is a high-yield investment in your own future.
An overconfident project manager, in contrast, will rely solely on personal experience, memories, and the team members’ intelligence and experience to weather any crisis and master any challenge. Hubris is not a solid technical foundation for project success.
Take software projects, for example. People have been creating software for more than sixty years. During that time, various development and management techniques have emerged as strong contributors to project success. These are known as best practices. It behooves all project managers, business analysts, and other professionals to become familiar with the established best practices in their domain. Selectively applying appropriate industry and local best practices is a way to benefit from the lessons learned on thousands of previous projects.
Some people don’t like the term “best practices.” They protest that it implies a global or absolute standard of excellence. Certainly, practices are context-dependent. Few techniques can be stated universally to be superior — or even appropriate — in every situation. In fact, I normally say “good practices” instead of “best practices.” Nonetheless, there are indeed patterns of practices and techniques that consistently give better results than do others, when thoughtfully applied in appropriate situations.
Watch out for the trap of mindlessly following an approach that someone dubbed a “best practice” without considering whether it applies to the culture, technology, size, and nature of your project and organization. However, you ignore the collected wisdom of those who have gone before at your peril. Don’t assume that your project (or team, or product, or organization) is so different that none of the insights from previous projects apply. Sure, all projects have their unique aspects. But there are enough commonalities that you can save a lot of time — and anguish — by applying the lessons that others have accumulated.
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. Cancelled projects and those that struggled can provide many lessons that can save your team grief on the next project — if you take the time to glean and apply them.
The most effective way to reap this harvest of knowledge is through a retrospective, as described in my article “Project Retrospectives: Looking Back to Look Ahead.” A retrospective is a structured activity during which 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 can reveal effective solutions to common problems and actions you should strive to repeat in the future. Two excellent resources about how to perform retrospectives are Norman L. Kerth’s classic book Project Retrospectives and Agile Retrospectives by Esther Derby and Diana Larsen.
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, from process assessments, and from your experiences in managing project risks. Organize the lessons-learned repository to make it easy for future project managers and practitioners 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 style. That way it isn’t obvious whether we learned each one because we did something brilliant or because we made a silly mistake. The knowledge itself is more important than how we acquired it. Be sure not to use a lessons-learned analysis (or a retrospective) to try to pin blame on anyone for why a project didn’t turn out quite right. You can be sure that no one will willingly participate in a blamefest in the future.
The template in Figure 1 provides a simple structure for collecting lessons from multiple projects within your organization. Table 1 describes some information that could go into each lesson-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 1 will get you started.
Following are just a few simple examples of lessons you might learn on a project:
- It could take twice as long as you think for new team members to become fully productive.
- Requirements that are going to be outsourced for implementation must be more detailed and clearly written than those that will be implemented locally, as you’ll have fewer opportunities for informal interactions to resolve ambiguities and provide details.
- Peer reviewers need to be trained before you can expect them to be highly effective at finding defects and to participate constructively in a positive review experience.
- Plan more time than usual for review cycles when the review participants are geographically separated.
You might or might not arrive at these same conclusions when you reflect on your own organization’s project experiences. The exact lessons you learn from each project are less important than the fact that you develop a cultural imperative in the organization of continuous improvement based on continuous reflection and learning. That habit will pay off both for you personally and for your team forever.
Grow your own list of lessons and pass that wisdom 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.
If you’re interested in software requirements, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources.