Do you capture everything?
Is everything a lesson learned?
How do you decide what you need to capture for the closeout?
I asked Mel Bost a Principal Consultant in BOT International’s PMO Practice who specializes in PMO best practices, project lessons learned, and program management those questions in a past podcast, Related Podcast and Transcription: Learning in Project Management.
Mel: That’s a good question. I’m writing this book which is going to be out shortly. In my blog, I talk about this process in capturing and documenting lessons learned. Really, what I’m defining there is what I call significant events. A significant event is something where you may have a major deviation between expected result and actual result. That would probably be easy for a project manager to sit down with his project team and list 50 things that ought to be improved. I say take the top 5 or 10 where you’ve had a significant deviation between expected and actual result. Focus on those 5 or 10, if you’re able to do that, you’ve got the old 80/20 rule. Eighty percent of the value to be gained is probably in the first five or six lessons learned significant events that you identify. The rest of them trail off very quickly, but there can be a lot of things.
If an organization has a robust risk management plan in place, they are 90 percent of the way toward having a lessons learned process. They’ve already defined some potential risks. If those risks get triggered in a project and they have a mitigation plan, they’ve already identified some significant events. The definition of risk and carrying that out for a project, having that risk identified, and if it’s triggered, if it’s significant and you’ve got a mitigation plan, that ought to go right at the top of the list of lessons learned. When you say how do you know, what do you need to capture all the knowledge? I’d say pick the top 5 or 10 lessons learned, something where you had a major deviation between expected and actual result.
Joe: My next question is how do you share that knowledge? How is that shared so that knowledge is made explicit to other people?
Mel: Different organizations have handled that in different ways. Certainly some of the larger organizations, we have, especially the large oil companies have put knowledge management systems into place. Even companies like Schlumberger, which is an oilfield service organization, they were one of the first companies to put together a knowledge management system where they actually go in and put it into a database. Depending on how sophisticated the organization is, I’ve even seen a couple instances in NASA where organizations have developed what they call a knowledge-based risk. In other words, they’re using their knowledge database to inform their risk managers of previous project problems before the initiate a new project. I think it’s up to, once again, the individual organization.
In the case of ConocoPhillips, when I worked there, one of the first things we tried to do was to have a breakfast forum among our project managers and invite some of the project managers who were just completing projects to talk about lessons learned. We videotaped those, and we put them into a SharePoint system, so anybody goes out and look at those. We promoted that to all our project managers, especially those who were going to initiate a new project that was similar to one that had just been completed. Today, we have a project server system out there from Microsoft project that incorporates a lot of that and allows capture of lessons learned.
Lean Sales and Marketing: Learn about using CAP-Do
Special Marketing with Lean Book and Program offers on Facebook