In theory, capturing lessons learned at the end of a project sounds like a great idea. Who wouldn’t want to reflect on what was done right, what could be done better, and then apply those lessons to the next project? In practice, though, it is sometimes a different story. It may be a lack of time, resources, interest, or follow-through that causes lessons learned to fall by the wayside. Or, even if they are captured they may not necessarily be implemented. So what makes successful application of lessons learned possible?

Probably the most important factor to me is accessibility. Actually capturing lessons learned is relatively easy (as long as it’s embraced by project and team leadership). Problems, issues, ideas are still fresh in people’s minds so voicing them is not the problem. Management needs to recognize this and embrace the idea that some time needs to be invested in capturing lessons learned — and not just at the end of the project, but throughout its lifecycle. In my experience, this is pretty easy to achieve.

It’s returning to the information and using it in the future where most organizations fail to follow through. 

Having a system in place that makes sure the lessons learned knowledge base is consulted and used in the future is critical. My favorite approach is a well structured, collaborative, wiki-like system. For example, Atlassian’s Confluence has proven great in the past. It offers an open information repository that anyone can contribute to. It’s rich in terms of media integration, and it has version control and sufficient security to ensure that nothing gets lost. 

But most important, the system needs to provide a ready reference library. That means an excellent search capability and well thought out keyword or classification systems. Project managers and leads need to know they can consult the knowledge base, quickly find relevant lessons learned, and apply them to their current project. 

This also means capturing a lot of information. The tool is only useful if it really has a significant knowledge base. Lessons learned need to encompass the positive as well as the negative. Project performance statistics need to be in there. Specific development problems and solutions. Having a cross-reference to your support system or ticketing system is a great idea, because the team can look up generalities and then link directly to hands-on end results from past projects. 

Building the right kind of system is critical. Think about building a reference library. What does it take to feed the library, and what does it take to make it easy to access?

Related posts:

1. Fix your boss (or, reduce risk to quality using a matrix approach)
2. Tackling the global project problem, part 2
3. Tackling the global project problem
4. Managing with blinders on
5. The good (and bad) about Project Management School