Enemies of Knowledge - Inside Knowledge

Feature

posted 1 Aug 1997 in Volume 1 Issue 1

Enemies of Knowledge

Laurence Prusak, IBM Consulting Group, takes a hard look at what he calls 'enemies of knowledge,' i.e. a set of practices and understandings that can sabotage the most well-engineered knowledge project.

Now that knowledge management projects, however so defined, are becoming a reality within firms and government agencies, it might be useful to take a hard look at what I choose to call 'enemies of knowledge,' i.e. a set of practices and understandings that can sabotage the most well-engineered knowledge project. Whilst this list is far from comprehensive, it differs from most compendiums of this sort by focusing on those factors that are specific to knowledge projects rather than generic project failure factors such as faulty leadership, poor planning, etc.

Here is a list in order of criticality of the top eight enemies:

1. Too tight coupling

One of the worst legacies of the recent spate of business process reengineering efforts is the concept that an organization is best understood as a machine - a machine that can be fine-tuned into delivering greater performance. In any organizations where knowledge work builds on a reengineering base, this results in prescribing work tasks into very tightly coupled, bound, and prescribed definitions which leave virtually no room or time for knowledge to be generated or transferred. Machines of course don't need time for reflection. Alas, people can't learn much without it.

2. Overemphasis on technology

Whenever a new development occurs in organizational thinking and it catches on, there are soon to be seen swarms of vendors who claim, with varying levels of authority, to be able to make tangible these ideas through technology. Why would knowledge management be an exception to this practice? Especially since there is a rich and fascinating history of attempts to codify knowledge through A.1., expert and other systems. However, knowledge, per se, remains a stubbornly human attribute that tends to resist capture. Technology is often better used as a connector for knowledge rather than a capturer. In any case, when a knowledge project spends over half its resources on IT, it is no longer a knowledge project. It becomes an IT project.

3. Conflating knowledge, information and data

Many executives, impatient with too subtle definitions, tend to lump all three of these categories together. This merging allows firms to consider SAP or Data Warehouse projects to be considered knowledge efforts and gets executives off the hook from having to focus on what people actually know. No rational observer would dispute that an organization needs to manage data, information and knowledge in order to function. But these are separate things needing different approaches, tools and measures to manage well. The world knows well how to manage data (best understood as records of transactions) and information (understood as messages), but is just beginning to understand what to do with knowledge processes and stocks. However, this provides a poor excuse to justify saying 'It's all the same.'

4. Virtual Virtuality

There is a plethora of evidence which points pretty conclusively that human beings best learn from other human beings face-to-face. Whilst this doesn't make useless the fortunes spent trying to get around this stubborn finding, it does throw a monkey wrench into the plans of those who think digitalization is the optimal rather than an efficient way to transmit information. Knowledge, however, exists primarily in people's heads and is optimally transferred by working with others.

5. Access = Value

Every new technology brings with it hyperbolic predictions about what transformations and other miraculous events will come about from them with information and knowledge. These are predicated on the assumption that the very act of offering knowledge systems, various sorts of and access to information and knowledge, will assure value for the organization. Why? We all have access to the world's best thinking in our research libraries. Where are the lines of folks beating down the doors? We all have telephones, e-mail and various other messaging media. Do these alone offer value? Or is value to be found in the activities these services serve? And isn't the best measure of utilization better assured by the user's evaluation and behaviors?

6. Physics Envy

Both the quality movement and the rise of the finance function have given us a double-edged sword in terms of measurement. While no one denies the value of measures for providing some feedback to a system, measures prove to be far less applicable for knowledge activities. After all, when all is said and done, you can't measure knowledge. You can, practically, only measure knowledge outcomes and activities. Even these can be best measured through proxies and milestones rather than formal quantification. For example, some firms view patents granted, old customers retained, new customers acquired and new products introduced as proxies for the effectiveness of their knowledge activities. Still others view the embedding of innovative work practices as a good measure of knowledge. However, the real enemy here is a false quantification which allows users to 'game the system' to acquire knowledge credits. Firms that measure transactions (hits on the web, books or reports signed out) open themselves to this false numeracy. Firms end up measuring what is measurable, not what is valuable.

7. The map becomes the territory

To many organizations and their consultants, it is far easier working with documents than with knowledge itself. Therefore they put their reports and other critical documents in a file or document management system and call it a 'knowledge system,' and go home happy. However, a document is not knowledge, but a bound representation of what an individual or team knew at a specific point in time. And while these documents may well be worth managing, the maps are not be the same thing as the territory itself.

8. Culture trumps everything

Who wants to try and change a firm's culture? It is a decidedly difficult task with no sure formula available for success. Organizations are just similar enough to inspire generalizations about culture, but just contextual and idiopathic enough to insure failure by going the 'paint by numbers' route. Yet there really is such a thing as a corporate (or divisional) culture that can powerfully distort any knowledge project from its path. Specific knowledge cultures are the knowledge norms, values, and behaviors that evolve in organizations and directly affect how individuals behave towards knowledge, i.e. share vs. hoard; proactively distribute vs. respond only when asked; innovate vs. default to rote procedures, etc. Cultures are often left out of projects because it is, again, easier to put in groupware, hire a chief knowledge officer, or develop a knowledge process then it is to try to influence behavior.

But by ignoring culture, you may doom your project without ever knowing why it failed.

Laurence Prusak works at IBM Consulting Group. He can be contacted at:

prusak@boston.vnet.ibm.com