Product Development & Management

Learning from Experience

By |

Software projects can derail in many ways. You can avoid making many classic mistakes if you study the many books and articles available on software engineering and project management, 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, “doing nothing” while you examine 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, arrogance, and cockiness aren’t a solid foundation for project success.

Best Practices

People have been developing software for more than fifty years. During that time, a number of software 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 practitioners 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 care for 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 in every situation. In fact, I prefer the term “good practices” to “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.

Some best practices are collected by industry gurus and consultants who examine many projects for patterns that correlate with success and failure. Other collections of best practices come from authors who glean and synthesize insights from the vast body of software engineering literature. One such author is Steve McConnell, whose classic book Rapid Development (Microsoft Press, 1996) describes thirty-five software best practices. McConnell presents the potential benefits from each practice, the effects on project schedule and risk, improvement in progress visibility, and the chances of both initial and long-term success. He also describes how to apply each best practice and the risks associated with each one.

You do need to 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 learnings from other projects apply to your situation. 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.

Lessons Learned

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 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 retrospective. A retrospective is a structured activity in 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 are even more valuable, identifying effective solutions to common problems and suggesting actions to repeat on future projects. Two excellent resources for performing retrospectives are Norman L. Kerth’s classic Project Retrospectives (Dorset House Publishing, 2001) and Agile Retrospectives by Esther Derby and Diana Larsen (The Pragmatic Bookshelf, 2006).

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 appraisals, and from your experiences in identifying and 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 brilliantly or because we made a foolish mistake. The knowledge itself is more important than how we acquired the knowledge. Don’t use a lessons-learned analysis to try to blame anyone for why a project didn’t turn out the way you hoped.

The template in Figure 1 provides a simple structure for collecting lessons from multiple projects within your organization. Table 1 describes the information that should 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.

Figure 1. Lessons learned template.

ID Date Project Description Activity Contact Recommendations

Table 1. Lesson 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, 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.

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.

  • 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 you’ll have fewer opportunities for informal interactions to resolve ambiguities and answer questions.
  • 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.
  • 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.

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.  Karl Wiegers is an independent consultant and not an employee of Jama.  He can be reached at http://www.processimpact.com.  Enjoy these free requirements management resources.

Latest posts by Karl Wiegers (see all)