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.
Number of views (2507)
*The views, opinions and positions expressed within these posts are those of the author alone and do not represent those of Seavus Group.
We accept no liability for any errors, omissions or representations.
The copyright of this content belongs to the Seavus Group and any liability with regards to infringement of intellectual property rights remains with them.
10/30/2009 9:06 AM
Thank you for this post. At this link http://www.gedpro.com/en/Community/Templates.aspx you can download a template to document the lessons learned for free (Project Closure Template).
If you are interested in conveying your message to your target market, please contact us at firstname.lastname@example.org!
Share you project management knowledge and expertise with the hundreds of thousands readers of PMTips.net. Apply here!