cazh1: on Business, Information, and Technology

College Professor uses Tried-and-True method for Encouraging Knowledge Sharing

via Slashdot a few weeks ago, and Ars Technica; at the University of Washington-Bothell, Martha Groom recently assigned her students to work on Wikipedia entries, and add to the knowledge base. An interesting approach; I found the reaction of the Wikipedia community most interesting, in that the entries were aggressively edited and commented upon - sometimes "rudely".

It's a common theme in many KM discussions, as early adopters enter their first Trough of Disillusionment, and see these wonderful tools languish from lack of use. Just this afternoon, I got into an impromptu meebo conversation with someone looking to implement a knowledge base for an international help desk ...

I sensed a type-A personality at the other end, but there is method to this madness. The Law of Large Numbers tells you that you can't rely on idealism - in a typical working group / business organization, there aren't enough self-motivated contributors to generate meaningful content

Some incentive is typically necessary to get folks to contribute to the knowledge base. One approach I've used in the past is simply requiring a certain number of wiki entries per person on the team - nothing too outrageous, averaging out to one or two entries per month. If you try this approach, I would strongly encourage folks to make their entries once every couple of weeks; this gets you into the habit of using the tool. Don't put it all off to a marathon data entry session right before the end of the year.

But don't stop there! Contributing knowledge is half the battle - you must develop the team's habit of using the knowledge base.

Years ago, when object-oriented programming was in vogue, development teams in many companies worked to create object libraries for commonly used code. The trick, of course, was to get well-written, reusable code into the library - and then see it re-used. Some sharp-thinking organizations would incent coders when their code was leveraged in another area.

The same might be done with a wiki or other knowledge base, if you can define a metric that quantifies how often a piece of knowledge is reused. For example, how much traffic does the wiki page get? How many times does the article appears in search results? In the help desk scenario above, we could require each trouble ticket to note which articles in the knowledge base helped solve the problem ... a simple counter at the end of the month will tell me how often my excellent solution saved the day.

Remember, it's not enough that people are capturing knowledge - it needs to be captured in a format that is relevant and useful (else, it's just another bag of bits).

Previously ...

• The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
• Thoughts on Why Tech Folks Hate Documentation (July 08, 2006)
• Moving from Search to Find: Anticipate the Next Big Problem (April 16, 2007)
• More on (sic) experience with wikis (January 31, 2007)
• Do blogs fit in the enterprise? Specific examples (WIIFMs) ... (April 19, 2007)
• The Joy of Programming, the Challenge of KM (May 05, 2007)
• Consarned whippersnappers (Generational Diversity) (May 20, 2007)
• Driving Participation and Contributions on Internal Blogs and Wikis (July 07, 2007)
• The Right Web2.0 Tool for The Job (July 16, 2007)

Technorati Tags: collaboration, documentation, knowledge management, meebo, tech management, wiki

posted by James P. MacLennan at 9:13 PM | Permalink | 0 Comments