Knowledge management tools that aren’t tools

This article by Neil Olonoff discusses the conundrum that can be faced with the implementation of knowledge management tools that are supposed to make managing knowledge assets easier but which, in reality, can create more complicated workflows. Olonoff focuses particularly on SharePoint, which is the system we use in my institution. Olonoff argues that:

We call software a “tool,” even though you can’t turn a screw or lever a log with it. That’s how symbolic and abstract work has become. But the basic idea of a “tool” — a utility external to our minds and bodies — remains. It’s still something that’s supposed to make work easier. So this becomes a very useful heuristic for gauging the effectiveness of knowledge management methods, and, dare I say it, tools. When something demands more effort and time and expense than the way we did things earlier, i.e., before [the] introduction of the New Tool, then that utility is simply Not a Tool!

Certainly, in the case of my institution, the roll out of SharePoint has not been what I would call particularly successful. Many units do not have a SharePont site, even though the institution adopted the software three years ago.  I’m always a little leery when implementation and maintenance of knowledge management software resides primarily in the hands of information technology departments, who might not have sufficient understanding of how to manage knowledge assets, implement proper metadata, ensure proper flow of records, maintain retention schedules, and so forth. I have encountered a fair degree of resistance to using SharePoint amongst colleagues because, to quote Olonoff, the new tool doesn’t meet the basic definition of a tool. It makes them work harder.