Project management lessons learned shouldn't be limited to postmortems

Lessons-learned session items are team-, project-, or technology-specific

Every project has its own unique web of problems, making general solutions very rare indeed.

The majority of the items that come up in a lessons-learned session relate only to the project just completed. The same team, however, will not be on the next project; the issues related to a specific project will not be the same on the next project; and the technology will be different on the next project. As a result, any team-, project- or technology-specific items are not useful in a lessons-learned context. 

Lesson-learned sessions are held at the end of the project

Traditional lessons learned are held when the project is complete, presumably so that the team does not make these same mistakes on future projects. The problem with this approach is most people can't remember what happened two weeks ago, much less what happened six months or two years ago. Trying to dredge up useful lessons learned months or years ago is nearly impossible. Additionally, as noted above, if the lessons learned are specific to a completed project, there is nothing to do with the information: No one can learn from it, and nothing can be done with the information to improve future projects. Two strikes on this one.

If items are not team-, project- or technology-specific, they are so vague as to be useless

In order to deal with the first two issues, people will often generalize the information to make it universally applicable to future projects. If we attempt to generalize the lessons learned to make them applicable to other projects, they often become ridiculously generic. I hear things like "Communication was a problem," "Stakeholders should be more involved," and "Budgets should have been more controlled." While these statements may be true, they are useless because they do not identify the root cause and make no recommendation of corrective action. How could they? Nearly every real problem that could or should be addressed to improve production is a tangled web of interdependent team-, project- and technology-specific issues that together create a problem. Every project has its own unique web of problems, making general solutions very rare indeed.

What can be learned from a Lean or Agile approach?

There are fundamental differences between traditional project management lessons learned and the Lean or Agile approach, specifically in how, when and why lessons-learned sessions are done. Traditional lessons-learned sessions are done so that future projects do not encounter the same mistakes made on the past project. Lean and Agile project lessons-learned sessions (typically called retrospective or kaizen events) are intended to make immediate improvements on the current project. Call them what you like, but they are frequently held events to improve the process of the current project by taking small steps over time.

Changing the purpose and frequency of the lessons-learned sessions resolves the three issues that plague the traditional project lessons-learned approach. Let's look at the impact this Lean or Agile approach has on the problems of a typical project lessons-learned approach.

Lessons-learned sessions are team-, project- or technology-specific

The problems identified are still specific to the team, project or technology, but that is OK because the team, project and technology are currently in flight. The team involved in the retrospective or kaizen has the knowledge and context to do something about the items or problems identified. 

Lesson-learned sessions are held at the end of the project

Lean or Agile sessions are not held at the end of the project. Instead, they are held every two to four weeks throughout the project. This results in three key outcomes:

• It is much easier to remember what went well and what needed improvement. It is also much easier to make changes over a short time period than a long one.
• The sessions are held mid-project so the team that identified the items can act upon them in the context in which they have relevance. 
• Because another session will be held in a couple of weeks, the team is able to inspect the results of the actions they took to rectify a problem and adopt a new solution if the last one didn't fix the problem. 

If items are not team-, project- or technology-specific, they are so vague as to be useless

In a retrospective or kaizen event, items are not generalized. The meeting is not over until the problems, root causes and solutions are made very clear and are given specific actions that are planned into the project to improve the working of the group. Finally, they are checked at the next retrospective or kaizen to see if the action was taken and if it had the intended results.

Even if their project is managed with a traditional approach, anyone can improve their team's ability to deliver by learning how Lean and Agile teams conduct lessons-learned sessions. 

To learn more about how to facilitate a retrospective or kaizen event check out the blog at www.whitewaterprojects.com. 

Joseph Flahiff is president and CEO at Whitewater Projects Inc., a firm that provides Agile project training and consulting services to enterprise organizations. Before establishing Whitewater Projects, Flahiff worked for a multi-state health insurance company, providing Agile project management and training for a three-year $20 million project that coordinated the work of more than 100 team members.