A simple method for building better Knowledge Capability solutions
How to build better Knowledge Capability solutions
I've been talking a lot lately about the disharmony that is created when people try to use tools/models/frameworks/solutions in situations for which they are not designed.
Quite simply, managers take a square peg to fill a round hole and then, when the "solution" stresses and fails, they spend valuable resource trying to figure out where it all went wrong.
Start with a typical problem: "we want to capture the knowledge from our engineering experts before they leave the company."
Ask yourself, what does this knowledge look like? To help understand this, work with the engineers to explore the answers they give to the questions they are asked (see the diagram below - adapted from Snowden's Cynefin Model).
One right answer solution = e.g. checklists or Standard Operating Procedures.
Better or worse answers solution = e.g. decision maps or lessons learned portals
No apparent right answer solution = e.g. communities or knowledge hacking
But this is only the beginning, you also need to consider the load being placed on the "solution" you propose (see diagram below):
Intrinsic load = the characteristics of the content you need to capture (refer to the model above)
Germane load = effort required to organise knowledge into a schema (the breadth of effort increases as you move from simple through to complex domains)
Extraneous load = external interference (e.g. knowledge capture during a period of down-sizing).
All these aspects must be considered if you are to be successful. The problem is that all too often these aspects are ignored in favour of taking a solution that has worked in one domain and shoehorning it into another.
The bottom line:
KM fails where the knowledge load exceeds the capability of the solution.
