Knowledge Capture

“To move ahead, one must often first look behind.”
–David Garvin, US Army

The issue:

I often hear a manager say to a project team member, “Your situation would make for a great lessons learned! You should document that.” The team member usually nods in agreement but silently begins thinking, “How can I possibly cram all of this information into a readable document without writing a novel and taking too much time?” If the team member is lucky, time erases the issue from everyone’s memory and they move on to the next assignment. If they’re not so lucky, the task goes on their goals sheet to be completed within the next 6 months. They quickly fill out a lessons-learned summary with a few graphs and charts slapped into the form along with some flowery language. Neither outcome is beneficial for continuous improvement, but unfortunately it is all too common. Knowledge Capture is valuable for making tribal knowledge readily accessible to those who need to make use of it for future decision-making and faster innovation. A Knowledge Capture document sheds light on foundational information such as potential costs, timing, or technology limitations. To help your company manage its lessons learned in a useful way, this article looks at the importance of clear expectations, simple formatting, and honest feedback.

Clear Expectations

Encouraging others to document their lessons learned should not mean creating formal chronicles that “thou shalt not alter, erase, or remove”. Knowledge Capture documents are not intended to be permanent monuments that prevent companies from exploration or experimentation. The documents should be like summary bulletins or succinct conversations with people not as familiar with the topic. I like to think of the reader as being a new college intern without a lot of industry experience. This helps me check my assumptions about what the audience may or may not already know.

When we face a challenge and we don’t know anything about the topic, these concise summaries allow us to quickly become informed enough to understand the variables and topics being discussed. We don’t have time to read volumes of information, so these short documents share only relevant information and help teams maintain and exceed project timelines. The goal is to become informed quickly so we can contribute to a robust solution faster.

It is important to understand that the perfect Knowledge Capture document does not exist. Rather, it ought to be looked at as a living document that grows and changes as the organization’s knowledge of the topic evolves and as new information is gathered and exchanged. The author ought to stay away from absolute statements such as “NEVER create a die locked condition”, “ALWAYS use draft on your parts”, “You Must do…”. What seems unimaginable today may be commonplace tomorrow. You don’t want your company to fall behind due to wrong assumptions about what will forever be impossible.

We can also learn from Henry Ford who stated, “The factory keeps no record of experiments…I am not particularly anxious for the men to remember what someone else has tried to do in the past, for then we might quickly accumulate far too many things that could not be done… it by no means follows because one man has failed in a certain method that another man will not succeed.” Although Ford seems to challenge the very idea of Knowledge Capture, his thoughts communicate a true and often overlooked danger. A well-documented experiment void of assumptions and parameters causes much more harm than good. Rather than expanding organizational knowledge it creates excuses that are used to justify lack of experimentation and initiative.

Format

My favorite method of capturing lessons learned is by writing an A3. An A3 is a letter-size (A3 paper size) problem solving and continuous improvement approach that often uses the Plan-Do-Check-Act (PDCA) principles by Deming. See the Figure 1 example. It’s purpose may be to solve problems (like an 8D) or to distribute general information (design guide). There may not be a root cause.

Figure 1: A3 Problem-Solving Process using PDCA

An A3 forces me to be clear and concise about what I have learned. It also encourages me to think critically about what the most important information is and how I can make it more readily understandable. Although the format is irrelevant, I typically begin with either a PDCA cycle or LAMDA cycle approach to writing my A3’s. I use these as loose guidelines to prompt me to fill in information that may be important to anyone that may want to duplicate my experiments or better understand how we interpreted the data at that point in time. Figure 2 is an example of an A3 on One Dimensional Stack Analysis.

Figure 2: A3 – One Dimensional Stack Analysis

Depending on the reason you are writing your document you may choose to omit or limit how much time you spend on each section. If you are using the document to layout your problem- solving process it will look much different than the document you use to create an informational bulletin. One key section that is often skimmed over or not given enough time is the “Background / Plan / Problem” section that describes what the document is about and why the reader should care. This is the abstract for the whole document. Within a couple sentences the reader should have one of the two following responses:

1. “Me too! That’s exactly what I’d like to know!”
2. “Who cares? Not even close to what I’m looking for!”

Both responses are equally valuable. The goal is for the reader to only read our Knowledge Capture document if it applies to them.

Feedback

Whatever method or format your company chooses to use, a Knowledge Capture document should not be created without feedback. Other co-workers (including the future YOU!) may have a hard time following the logic from unspoken conversations and data from your memory that you drew upon to complete the document. Like in math class, “Show your work!” We’ve all had the experience of reading through old notebooks or hand-written reminders and having no idea as to its meaning. This is why your document needs to be reviewed by someone who is unfamiliar with your project. They can provide honest feedback on the intricate details and data you are trying to present. The person evaluating your Knowledge Capture document should also be someone that may very well refer to it down the road. They will have a vested interest in making sure they can read and understand the information for helpful future reference.

Resources:

By actively cataloging and sharing your lessons learned, your company will make better and quicker decisions; you will have the ability to focus on solving new problems while having a better understanding of what has already been tested. While this article is not a “HOW TO…” manual on writing A3’s or managing a Knowledge Capture database, there are many beneficial resources available online and in book form to guide you through your lean journey. Some of my favorites are:

• Understanding A3 Thinking, by Durward Sobek and Art Smalley
• Lean Product and Process Development, by Allen Ward and Durward Sobek
• Innovative Lean Development, by Timothy Schipper and Mark Swets

Written By: Dennis Smith – Mechanical Engineer |
Dennis has over 10 years of experience as a product and manufacturing engineer in the furniture and automotive industry. His passion for lean product development has helped customers launch and support dozens of new products.