Mel BostHead Project Closeout and Lessons Learned Advisory Services Practice| BOT InternationalCave Creek, Az, United States
In my experiennce advising PMOs about capturing, documenting and sharing project lessons learned, I caution project managers about trying to document too many lessons learned for a project. Only the high priority lessons leanred that can be converted to process improvements for the project process shoold be addressed. Othewise, resources are wasted which could be better employed elsewhere. If a Significant Event in a project is truly a Lesson Learned, then the process improvement which results will improve the processes markedly. There is no need to keep a tally of the number of times a certain lesson is documented. Saving Changes...
I just keep a log in a shared folder which project team members can access - however I do find that people require a lot of encouragement to complete this, it's best to mention it at project meetings from time to time. Saving Changes...
This is a topic I get into when doing assessments of company capabilities. Many companies are proud of their LLL and all the information they have captured. I turn this around and tell them this is a great opportunity for process improvement. If they were to take 1-2 of these lessons learned and FIX the issue so it never appears again, their whole enterprise would benefit. Lessons Learned should equal areas for improvement and the company shouldn't keep a library other than to use it as an update to their process. Saving Changes...
cyndi mcalpineProject Manager| switchbox incColumbus, Oh, United States
I agree, it's not of any value, actually provides more frustration to gather lessons learned and not take any action on them! Heard a great idea recently at a conference whereby after gathering Lessons Learned, allow the team to do the following:
1. Group or categorize the lessons (if possible)
2. Use a multi-vote process for each team member to vote (up to 5 times on same or different categories) what they believe warrants the most attention (could be one that creates the most frustration, one that would, when resolved, create the most value, whatever).
3. Work to resolve that one issue Saving Changes...
Wai Mun KooPMO Director| Intergraph PP&MSingapore, Singapore
Thanks for all your awesome ideas and suggestions especially those from Mel. The idea that John mentioned on using LLL for the start of process improvement is also refreshing.
The reason I raised this question is I was inspired by the Museum of Failed Products, Michigan (part of GfK Custom Research, North America). I was thinking that if we could have a public repository of failed projects that anyone can contribute and share with the rest of the people who are in the field or interested to learn more in project management by studying what had gone wrong. I believe it would be a trove of treasure for the PM community.
Anyone interested in this? Let me know. Perhaps we can put our efforts together and see if we are able to create something useful for the community. Saving Changes...
Don KimPROJECT-TO-PORTFOLIO MANAGEMENT EXPERT| Seeking opportunitiesSacramento, CA, United States
At least for the major projects (project with budgets $1M or more) I manage for my PMO, I keep a SharePoint site for each of them. We upgraded recently to version 2007 and find using the wiki web part very useful for documenting lessons learned. This allows the content to be dynamic and for team members to add, revise and/or comment.
Wai Mun:
You could set something like this up for free using Google sites at http://sites.google.com Saving Changes...
Wai Mun KooPMO Director| Intergraph PP&MSingapore, Singapore
Don,
Thanks for the link. I will take a look at it. I also agree with you that wiki will be extremely useful for this purpose. My key challenge now is to come up with an ontological set of meta fields to be used to describe each of the entries so that it will help in searching, cataloging and data analysis.
@Don & Mel: Do you have something to share on this? Saving Changes...
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Wai Mun - great post and replies. This is yet again one more example of how the PMBOK, though a fine body of knowledge in the context of managing a single project, is quite incomplete and inadequate in terms of ALL of the project related work that takes place in just about any organization that manages projects. For example, there is work that takes place before Initiation, there is work that should take place after Closing, and there is also quite a bit of work by way of policies and procedures and business as usual management that takes place over the span of the project. None of this is addressed in PMBOK (nor should it be) in terms of a general purpose, collaboratively developed, body of knowledge.
Many people advocate that a Continuous Improvement process step follow the Closing process. In the Continuous Improvement process step, such things as lessons learned that are typically documented and filed away (lessons lost) are used as input to recommendations for specific areas of improvement. The impact of the execution difficulty behind the lessons learned are assessed and ranked and improvement recommendations are offered for consideration to be acted upon.
Naturally, not all improvement recommendations for lessons learned can be or need to be acted upon. Like John comments below, "...take 1-2 of these lessons learned and FIX the issue so it never appears again, their whole enterprise would benefit."
Some people combine the Lessons Learned documentation with the development of an improvement suggestion. There is value to that. Others prefer to keep the documentation of lessons learned in the Closing process and have the development of improvement recommendations be done, by way of project process, in a post-Closing process step. Many folks prefer the latter as it enables the project to be closed while at the same time recognizing there is still more project related post-closing work to be done and reviewed with the PMO.
Getting back to your main question of the post, "How do you track and keep records of your lessons learned for all your projects in your organization so that they can be shared with everyone?", we see many folks use Gating, a management activity and end of process step to document, review, and share lessons learned during the span of the project in addition to the customary end of project effort. As one of many project artifacts, such a document can be kept on the PMO's platform for collaboration and document management such as SharePoint, Lotus, a well structured network file share, etc. Saving Changes...
Don KimPROJECT-TO-PORTFOLIO MANAGEMENT EXPERT| Seeking opportunitiesSacramento, CA, United States
Wai Mun - I see where your going. No doubt putting these L3's into a smart knowledge base would allow one to do structured and semi-structured cataloging and analysis of the lessons learned. I think implementing a full blown one would be pricey. I did talk to my SharePoint guy in my company and he mentioned that in SharePoint 2010, it will have a feature to do feature rich metadata cataloging of documents to incorporate the kind of functionality you are describing.
If your using MS Project Server 2010, it basically sits on top of enterprise SharePoint 2010, so this may be one type of solution.
Of course if you go the Google site route, it is run by Google, so you can bet it will have SEO, page ranking and key work search capabilities built right in. :) Saving Changes...
"The reason I raised this question is I was inspired by the Museum of Failed Products, Michigan (part of GfK Custom Research, North America). I was thinking that if we could have a public repository of failed projects that anyone can contribute and share with the rest of the people who are in the field or interested to learn more in project management by studying what had gone wrong. I believe it would be a trove of treasure for the PM community."
That's the most awesome thing I've heard today. I can totally see it, too - welcome to the Bungled Bin, where projects who could not live on as shining examples come to die as horrible warnings.
The problem though, as with all endeavours that relate to learning from past mistakes, is the necessary prior acknowledgement of said mistakes. We, as PMs and PMOs, more often than not know what went wrong and what should be done to fix it. What we really need is for those "lessons learnt" to be read and acted on by those people who have the power to cause change, but who would rather fire the innocent than disturb the status quo, as it could be interpreted as admiting to their managerial errors. Saving Changes...
