Documenting Lessons Learned

Posted by Brad Egeland

It is my belief that the act of conducting and documenting a Lessons Learned session with your team and your customer is critical and one of the least utilized tools of the project management trade. Seriously…the project is basically deployed and you’re ready to move on to other things. One of the last things on your mind is to examine the good and the mostly bad things that went on during the project.

However, when utilized, this can be very helpful and critical information both for you as a PM on your future projects and for your organization. It can also be very helpful for your customer and your own tech support in post-deployment support situations.

Carl Pritchard outlines his version of a Lessons Learned report below from his book “The Project Management Communications Toolkit.” Again, by including it here, I do not necessarily agree with everything stated, but I think as PMs it’s important for us to understand the various ways to handle such activities because what works in one industry or for one customer or project may not work for another.

The Lessons Learned Report


Lessons learned are used at midpoints of the project and at project completion to catalog significant new understandings that have evolved as a result of the project. They are used to build the knowledge base of an organization and to establish a history of best and worst practices in project implementation and customer relations.


Lessons learned should be applied across the organization to facilitate consistency. They should be used and reused as new projects evolve with concerns similar to those addressed by the original lesson learned.


Lessons learned include detailed, specific information about behaviors, attitudes, approaches, forms, resources, or protocols that work to the benefit or detriment of projects. They are crafted in such a way that those who read them will have a clear sense of the context of the lesson learned, how and why it was derived, and how, why, and when it is appropriate for use in other projects. Lessons learned represent both the mistakes made on projects and the newer “tricks of the trade” identified during a project effort.

The content of a lesson learned report should be provided in context, in detail, and with clarity on where and how it may be implemented effectively. Because lessons learned are often maintained in a corporate database, the lesson learned documentation will frequently include searchable keywords appropriate to the project and the lesson.


Although forms, databases, and simple documentation are the norm for documenting lessons learned, the approaches to cataloging the information can vary widely. Some organizations capture lessons learned in on-line cartoons and captioned scenarios. Others post lessons learned in hallways and project war rooms. Most capture lessons learned in simple document files or databases. The storage medium is not nearly as important as ensuring that the content includes detailed, in-context information about why the lesson was deemed important enough to store and what specific action can be taken to implement the lesson on future projects.


Storing lessons learned information is one critical consideration, but equally important is the establishment of protocols to ensure access to the information on a consistent basis. Lessons learned may be captured and logged in depth, but if they are not accessed by project managers in the future, they do not serve any real function. Access may be encouraged through creative documentation approaches (like cartoons), physical location (hallways and project war rooms), or by including the mandate to access lessons learned as a key component of the performance criteria for project managers and team members.

Tags: , , , , , , , , , , , , , , ,

One Comment to “Documenting Lessons Learned”

Post comment