What can happen if you don’t capture the "know-why"

Know-Why is important in KM, but sometimes neglected. Let’s see what happens if this is not captured.

Image courtesy of keesler.af.mil

Know-how is one of the cornerstones of Knowledge Management.  If we capture how things should be done, we empower people who need to perform a task, but have no experience of their own. Capturing know-how allows you to build a “recipe book” for repeat tasks, which allow them to be replicated in similar circumstances in future.

However unless you also capture know-why, the know-how can trip you up, especially when the know-how is applied in a different context.

Here is an example of when know-how was misapplied, through lack of know-why. 

This story comes from oil-well drilling back in the 90s, where one part of the organisation was learning from another part about a particular technique for drilling in deep water. The details of the technique were transferred, but not the reasoning behind it, and when the team applied the technique in their own part of the world, where the sea-bed was different, it failed, and several days were spent recovering the situation at a cost of over a million dollars.

One of the partners involved with the well, however, picked up the technique and also the rationale behind it(the know-why)  and applied it successfully, at a saving of several million dollars per well.

If we capture the  Know-how of a technique, but not the Know-why, then

1. others can “follow the recipe” when the context is the same, but
2. when circumstances change, people do not have the knowledge to adapt the technique, and either proceed to failure, or tinker with the technique, which often leads to failure as well

If we capture the  Know-how of a technique and also capture the Know-why, then

1. others can know when the recipe is inapplicable, and
2. know what can be safely changed

There are a number of ways to capture the Know-why.

In After Action Reviews and Retrospects, the questioning includes a “Root cause analysis” step, that shows why the lessons were derived, and why they are worded the way they are. The observers and participants understand the context, and this is also recorded in the lessons management system. There should always be a paper trail between any changes to procedures made as a result of lessons, and the know-why recorded in the lessons themselves.

The A3 approach used in product design also captures the context and the root cause.

Some equipment designers use a document called Basis of Design. This captures the rationale behind a design of equipment or design of a process. It explains why the design is the way that it is.  The Basis of Design can be updated as design continues, to capture any changes, and the rationale behind these.  As one Alaskan drilling engineer said to me, “With a good Basis of Design, I could come up to this oilfield and put a quality well program together in a week, and there hasn’t been a rig drilling here for two years”.

Toyota capture the Know-why in “checksheets”, attached to each technical drawing, which captures the rational behind the design, its impact on performance, and any known issues. Rolls Royce Aero Engines have an even more sophisticated system called the Design Rationale Editor, which captures the reasons behind design choices, and the reasons why other choices were rejected, as a Functional Analysis diagram.

In each case, the knowledge product contains not just the final design of a product or product, but the rationale behind it. This preserves crucial knowledge for future use.