Knowledge Management

Knowledge Management

I've been going through some of my old University papers, and had completely forgotten that I'd wrote one on knowledge management systems. I have some thoughts on what I was taught.


It's a little funny, looking at the optimism of both the course material and myself at that time. The way KMs are presented is one where they are simultaneously the Library of Alexandria and a complete necessity to even the smallest of businesses.

I suppose in a sense, that's true. Businesses need processes and procedures. But most small businesses (I'd expect) use the collective experience of staff as their KM, rather than some ITIL-approved software package. It isn't really debatable which is better - you can't easily index, search, back up, or restore experience. But one is the product of organic development - it's free, and easy, and requires zero buy-in. The other can only come from time, money, and persistence.

But yes; the material was very much written for a perfect world. Of which we are not occupying.


My views on how best to implement a knowledge management system have changed. Whereas ten years ago, I'd argue for an organisation-wide push where each and every user is also a contributor - now I hold a very different opinion.

Consider a wiki. Not difficult to set up and manage. Everyone can use it. You have complete buy-in from management who have directed other teams to contribute.

And then you read some of the articles contributed by other teams. They skip details here and there. The articles are perhaps untagged. Some pages are stubs that say "Ask Dave". Inaccuracies abound. Hell, some pages link off to another KMS that team had been running for a while. The value of those contributions is debatable.

To be clear, this isn't about shitting on people who have more important things to do than documentation, or even people that dislike documentation. It's about recognising that quality of output is variable. That the intention behind the documentation is relative to the team the author works within, or how the author understands the requirements given. That sharing a language doesn't mean sharing terminology.

Academically, these properties should be handled in some sort of process prior to writing the article. In practice, that's not how it works, at all. The amount of time it would take to define the minutia is unfathomable - and that time costs money. So instead, steps are skipped, priorities shift, and islands of endemic knowledge begin to form. The KMS is usable but vocabularies differ. An 'internal reference' is a 'DDI' is an 'IAX ID'. Between the islands are impenetrable oceans that prompt duplication in the native dialect of the team trying to understand another's.

Silk Roads

This is where I differ from academia (at least as it was in 2011). The solution is not, in my experience, top-down direction, or working-groups, or for one rogue to go-it-alone and attempt to write an encyclopedia. The solution is to give up, accept that teams are islands, and to instead encourage trade as a means to improve-but-not-perfect. Therefore, with leading words that make my list look like a self-help guide:

  1. Establish borders within the KMS. These pages belong to Team A. These pages belong to Team B. Ownership needs to be clear, because we're going to change it where necessary.
  2. Identify the trading posts of each team. Goods travel between teams. Tickets, questions, work. These things leave teams through one trading post, to come in to another. Sometimes they get sent back, sometimes they get sent on.
  3. Classify those goods. What pages do they relate to in each team? "This type of ticket relates to Page X (Team A) and Page Q (Team B)."
  4. Nationalise the pages. This could be as simple as concatenating the pages so there's a section for Team A, and another for Team B. Or it could be a rewrite by one person from each team. What matters is that the page belongs to a higher power than the team.

In practice, what I'm suggesting isn't too dissimilar from turning teams into classes, their processes into methods, and the information that passes between teams into parameters. And to do that in a progressive way that shuffles towards more closely integrated documentation.


I do not, to be clear, exist under an illusion that this is some sort of axiom. That I've cracked the problem. But the results do seem better than what you get when you (blindly, I suppose) try to implement KM in the way prescribed by academia. Really, I have no idea if this works at scale - I'm just a system administrator trying to make the documentation I read and write more useful.