Knowlege sharing’s day of reckoning, sort of

I took a bit of issue with the innocently introspective KMers that Brad Hinton was writing about earlier in the week… and here comes Wharton University and publishes a research paper apparently calling into question the effectiveness of «knowledge sharing». And this really irks.

I’m not quarreling with the study in itself (I’ll be trying to read it later and I’m sure it’s better than advertised) but with the sensationalist presentation. Wharton’s article states that «research by Wharton management professor Martine Haas and Morten Hansen, professor of entrepreneurship at INSEAD, indicates that knowledge sharing efforts often fail to result in improved task outcomes inside organizations — and may even hurt project performance.» Scary stuff. Then they continue: «However, organizations that plan carefully before launching a knowledge-sharing initiative, and support these efforts along the way, have a much better chance of adding value, the researchers say».

In Spanish, when someone states the obvious or goes tautologically enlightened (i.e. not just states the obvious but also shouts it from the rooftops as if it were world-changing breaking news, we say they’ve gone and rediscovered the wheel. This people apparently have.

It irks more because, back in the days when I sold CRM strategy projects, our presentation always featured a slide that said that an impressive percentage of CRM implementations were failures… because of a lack of serious planning and support. Such as can be gained by, guess what, hiring outside specialists.

It’s hard to find kind words for blindingly obvious statements like: «the types of knowledge shared and the design of the organization’s project teams are likely to influence the success or failure of a knowledge-sharing effort (…) In fact, project teams that are badly designed or use the wrong type of knowledge for their task can see their performance suffer rather than improve as a result of efforts to use knowledge from other parts of the organization.»

But it gets better (irony intended). Apparently the paper identifies just two «distinct» ways in which knowledge sharing usually occurs in organizations. «The first way is through direct contact between individuals, typically when one person advises another about completing a specific task (…) The defining characteristic of this mode is that the handover of knowledge requires direct contact between the provider and receiver — through meetings, by phone or via e-mail. (…) Direct contact allows for the transmission of tacit or non-codified knowledge that may be difficult to put in writing. (…) In contrast, another way to obtain knowledge is through the use of written documents available from databases or libraries. This mode is appropriate for knowledge that can be readily codified, including certain procedures and other data.»

So it’s either personal contact and focused one-to-team conversation, or searchable libraries of reusable documents… Let’s see, anybody here can name any semistructured knowledge-sharing mechanism useful to make organizational knowledge available to team members, without either direct personal contact or extensive formalization? What was that again? Did you say forums? Wikis? Anybody else? Domain clinics. Blogs, yes. OK, there’s more but that’ll do for now.

Mind you, that doesn’t mean they’re not right: the first two distinct knowledge sharing methods also work. They’re simply not the only ones, and they’re the most time-consuming and expensive. Which shows in the next parts of the study, apparently (so the article says), when they go on to analyse the costs imposed in projects by those types of collaboration, and find that they are high.

It’s not news, but it doesn’t hurt to have someone point out the time costs of having an expert come help each team that does a project in its field… or the costs of building and adapting reusable knowledge objects. They’re both high. Especially the first one, which is the reason companies deal with it with «pre-sales consultants», domain specialists who help design a solution that can later be implemented by the team. Also, the cost of turning project documentation into reusables, and keeping them updated, is high and (especially at first) uneconomical; the fun part is that as the documentation practice scales (more people doing it, more projects documented) the probability of it being useful and reusable grows, and the cost of the new projects decreases. Of course, if you never do two projects alike, it’s mostly wasted time. Common sense should be involved somewhere.

Yes, as the study suggests, it’s also conceivable that someone would attempt to use an inappropriate reference material and thus decrease the team’s efficiency. Or that the material is so obsolete that it’s not useful and needs substantial updating… which, if done, can add cost (see previous paragraph) but will be effective if the material is really likely to be reused. Common sense, again, is required to judge the cost effectiveness of this.

The authors thus manage to avoid including good sense and semistructured options in the study. And they go on to say that «We find that using codified knowledge in the form of electronic documents saved time during the task, but did not improve work quality or signal competence to clients, whereas in contrast, sharing personal advice improved work quality and signaled competence, but did not save time.» I can’t really quarrel with the second: it’d require either imposing on busy people’s times, or -worse- bloating the project costs. But the first is utter and plain nonsense.

The whole point (well, most of it) of reusable knowledge objects is to improve work quality by increasing the use of approved and consistent good practices. Templates, guidelines and reference materials improve the chance of achieving a high-quality result; indeed, simply by providing an ordered, sensible report framework and a clean consistent image, they can also improve customer satisfaction… but they also arm teams with building blocks to work faster at some other phases (project design and scheduling), avoid mistakes (activity or item checklists) and quagmires (legalese boilerplate about confidentiality, intellectual property, warranties and working conditions). A good offer (good enough to rate as a reference) can be cut and pasted and modified to produce a sterling-looking, detail-perfect document in less than a tenth of the time of a brand-new one, and it will be better too in consistency and quality aspects. Yes, some types of «reusables» may not be that useful… but then, someone should be fired for not having domain knowledge and common sense enough to tell the difference.

Then the authors are reported to go on to state that «While part of the challenge is to use knowledge appropriate for the task, (…) organizations also face the problem of setting up teams in ways that help them take full advantage of the knowledge they use. (…) many project teams in knowledge-intensive organizations operate in environments than can interfere with their ability to perform well because they are characterized by overload, ambiguity and politics.» Which rates as another big bloomin’ rediscovery of the wheel, but…

Well, I won’t bore you further. The rest of the study’s presentation is a list of rediscovered wheels, some trite to the point of practical irrelevance, that have (yes, they do) bearing on the ability of teams to make use of organizational knowledge. Yes, they’re obvious… but yes, they make sense. They end up mentioning earlier research and insights by the authors.

You can download the actual paper here. I really look forward to finding that it reads better than it’s presentation. It deals with a very serious aspect of KM implementation. It’s been done by reputable scientists. But it’s simply been presented as sensationally as possible, with an article that attributes it serious flaws.