Difference between revisions of "Dynamic Knowledge Repository"

From Faster Than 20
(References)
m (3 revisions imported: Imported from WebFaction on September 14, 2021)
 
(No difference)

Latest revision as of 23:52, 14 September 2021

A term coined by Doug Engelbart that describes a group's collective repository of knowledge. "DKR" for short. Because all forms of collaboration include knowledge work, to achieve high-performance collaboration, we must become good at managing this DKR.

A DKR consists of a group of people and an up-to-date, integrated store of information that is used, developed, and maintained by the group.

Understanding this definition and its implications (what it does and does not entail) gives us clues for developing effective knowledge management strategies. For example, DKRs exist with all groups doing knowledge work, whether or not the groups are conscious of them. Effective groups think explicitly about how to improve their DKRs.

What Is Knowledge?

People often confuse "knowledge" with "information," but there is an importance distinction between the two. Knowledge is information that has been internalized.[1] If you have a physics textbook on your shelf, then you have information (or a knowledge artifact). If you are capable of doing the problems in the textbook, then you have knowledge.

Because knowledge does not exist outside of people, the notion of a Dynamic Knowledge Repository must also include people. An effective Knowledge Management strategy should also explicitly include people. Studies have shown that only 0.5 percent of an organization's knowledge is captured in document form.[2] The rest is tacit knowledge, informal knowledge that humans have, but that is not explicitly captured.

A useful way to think about knowledge in the context of DKRs or knowledge management is to break it down into the things you know and don't know. Specifically, there are:

Image:Epistemology.png|center

Designing systems (both tools and processes) that help us manage the first two types (things you know you know, things you know you don't know) is relatively straightforward. The larger challenge is addressing the third type (things you don't know you don't know). Doing so helps facilitate emergence and evolution within a group.

DKR Examples and Implications

Many people mistakenly assume that a DKR is some kind of information management software. This is narrow thinking. While a DKR may include a software tool, it must be viewed as a system, including the people who are part of that community. For example, a tribal community with an oral tradition is a DKR that does not use of software or possibly even written language.

There is no such thing as a purely digital DKR. Humans are always part of the system. For example, a library, its librarians, and the community of people who use the library are all part of a DKR.

The minimum Dynamic Knowledge Repository is a person or group of people. Treat the knowledge in people's heads and the interaction between the people as part of the design. Also consider the interaction between the people and the artifacts as well as the containers for the artifacts.

As you scale from individuals to small groups to large networks, you need to account for the Messy Desk Syndrome in the design of your DKR and in your usage patterns.

Historical Definition

Doug Engelbart defines DKRs as consisting of three primary components:

  • Intelligence collection
  • Recorded dialog
  • Knowledge product

Doug's choice of the word "intelligence" was unfortunate, because it implies many different things. He means "intelligence" in the sense of "gathering intelligence":

An alert project group... always keeps a watchful eye on its external environment, actively surveying, ingesting, and interacting with it. The resulting intelligence is integrated with other project knowledge on an ongoing basis to identify problems, needs, and opportunities which might require attention or action.

Recorded dialog refers to the conversations between project members, be they verbatim transcripts or meeting minutes.

Knowledge products are the products of our knowledge, the expression or application of knowledge that we have acquired. For example, a software development team might produce an architectural document, or a business development consultant might produce a new corporate strategy. Knowledge products can be thought of as the integration of intelligence collection and recorded dialog. Doug often uses the term "handbook" and "knowledge products" interchangeably.

As a classification scheme, all three of these components are highly contextual. For example, a physics textbook is the author's knowledge product, but for people who do not know physics, it is part of their intelligence collection. Whether or not something can be considered "knowledge product" depends on whether someone within your team actually has that knowledge. In other words, the knowledge product implies humans as part of the system.

Doug's definition of a DKR has several flaws. First, he uses weighty terms like "intelligence" and "knowledge" without precisely defining them. Avoiding these terms is possible and would make the definition more rigorous. Second, the distinctions between the components are not clear. Recorded dialog, for example, could also be considered knowledge product. Third, the human element of a DKR is not explicit. Making it so would help prevent confusion between DKRs and the infrastructure that supports them, and would also add an important element to the design of information repositories.

The definition that we use above attempts to correct these deficiencies.

References

  1. Keith Devlin. Infosense: Turning Information into Knowledge. (New York, NY: W. H. Freeman and Company, 1999). p15.
  2. Larry Leifer. "Distributed Design Team Innovation Metrics and the Role of Collaboration Technology." Computer Systems Laboratory Colloquium, Stanford University, September 26, 2001