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 …

jpmacl: how will you get the team to contribute their solutions?
meeboguest: that’s easy – I’m the manager, and I will make them

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).