Q: We capture knowledge from projects in lessons-learned documents, but our engineers rarely look at them, forcing us to relearn knowledge for new projects. How can we get our engineers to use the knowledge we already have?
A: That is a great and common question. You are not alone. Many organizations struggle with effectively using organizational knowledge. Organizations often focus on picking the right practice or tool to capture knowledge, assuming that, once it is captured, others in the organization will use it. Like all lean practices, the effectiveness of knowledge–sharing practices is determined by how well it helps people do their work.
Understanding the Customer of the Knowledge Sharing Practice
If you focus on understanding who needs what knowledge, you can design a knowledge–sharing practice people will use. The customers of your knowledge–sharing system are the development team members. You need to understand what knowledge the team members need and when they need it so knowledge can be shared with or pulled by the people who need it at the right time. It would be best to also understand what doesn’t work about your current knowledge–sharing practices for team members. There are a couple of common reasons why lessons learned documents don’t get used:
- The right knowledge is hard to find. If team members can’t find the knowledge they need, they feel like they wasted their time.
- Creating new knowledge (even if it already exists in the organization) feels more meaningful and enjoyable than searching for knowledge.
Why Knowledge is Hard to Find
Team members — the customers of the knowledge — frequently find it challenging to find captured knowledge because knowledge-sharing practices are often designed around making the process easiest for the people contributing knowledge. In the case of lessons learned, the team completing a project usually creates a document that captures what it feels is essential and then stores it in a shared drive accessible across the organization.
In practice, these documents are rarely — if ever — used, causing the people who write them to put minimal effort into capturing their knowledge, which makes it less likely that other project teams will use the documents — and the cycle continues.
Some team members become disengaged, feeling like they are wasting their time capturing knowledge that nobody will use. Other team members become disengaged as you ask them to search through poorly organized shared folders, trying to find helpful knowledge. (Often, the documents are filed in folders organized by project, not by essential learning topics.) There is often invaluable knowledge in the files, but finding it is like finding a needle in a haystack. Frequently, people don’t even bother looking since the relevant knowledge is hard to find; the search is too frustrating.
Why Knowledge is Recreated Instead of Reused
When it is difficult to reuse knowledge, most people recreate it for their new project. Or worse yet, if there isn’t time to create it, people make decisions with insufficient learning, which usually has negative consequences. Most people enjoy creating new knowledge, which is perceived as creating new value, even when the knowledge already exists in the organization.
Just–in–time knowledge creation is fun and often is what is valued and rewarded in organizations. But it is an easy way to fall behind the competition when they effectively reuse knowledge and focus their energy on creating genuinely new knowledge and value for their organization. Still, most team members would prefer not to recreate existing organizational knowledge and wouldn’t if it were easy to find.
Designing a System Your Team Will Use
For people to reuse knowledge, it needs to be shared at the right time in the development process in a helpful format that makes the work easier. There isn’t an easy knowledge–management tool solution. Instead, you must provide your development teams with the support they need to create new value. You need to build knowledge reuse into your development process.
… deploying such a system frees team members to focus their time and energy toward creating new organizational knowledge.
Creating this process can and should take many forms and should evolve as you capture more knowledge in reusable formats. The easiest place to start is person–to–person sharing, which can include individual mentoring. Such sharing also takes place in obeyas and during design reviews that are part of the development project.
Design guides, trade-off curves, and design standards are other ways to share knowledge when it is needed. When structured around how specific part components and the overall product is designed, these documents can be effective for providing knowledge at the time it is required. Design guides work best when used along with mentoring and design reviews and not as a replacement. Trade-off curves, which make knowledge visible and easier to use, is another tool that enables knowledge sharing if their use is built into your development process. Design standards, which includes reusing proven standard components, common platforms, and modularity, enable you to focus your energy and effort on designing the part of the product that adds new value. When 80% of your design is fixed (reused), you can focus your energy on the 20% the customer cares about and differentiates you from the competition.
Designing knowledge-sharing practices that will allow people to get the necessary knowledge at the right time ensures that your team reuses the knowledge your organization has already created. Critically, deploying such a system frees team members to focus their time and energy toward creating new organizational knowledge. Continuously reusing and creating new organizational knowledge sets the foundation to develop new innovative products providing a competitive advantage consistently.
Good insights, Katrina. What a lot of managers don’t seem to realize is that to develop and maintain design guides and other user-friendly knowledge repositories requires an extra step. It is normally not enough to simply “capture” lessons learned. Rather those lessons need be formalized into something that can be used on a future project which requires some additional effort and development work. That effort, though, can be highly value-added to the organization as a way to pass learning between people and project teams, and build learning into massive knowledge treasure troves!