Posted by Brad Egeland
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:
- Provide the delivery team with good feedback and useful info for future engagements
- Document project-specific issues that may be relevant to tech support after hand-off
- Increase customer satisfaction and provide the customer with useful project information as they move into the post-implementation support mode
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.
Once the project moves into the Post-Deployment phase, it’s a good idea to bring Tech Support up to speed on the issues from the project and a good way to do that is with the Lessons Learned documentation. Sharing Lessons Learned in a central knowledge database like a Sharepoint or Wiki database is a great idea and can help ensure that future projects use corrective action early enough to avoid the pitfalls that occurred on your project.
Tags: customer, delivery, deployment, engagement, Goals, identify, information, issues, knowledge, learned, lessons, management, manager, managment, meetings, Methodology, mitigation, need, process, project, review, Risk, sharepoint, team, wiki, your