I recently read Stewart Mader’s Wikipatterns, over several long plane trips, which I highly recommend. That is the book, not the plane trips. Not that it takes that long to read but I took it in bits, between other things, like editing my trip pictures and reading, Suite Francaise by Irene Nemirovsky (alos highly recommended). Anyway, this was better to space out reading Stewart’s book as it is a great guide to go back to. Parts of it also took me back ten years ago to promoting knowledge management best practices. I found it interesting to reflect on the differences and similarities between a top down system that required bottom up support and participation (aka KM) and a system that requires bottom up support and participation and offers a bottom up structure (aka wiki). Now you might say that a wiki is a tool and KM is an approach. However, it seems that wikis are also very much about an approach, more than just a tool, and KM relied on tools to enable its approach. I think more comparisons are valid, especially since both are about content.
You can find a good general review of the book in at the Fast Forward blog, see wikipatterns - The First Enterprise 2.0 Playbook by Jevon MacDonald. I am going to cover my comments on the book in four parts and mainly draw comparisons to KM. I am going to start with Stewart’s excellent list of possible wiki uses. A wiki is a system for generating and organizing content and you can use for a KM system. However, because of the bottom up structure you can use it for many others things such as the following suggested by Stewart.
I took his uses and grouped them into three themes that represent what I think are the best functions for a wiki
1. Generating Ongoing Growing Lists of Content:
Knowledgebase or Support Site
2. Group Work:
Document Creation (actually not on his list but this use is discussed and the book is an example)
3. Communication Platform:
Intranet or Extranet
Pubic Web Site
Knowledge management is really only about the first theme. I found that the knowledgebase works best when it is aligned with a business process (a work support site) and I assume this would also be the case with a wiki. I know of at least one instance where a general purpose wiki had trouble getting traction in an organization that uses wikis extensively for project related tasks. Of course, the products of the second theme can go into a KM system and KM can be contained within the second theme. Wikis have the potential to change the role of administrator as they lower the barriers to contribution. Administrators function more as monitor than gatekeepers as contributions do not go through them. However, administration does not go away. Even the wikipedia has to monitor and sometimes lock down on content disputes. Stewart gets more into behaviors with the patterns and anit-patterns I will cover in upcoming posts.