Thursday 5 March 2015

How to capture "Know-why" (and why)

One of the pieces of knowledge which is seldom captures is Why things are done.  In many circumstances, the Know-Why is as important as the Know-How.


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.

Where know-how breaks down, is when circumstances change.

An example comes from deepwater drilling back in the 90s, where one part of the organisation was learning from another part about a particular technique for drilling in deepwater. The details of the technique were transferred, but not the reasoning behind it, and when the team applied the technique in their own context, it failed, and several days were spent recovering the situation, at a cost of a quarter of a million dollars a day.

One of the partners involved with the well, however, picked up the technique and also the rationale behind it, 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

How do you capture the Know-Why?

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,m and this is also recorded in the lessons management system. 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.

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.

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".

No comments:

Blog Archive