How many times have we all wished we could take a mulligan, to borrow the popular golfing term – on an action or decision we made on a project? I know I have on more than one occasion. The goal is to always learn from our mistakes so that we aren’t destined to repeat them. There are certain issues that arose on past projects that I will never forget and would do things differently in the future to ensure they didn’t happen again. But what about others? How can others benefit from issues that we encountered? That’s where the formalized concept of documenting ‘Lessons Learned’ comes in to play.
I discussed this to some degree in the methodology article Project Phase 8 – Post-Deployment. A good Project Manager should be documenting potential Lessons Learned throughout the project, but at the very least many things that are included throughout the engagement on the issues and risks lists will eventually be discussed during a more formal Lessons Learned review.
As previously discussed, there are three main benefits specific to the project and the project team members of going through a formal Lessons Learned review process. These are:
One additional, long-term benefit that can greatly help future project teams and customers is documenting the Lessons Learned and making the formal documentation available on a company Sharepoint or Wiki-type knowledge database library.
The Review Process
Following Project Phase 7 – Deployment, and during Phase 8 Post-Deployment, reconnect with the customer to go through one or more formal meetings to discuss the issues Lessons Learned. This activity is led by the Project Manager and should include all project team members on both the delivery team side and the customer team side.
Below are two links to examples of documents that can be used to aid in the Lessons Learned process. The first link is a Microsoft template that outlines questions that need to be answered during the Lessons Learned formal review process. Out of these questions will come the formal list of Lessons Learned and the likely proper course of action that should have been taken in hindsight. The second link is to a Lessons Learned checklist from the State of Vermont site. This more or less helps identify whether or not all the bases were covered during the engagement.
I think they’re both useful, but I tend to use something more like the MS template in conjunction with the project issues and risks lists to come up with an overall list of Lessons Learned for the project which identifies impact, outcome, how it may be mitigated in the future, etc.
Number of views (3853)
????? ?????? ????? ????? » Blog Ar
3/10/2009 10:46 AM
[...] Lessons Learned [...]
Transferring Lessons Learned to Others |
9/11/2009 7:40 AM
[...] in February 2009 I wrote an article entitled “Lessons Learned” which discussed how and when to conduct Lessons Learned sessions, how to document them and what [...]
More on Lessons Learned | Project Manage
10/10/2009 7:36 PM
[...] my thoughts on Lessons Learned previously including an article from February 2009 titled simply “Lessons Learned.” Here, I present some further thoughts on lessons during the project implementation process from [...]
Project Management Templates | Project M
11/27/2009 9:13 PM
Expert Program Management
5/28/2010 3:05 PM
You might want to check out a post I've just written about how to run the Lessons Learnt meeting itself:
5/20/2011 9:05 PM
Does anyone know of or use a good Lessons Learned Datatbase.. Im a engineering intern and one of the projects i was assigned was implementing a system.. All help appreciated....
1/26/2012 3:29 PM
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!