Gathering knowledge

Answering a question in Brint's ThinkTank.

"How would you recommend that the 'knowledge' is gathered? Thru databases? internet libraries? or maybe surveys? forums? focus groups?"

My answer. There are a number of ways to gather knowledge in addition to those you mention:

a) Collect the insights that percolate from work related conversations

b) Record the 'best' solutions to commom problems and issues

c) Construct an ontology / taxonomy, identify gaps and seek expertise to fill them

d) Encourage collection, indexing and distribution of best practices and lessons learned

e) Conduct formal After Action Reviews (AARs), encourage periodic reflections, craft patterns top collect solutions that work from experience

f) Apply knowledge harvesting techniques using tools such as Infinos or HKc

g) Perform acquisition using knowledge engineering methods

h) Use a technique called enumerative description to ask questions and gather key situational diagnostics

g) Set up a question driven community, e.g. using Organik and mine the insights

h) Construct 'profiles' and have a space where issues can be discussed and pushed to key decision makers, e.g. using Vignette dialog
i) Mine electronic messages and construct dynamic profiles using products like Autonomy or Tacit to link people to people via content matching.

In my experience structured questionnaires and surveys are the least effective may to gather knowledge, which is emergent and very context dependent. I strongly favor communities of practice and knowledge networking where emergent insights and shared meaning are evaluated, continuous learning happens, and participants are kept aware of developments by their peers.

Comments

[Mentor Cana]

Hi Denham,

The methods you have enumerated above (a-i) appear to correspond to knowledge representations and not knowledge itself. In my experience and studies I have found it very fruitful to make this distinction as it allows for better focus.--Mentor

[David Locke]

As I was stewing about my earlier comments, as I have railed against this notion that knowlege is social, because from everything I've been involved with it isn't, I realized that it isn't knowledge that is socially constructed, but the use of knowledge that is socially constructed.

All the knowlege we humans are going to discover already exists. It's infinite. What we socially construct is the explication and use of the explicated knowledge. So I can agree that in some, but certainly not all cases, knowledge use is social. I say, not in all cases, because knowledge can be used and useful while it is still implicit or tacit.

[David Locke]

Products embed tacit and implicit knowledge without explicating it. So products are the best way to capture knowledge.

[Gautam]

Hi Denham

Connecting after a hiatus with you. As usual, interesting thoughts.

My personal experience has been the use of non-written tools (audio-blogging? virtual classrooms?) specially in cultures that are not traditionally of the "written documentation" type..like the people of Asia :-))

regards,
Gautam

[David Locke]

If you gather data, it is only data. If it flows through an IT system it is only information. And, these days certain BI companies are pushing the idea that database systems are poor managers of actionable information.

None of the above is knowledge. You implement knowledge. Or, you explicate it into a less useful form. You do not have to understand knowledge to use it.

[David Locke]

"Construct an ontology / taxonomy, identify gaps and seek expertise to fill them"

Actually, in the corporate world, the taxonomy/ontology/culture/lexicon/semantics/metrics/systems are created with the intent of imposing the central view of the executive. These executives represent the line of business manager, the extroverts, not the expert introverts. Thus, the practice of creating these things is coersive.

The attack on functional silos, the breaking of silo is one of the driving goals in IT today. It fundamentally denies the role of the functional unit in businesses. Which means that you wouldn't consult an expert. You, if you were an executive, would go into a closet make up a definition and cram that definition down the experts throat.

The end point of this will be the psychotic organization. The talking head. Speaking only in XML languages meant to unify all things, but failing misreably, because container semantics is not contained semantics. So what if all the plumbing lines up. The stuff in the plumbing is specific to the discipline-specific cultures that gave rise to it. It was never meant to flow outside its domain. And, it wasn't given rise to in the organization, or with the executive being the consumer of it. Disciplines have their own language. The central language ignores this, as does the notion of a single corporate culture.