Felix LudosanSenior Program Manager| BASFNeustadt/Weinstrasse, Germany
Hi, what lessons learned software products (databases) are you using in your company? We are using an application developed by an inhouse team. I would be curious to learn what other tools are being used in other companies (with success). Thank you! Regards, Felix Saving Changes...
At a former company, we had a repository of LL documents. Almost nobody used it. When you did try to use it, it was hard to find anything useful.
At my current employer, we've combined a project checklist with lessons learned. The outcome of a lessons learned meeting is a list of information, focusing on what is actionable, that we categorize as follows:
- historical information (no action needed) - information that would be helpful in future phases of the project (we don't always wait for the end of the project for lessons learned. Steps are added to the project schedule, as appropriate.) - information that would be helpful on other, active projects or business processes (the information is shared with the appropriate people, who determine what to do with it) - information that would be helpful on future projects (the information is added to the project checklist, which is reviewed regularly throughout the project)
In theory, an item can exist in multiple categories, but this overall process is something I've only recently introduced so I don't have good examples. The next step is to regularly review the project checklist to determine if the items on it are still relevant. We've also discussed using the checklist when reviewing projects during 1:1s. Saving Changes...
As Aaron has indicated, most folks don't take the time to search for lessons in repositories regardless of how easy to search those are. It is often more effective to "bake" the lessons into your standards & policies and to share others through constructs such as Communities of Practice.
This topic has come up multiple times, and there seems a general consensus that lessons learned databases have significant limitations. The ability to get useful results is a big part of it.
As you generate a basic database, people generally enter freeform text which is difficult to use for consistent search results. Generally there are categories created from the start, but they must be well structured to group like things, you can have multiple categories apply to each item, and as you learn more about what data is useful, you will likely add more fields. That can require significant rework to update the database for the older lessons that don't fit the new organization. If you don't organize well, either you won't get useful search results and lose important lessons, or people must trudge through vast databases, with lots of duplicate data. People eventually give up.
For very important lessons like safety related issues, I have seen success. A smaller set of specific types of lessons learned are collected, and managed more carefully. This requires administration overhead. Trained focals are managing the database, rather than N untrained users entering lessons N^2 ways. With the structure and discipline, the search results are much better.
What could bridge that gap is starting with a smaller number of lessons to learn lessons about how to organize lessons learned (that's a mouthful), and then restructure the database before it gets too big for the 2nd effort with 100X the data. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
In our company lessons learned are a component of a knowledge management system. In our case all the system is based on Microsoft products. Saving Changes...
Community Champion
