All Life Is Problem Solving

Joe Firestone’s Blog on Knowledge and Knowledge Management

All Life Is Problem Solving header image 2

Some Quick Thoughts on Reasons for KM Failure

April 25th, 2009 · 1 Comment

turnerfisherman

Recently, John Ragsdale offered his view on the top five reasons for KM failure, in a blog post currently being discussed at AOK’s Future Center. My reaction to Ragsdale’s blog is that it seems to assume that a KM intervention is primarily about technology. So he gives us reasons like: “Expecting the KM technology to create a process where none exists”; don’t hard code “broken processes into new technology”; “lack of participation”; “lack of adoption”; and “lack of maintenance.” In my view, these are not the primary reasons for KM failure. In fact reading the article, I received the distinct impression that Ragsdale is talking about IT systems directed toward content management, rather than interventions designed to enhance knowledge processing. In short, from my standpoint, he’s not writing about KM at all. Of course, I have my own thoughts about the relative success or failure of KM initiatives, and here are a few quick ones, in the absence of a serious attempt to compile a list of primary reasons or factors.

1) I think the most important reason for failure is that we really don’t know much about the relative success of KM projects. That’s because we really don’t have a consistent idea, from a disciplinary point of view, about the nature of KM. As a consequence, we know that projects, programs, and interventions carrying the label KM frequently fail. But we don’t know a) what percentage of these are really KM projects, as opposed to just information management, IT, content management, customer relationship management, organizational development, or other types of efforts and b) we also don’t know what percentage of KM efforts performed under the labels quality management, or innovation management succeed or fail. Until we have a much better handle on the track record of KM it will be hard to draw definite conclusions about the primary reasons for failure or success. Noting this lack of knowledge, I’ll now go on to hazard some guesses about why KM projects might fail.

2) One reason why a project might fail is that it may not be performing KM. For example, if you think you’re doing KM, but you’re only facilitating information sharing, your impact on behavioral outcomes may be much more fuzzy and the perceived benefits from your efforts much less impressive. Also, if you think you’re doing KM, but you’re really doing Community of Practice (CoP) creation and maintenance, you may succeed in creating large numbers of CoPs, but you may also find that you’ve not had much influence on the day-to-day operations of your organization. Further, if you think you’re doing KM, but you’re really doing an IT application that records past successes in your organization, you may find that such a best practices system is ignored by people encountering new situations that seem to present unique challenges and is therefore perceived as a failure. In other words, to be successful at KM, I think you need a coherent view of it that can guide you in developing approaches, strategies, policies, programs, and projects consistent with that view. When people who undertake KM don’t have such a view they can easily develop these things incoherently and inconsistently, so that the various components of a “KM” program contradict and conflict with, rather than reinforce, one another. We also have to remember that any definition of KM has implicit within it a view of the general influence relationship between KM and business outcomes. When one’s KM view is incoherent, this implicit relationship is likely to be false. So when an initiative using such a conception is implemented, it may very well fail precisely in the sense that its expectations won’t match reality.

3) The relative absence of knowledge processing metrics in KM. We can track our own actions and expenditures in KM and keep metrics on those things, and we also know or can easily find out what kind of business process and outcome metrics exist in our organizations. But we don’t have good measures of our performance in seeking, recognizing, and formulating problems, solving them, and communicating the solutions to others who might need them. The relationship between KM activities and business processes and outcomes are indirect. Our impact on them is through our impact on knowledge processing. Until we have good measurement models, metrics, and indicators of the various aspects of knowledge processing we can’t really trace the impact of KM through knowledge processing and its outcomes, to business processing and its outcomes. But until we know that impact, how can we really know whether KM, in a particular instance, is succeeding or failing?

4) I think we need much better models in KM than we have. There’s very little formal modeling or computer-based simulation in KM, and very little work, in general, that aspires to science. We need more of that.

5) I think KM projects may fail because we don’t conceptualize our efforts in relation to holistic approaches. It seems to me there are three primary holistic approaches in KM: the decision interruption approach, the expectations gap approach, and the ecological approach. I’ve outlined two of them in a KMRP article, and all three in a recent blog post.

I’ve only begun to scratch the surface of this so far. But I think that’s enough for now.

Tags: Complexity · KM Methodology · Knowledge Integration · Knowledge Making · Knowledge Management

1 response so far ↓

  • 1 jragsdale // Apr 25, 2009 at 11:13 am

    You are correct, my focus is knowledgebases for technical support operations, not overall corporate KM initiatives. I was specifically addressing why companies do not receive ROI for new knowledgebase implementations, based on what I saw implementing KBs for a couple of years and covering this space for a decade. Thanks for the interest!