« Collaborative tagging | Main | Deconstructing KM »

April 23, 2006


David Locke

The problem with selling KM as a capability to a corporation is that it needs to have clear distinction. Without a clear differentiator, you are a commodity. The differentiation is words.

If we deal with content, there are so many non-KM companies and disciplines that alread deal with that, and those capabilities are already built into the corporation with vested interests.

If you deal with info and data, same deal.

The niche market is where you build towards selling your idea. Instead of butting heads with the content people, the teaching peope, the IS people, why not be specific and distinguish knowledge and knowledge management. We would be much further along today, if we had.

The thing corporations need lay outside the reach of content, info, and data, but clearly within the grasp of knowledge and knowledge management.

Otherwise, all the blogs in the world just keep missing the point.

David Locke

Projects make processes. Projects make capabilities to fulfill or attempt to fulfill strategy. Strategy fulfills vision.

An organization is a media. An organization and it's goods are decisions. If you organize the decisions towards realization, you have captured organizational memory.

Take this one further to say capture and archive ALL decisions. Decisions are not database tables or text. Decisions are representations around choice exploration.

Denham Grey

Hi Shawn,

Your piece hits the sweet spots. Perhaps you could have reflected on core KM activities a little more, contrasting IM vs. KM attitudes, beliefs, processes.

It is not the conceptual differences between information / data and knowledge that is key, so much as what KM folk could (should?) do with that core distinction that makes the difference.

What I missed most in your script was the sense-making, solution finding, awareness, incremental learning, inquiry, aspects of KM.

Denham Grey


Thanks for your detailed response.

My take is far too many people do not bother to reflect on the differences between IM and KM and believe they are doing KM when they are really working / dealing / organising information.

Building a repository of lessons learned - is IM work, getting people to converse, reflect, learn, improve their understanding, make sense of the lessons and change their behavior, is the KM stuff.

Kaye Vivian

Hi Denham, Nice post, thoughtful comments. And thanks for referencing my work.

While I agree with most everything you said here, I'm out of step with you on one point:
"...The key is not the difference between information / data and knowledge but what you do with this distinction."

I am not sure that "what they do with the distinction" is in scope for knowledge management. (But maybe it comes down to how you define KM) Does it matter what they do with it? (well, it does to them obviously, but does it matter to the KM practitioner?) It seems incorrect to me that KM practitioners should be evaluating what workers might "do" with information created or knowledge gained. Isn't that more an issue of business application or community relevance than a scope of KM?

I believe you are saying that it's important for knowledge to be reused/shared in order to produce value for the community or organization. Am I right? That's slightly different than saying a criterion of KM is "doing something" with the distinction between knowledge and information/data, though.

These are valuable discussions because they help us to define our scope and make clear to ourselves and others what KM is. Perhaps I'm whipping an old horse here, but I still feel strongly that until we can all agree on definitions for knowledge, information, knowledge management, etc. we will continue to spin our collective wheels and be fuzzy. Widely agreed definitions are sadly needed. I've written about KM definitions recently, especially here


(if anyone's interested to continue that discussion! :)

Thanks for your thoughts. They are insightful, as always.

Shawn Callahan

Hi Denham, your right when you say we glossed over or missed key concepts. I think we did too but it's important to remember the intended audience for this paper: people who have just come into contact with knowledge management and want to get some basics under their belt to make progress. This is what our clients were asking for.

This paper is less useful for highly experienced knowledge management professionals like yourself.

Given that context do you think there is anything in the paper that would lead someone astray? I'm keen to hear your thoughts on this.

Thanks again for noticing our work and taking the time to comment on it.

The comments to this entry are closed.