Jim McGee writes about Knowledge work as craft work (also here) and the importance of the process of crafting knowledge as well as the final output. Focusing on the output - a report or presentation, say - loses the thread of thoughts and alternatives that were considered in reaching the final recommendations. This is a loss to those who only see the final output, to colleagues, and to knowledge workers themselves.
This is a difficult point to get across to organisations thinking about implementing knowledge management - particularly when they have a bias towards publishing explicit knowledge rather than sharing and exploring tacit knowledge.
I find that people can readily grasp the idea of sharing the outputs of knowledge work. A simple example: John knows the three best software applications in his field, so he writes a document with the names of the applications, the contact details for the vendors, maybe a note about which one to use in which circumstance. This is concrete information that can be passed around the organisation and easily used by others. No-one has to worry about sourcing this type of software any more - no-one has to think about why this application is better than that.
But then John leaves the organisation, a year passes, one of the software vendors goes out of business, the other two release new versions, and there are several new entrants to the field. Now which applications are the best? How do we decide, what do we look at, what's important and what's peripheral, what features do the users want and what's just marketing hype?
Because the process of evaluating the software applications has been lost - possibly even to John who's forgotten why he made those recommendations - the organisation has to start from scratch to learn how to evaluate these issues. And it has to do this again and again across innumerable issues in many different contexts. It is a continuous, repetitive process of learning and forgetting, re-learning and forgetting once more. The cost and the loss of opportunity to both the individuals and the organisation can be huge.
The arguments used for a publication model are simple to understand and hence quickly adopted by many organisations: we need to maintain quality so we want well-polished documents; it's hard to get people to contribute, so getting them to note down their conclusions is better than asking them to capture their thinking; we don't want people wasting time going over old ground, we just want them to get the answers.
For individuals, there are also compelling arguments to focus on outputs: I don't want people to see all the wrong turns and dead ends in my thinking; I don't want people to know that I am fallible and don't have all the answers; I don't want to share my thought processes because it weakens my position - once others know how to do this, it lessens my value; no-one reads beyond the executive summary anyway so why waste time with the background.
These arguments are seductive because they have some value: sometimes you do just want the answers and don't have time to understand the process; yes, quality is important as it engenders trust in both the person and the output; yes, people are short of time and getting something out of them may be better than nothing. Organisational agility, quality and inclusiveness are all important factors that a knowledge system should support.
However, they're not the full story. What they miss is insight and understanding, either transferred from one person to another (eg by apprenticeship) or developed as a team and hence spread out into the organisation.
The industrial approach to knowledge management treats knowledge as a product - it can be standardised, rationalised and distributed more efficiently. The craft approach that McGee discusses treats knowledge as a process - it is contextualised, changes over time, is hard to pin down and is exchanged through inefficient conversation and practice. Unfortunately for the industrial approach, the benefits are often in the inefficiencies and redundancies, in the time it takes to think through and around a problem to genuinely understand it, to see the options and opportunities, to act with insight.
As McGee says, there are advantages to both the industrial and craft approaches, to knowledge as product and knowledge as process. The challenge for an organisation is to get the right balance between the two and not to take the easy route of treating knowledge management as knowledge publication.
Why is that route easier for many organisations? Because it doesn't require a cultural change - it fits within practices that organisations are comfortable with. Publication is a respectable model: you only have to look at the mainstream media to see how successful and how 'business-like' publication is. It is easily centralised. Journalistic standards can be applied by a trained core team. It is efficient. It is easily converted into technology with well-known architectures - information management or document management are familiar domains. It is easy to count: this many articles read by this many people. It is about answers not questions, standardisation not innovation, publication not collaboration.
So how can we move an organisation from the corporate safety of publishing knowledge products to also adopt the more open-ended, long-term approach of sharing knowledge processes? Senior management buy-in is the key factor. Knowledge projects that are sponsored at a departmental level can play their part and they can certainly work well within smaller teams or communities. But to broaden KM out to the whole organisation requires both the right culture and sufficient opportunity to learn and communicate - which means that roles, targets and remuneration must be designed to accommodate a certain amount of creative slack.
This is, of course, a well-rehearsed argument in KM circles: get executive commitment because KM will require fundamental changes. At a more practical level, what assistance can we give individuals and teams to capture the process as well as the product, with or without executive commitment? This is an issue I'm working through with a client and I plan to come back to this soon.
(Thanks to Lilia Efimova at Mathemagenic for the link to Jim McGee's article.)
2:34:04 PM 
|
