Members Only Logo  

or Subscribe by Email by entering your address below:

Powered by FeedBlitz
Learn about Subscriptions Follow me on Twitter!

The topics discussed here grow out of the bread-and-butter issues that confront my consulting and software clients on a daily basis. We'll talk about prosaic stuff like Membership Management, Meetings and Events Management and Fundraising, broader ideas like security and software project management, and the social, cultural, and organizational issues that impact IT decision-making.

Wednesday, February 22, 2006

Using our heads

In a couple of posts a few weeks ago, I warned that information that is just in people's heads and not shared organizationally cannot be considered organizational knowledge, and suggested the reuse of routine communications as a path to capturing this knowledge in a way that does not create endless new documentation tasks. But Sharon Richardson in a thought-provoking post on her Joining Dots blog proposes that the emphasis on documents of any sort is a very limited view of knowledge management.
...I think Knowledge Management should be replaced with Knowledge Support. The phrase Knowledge Management just naturally lends itself to managing something tangible and that means documents - but stuff in documents is really just information, it requires a person to use it as knowledge....Knowledge Support shifts the focus to people and the application of knowledge.
The "stuff in documents," Sharon suggests, is just one leg of a triad that comprises organizational knowledge - the other two are the "stuff in heads" and the "stuff in databases". And its the actual investment in people that she sees as the neglected component of knowledge management.

She doesn't offer specific examples of this type of investment - but I found myself thinking of the Pair Programming model popularized by the Extreme Programming methodology, also known as XP. In this approach, all coding of software is done by two programmers working together. Despite the initial perception that this method will double the number of person-hours for each task, pair programming has been seen to generate better-designed and less buggy software, with only a slight increase in the number of person-hours involved. So here is an approach that increases sharing and immediate application of knowledge directly between heads without any intervening documentation process.

Often, in organizations where time is scarce and money even more so, investing in knowledge application this way seems an unjustifiable waste. But pair programming has been shown to be quite cost effective. This is an example from software development, but maybe there are investments like this in other domains that all of our organizations could be making in order to leverage our human knowledge better.

Tags: , , ,

Comments on "Using our heads"


post a comment