Learning from Experience

Software projects can derail in many ways. You can avoid making many classic mistakes if you study the many books, articles, and blogs available on software engineering and project management, as well as the lessons your own teams have learned on previous projects. Sure, everyone’s crazy 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 solid foundations for project success.

People have been developing software for more than six decades. During that time, several 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 learn about 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 countless 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. 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 leaders who examine many projects for patterns that correlate with success and failure. Other collections 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.

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 other projects apply to your situation. Sure, all projects have their unique aspects. But there are enough commonalities that you can save 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 to deliver 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, also called a postmortem (even when the patient survived), a post-project review, or a debriefing. These are structured activities in which project participants reflect on the experiences of the previous project, phase, or iteration. Such reflections often 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).

For the maximum organizational leverage, accumulate and share lessons learned from your retrospectives, process assessments, and risk-management experiences. 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 each project that avoids repeating past problems.

I like to write lessons in a neutral style so 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 retrospective or lessons-learned analysis 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 might go into each lesson-learned record. Building a lessons-learned collection is not free. However, it takes far less time to record knowledge than to acquire that knowledge.

Figure 1. Lessons learned template.

Table 1. Lesson Learned Data Field Descriptions

Following are a few simple examples of the kinds of lessons you might learn on a project. Grow your own set 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 each time around.

• Requirements 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 to resolve ambiguities and answer questions.

• It will take twice as long for new team members to get up to speed and become fully productive as you think it will.

• 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.

The exact lessons you learn from each project are less important than the fact that you develop a cultural imperative of continuous improvement based on continuous reflection and learning. That habit will pay off both for you personally and for your team forever.

Author: Karl Wiegers, Principal Consultant at Process Impact

Karl Wiegers is Principal Consultant at Process Impact, a software development consulting and training company in Portland, Oregon. He has a PhD in organic chemistry. Karl is the author of numerous books on software development, most recently Software Requirements, 3rd Edition (with Joy Beatty). He’s also the author of Successful Business Analysis Consulting: Strategies and Tips for Going It Alone, a memoir of life lessons, and a forensic mystery novel, The Reconstruction. You can reach him at ProcessImpact.com or KarlWiegers.com.