Avoid the Same Old Mistakes by Focussing on Lessons Learned

It’s said there are no new project management sins, just old ones repeated. It’s also said that we don’t learn the lessons from past projects, and this must be true, otherwise, why would we keep making the same old mistakes?

There are two common problems preventing us from learning valuable lessons from past projects:

• We think the lessons don’t apply to us
• We want to get things done

The sad truth is that these lessons learned are useful. That time spent doing the work better is time well spent. Getting it right the first time is cheaper and easier than doing it now and fixing it later.

So if we accept that lessons from past projects are helpful and can prevent problems later down the line; how can organisations create a lessons-learned culture where people not only take the trouble to learn from past projects but want to learn? A culture where we apply best practices and discard bad ones.

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 program or 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.

Best Practices

Take CTRM and ERP 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 behoves 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 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 organisation. 

Ignore the collected wisdom of those who have gone before at your peril. Don’t assume that your project (or team, or product, or organisation) is so different that none of the insights from previous projects applies. Sure, all projects have their unique aspects. But there are enough commonalities to save a lot of time — and anguish — by using 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 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. 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. 

Don’t expect all project managers and team members to read the complete report from every retrospective and draw their own conclusions. For maximum organisational leverage, accumulate and share lessons learned from your retrospectives, from process assessments, and from your experiences in managing project risks. Organise 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 blame fest in the future.

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 participating 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 organisation’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 organisation 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 to anyone who might benefit from your 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.