At most places I have worked, lessons learned from a project do not benefit future work because it is not available in an accessible way to other team members. Has anyone found an effective and accessible way to document and publish information from lessons learned or retrospectives so that after projects close, that knowledge and those ideas will not be lost? What tool did you use? How did you structure the information? What discipline did you need to put in place? Saving Changes...
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Pamela
Lessons Learned has been one major factor for us imporving our project delivery, quality, productivity and client satisfaction.
We normally do a final restrospective at the end of the project, and circulate results to all the organization then those lessons learned, along with others recorded throughout the project are put into the PMIS that is shared accross the company.
Knowledge sharing and knowledge transfer that requires teams ownership, committment and collboration is the secret receipe for making difference using lessons learned. You need to build this into the organziation's culture one way or another just like you build-in quality into the projects.
RK Saving Changes...
George FreemanThought Leader | Author | Architect| Florida, United States
Hi Pamela,
It always seems to be a struggle to get project professionals to reference lessons learned, even when it’s readily available and done through mandated processes. And when they are reviewed, that doesn’t mean that the write-up was able to communicate the proper context, let alone non-mentionable content like the impact “corporate politics” had on the project, etc.
Although more difficult in virtual settings, brown bag sessions allow lessons learned to be communicated in ways that leave a lasting impression, as it’s a collaborative forum. I also like to inject humor into the equation, making it more relatable and memorable.
I documented some of my lessons learned in a humor-based article a few years back and then did a webinar using the same approach (reference below). Bottom Line: Creating an empathetic connection and sharing goes much further than a document housed “only” in a repository.
Knowledge sharing is frequently a big challenge. While ideally you can grow the knowledge of an organization over time through peer-to-peer knowledge transfer, this has limitations. During covid, some companies had such high turnover due to people leaving or changing jobs, a lot of knowledge was lost.
One thing you can do is interview people from past projects to get their input. Then you have face to face communications on relevant topics at the time required rather than hoping people remember lessons from long ago that were not always relevant at that time.
Recording that in a system for later retrieval also provides challenges. You either need a lot of structure to query for relevant topics without either finding nothing or too much to consume, or you need a smarter way to find the relevant things. Some very important databases require a lot of formatting discipline such as by having a gatekeeper, and they may require reorganizing over time which is expensive. With big data tools, it makes it easier to find inconsistent things like differences between engineering, eng, engr, misspellings, etc. Not everyone has access to those tools, and they are also expensive. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
In my case, along the years, I lead this type of thing as a component of a knowledge management system, where system is not software system only. That´s worked for me. Saving Changes...
I did an on-demand webinar on the topic of getting more value out of lessons learned a few years back - you can find it in the on demand section of the webinars menu.
Baking lessons into standard procedures and templates is better than just hoping folks remember them. I would also suggest that lessons are different than reminders and organizational blockers. The latter two are often lumped in with lessons but need to be handled in a different manner.
Well, it depends on the nature of the projects. Are they similar to each other?
However, documenting and sharing the lessons learned is very important. I usually try to invite the key member to a meeting and ask questions. Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
I find that formal lessons learned exercises tend to focus on the wrong lesson. Typically a LL identifies the technical challenge and provides the technical solution applied to the challenge. Thus, if we run into a similar challenge under similar conditions the earlier solution may be applicable or at least worth considering.
However, in the management business, we should be focused on how we got to the solution rather than the solution itself. From that perspective the challenge, the conditions under which the challenged occurred and the possible solution do not have to be similar. The process of identifying and analysing the challenge becomes the lesson.
Most LL should fall out of the Risk Management effort keeping in mind that RM includes enhancing benefits as well as mitigating risks. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Pamela,
I second Sergio: what you need is a knowledge management system at your organisation. It includes a tool, but more important a culture change, knowledge stewards, and probably a business case to get buy in.
At IBM we had 40K project managers participating in the knowledge base and the financial value was measured in savings by re-using knowledge assets.
The very short answer is to separate actionable information (things to do on current or future projects) from historical information (reasons for delays/overages, info for audits, individual recognition, etc.) and keep the actionable information front and center until it is resolved. It doesn't take long for people to stop looking at historical information. If your actionable information is buried in historical information, it will get lost. Saving Changes...
Muhammad AleemProject Manager| Fluor CanadaCalgary, Alberta, Canada
The most difficult part of lessons learned is to utilize them in a way that these can benefit new projects. The problem I have seen across the organizations that lessons learned are documented in complex formats and not readily available when these are needed. So to solve this problem, we try to manage a log of lessons learned and review them at the start of every new project. The lessons that are implemented on the projects repeatedly become part of the organizational memory and are ultimately off the log and new lessons keep on populating. Secondly, I strongly believe on 80-20 rule and only major project issues should be captured as part of lessons learned. Saving Changes...
Community Champion
