Knowledge Management (KM) is a much newer profession: it became a discrete discipline in 1991 with the publication of The knowledge creating company by Ikujiro Nonaka in the Harvard Business Review (which you can read online at HBR here). Although philosophers have studied knowledge for millennia (Plato was writing about it in Ancient Greece nearly 2500 years ago, and he was almost certainly not the first person to do so), they weren't studying it with a view to making sure people captured and shared their knowledge, which is the main goal of a KM professional. Philosophers were, and still are, more concerned with what knowledge is and the difference between certainly, belief, knowledge, etc, and although that's very interesting from an intellectual point of view, it's not overly helpful in practical terms. KM doesn't have the history of technical writing, nor does it come from the intellectual highlands like the study of syntax and semantics do (both of which are key to effective technical communication).
And yet because documentation now comes under the auspices of KM in many places, so must technical writing and therefore technical writers. This makes sense, because if the goal of a knowledge management system is to make sure that the knowledge in people's heads is captured and shared, then you will need technical writing skills to document what is captured. And in those places where technical writing is not explicitly line-controlled by KM, perhaps because there is no explicit KM function or because KM and technical writing come under different reporting lines (e.g. product management and development), it's still hard to see how you could implement a robust KM programme without your writers being involved in some way.
This though begs the question, does it not? of whether KM is actually just a fancy phrase for technical communication. The goal of technical writing - to explain, elucidate, inform and teach through the medium of written documentation - is one of knowledge transfer through capturing and sharing knowledge. A Documentation Manager will be responsible for, amongst many other things, laying down standards for information capture, such as information from developers about issues they've fixed; it is a short hop to say that these standards should be slightly expanded to include the capture of other information that needs to be written down somewhere, even if it won't go into explicit documentation sets targeted at specific users.
Of course, KM has its own language: You encourage knowledge sharing, with the aim of building a knowledge ecosystem, a place where the codification of knowledge is performed collaboratively by expert practitioners who can explain and illuminate both their explicit and implicit knowledge, with the ultimate target of having a complete record of the output and metadata of your human capital. KM experts will make references to culture, process and technology forming a tripartite foundation on which a company's knowledge management programme will stand strong for decades, or crumble into the dust.
But such language is often just a label for a more complicated concept, a short cut for adepts to use in cultured conversation. The technical writer, when talking about the use of DITA in a single-sourcing environment as part of a content management strategy, is doing no different. These languages should not be mistaken for the practises themselves; the language may be a point of difference, but that doesn't mean that the practises of a KM professional and a documentation professional are therefore automatically different. A "punt" in American Football is no different to a up-and-under in Rugby Union (the synonym "huge Garryowen" - thanks to the late, great Bill Mclaren - is also identical in practise).
The practises of technical communication and the practises of KM, especially when viewed through the different lenses of their languages, may seem divergent, particularly for the practitioners of each, but the goals and intentions of technical writing and KM are almost identical. The practises too, cover a lot of the same ground: information gathering, analysis, writing and sharing the result of that writing. However, there are differences between KM and documentation, and the two primary ones are:
- Scope
- Responsibility
Related to this is the level of responsibility. A technical writer normally has responsibility for creating content themselves, whereas a KM professional has responsibility for getting others to create content. Both cases are value multipliers, because the technical writer makes public that which was previously private and the KM professional does likewise, but the KM professional does it by making as many people as possible into value multipliers by getting them to create content and share it.
Whilst it might seem that the KM professional is therefore more valuable, it is also the case that with this increased reward comes an increased risk. Content that is created by people who are not trained documenters can be confusing, inconsistent and incorrect; it rarely follows standards for terminology and structure, and tends towards the scattershot approach of "write everything", which means that users have to work hard to sort the wheat from the chaff. Whilst these problems can be ameliorated to an extent by documentation tools that force users to do certain things (such as templates, mandatory metadata entry, obligatory skins and formats, and so on), there is only so much that automation can achieve. The return on investment of hiring a professional writer to produce documentation, or at least the most critical documentation, cannot be underestimated.
Another interesting, although perhaps localised, difference is that KM is often seen as a more dynamic role than that of a technical writer. KM is a collaborative exercise with collective benefits, as opposed to being a job for a specific team, like technical writers, which the collective doesn't always recognise as worthwhile. This shines a light on part of our psychology: Everyone wants documentation when they don't know something, but few are willing to create documentation that explains what they already know. In a good KM programme, there is an acknowledgement by the majority that if each individual documents their knowledge then everyone will benefit. Therefore it is in the interests of the individual to contribute, especially if there is any sort of public register of those that have and haven't contributed. On top of this, the idea of a gift economy comes into play, and people who have the knowledge often like to give it away as an act of largesse to show how much they know. (You may call this ego if you wish, but for me that's too pejorative.)
Where there is a specific documentation team, there is generally no sense of people using a gift economy. It can become a chore for people outside of the documentation team to have to write things down, because they only see the benefits to others, not to the collective or to themselves, even though the outcome is largely the same. It's as if they feel they are doing the job of the technical writers for them. For this reason the KM programme's emphasis on collective responsibility can be more effective. I won't say much on this here, but I leave it as a point of interest for those who think about such things.
In conclusion, KM and documentation are not the same thing. Where both are present, documentation is one part - albeit the most critical part - of the KM process. KM can be seen as a framework in which documentation sits. Of course, this isn't the only framework and a KM programme is not required in any way to give value to documentation. But where KM and technical writers work together, KM should provide the direction and culture, and technical writers should provide some of the content and make sure all of the content forms a coherent whole.
As always, your thoughts are welcome in the comments section.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.