During the research phase for this book, I did a straw poll among friends and business colleagues, and asked them what are the most frequent barrier statements they encounter. It quickly became clear that most of the excuses they, and I, hear for not implementing a wiki come from misconceptions and prejudices about wikis rather than actual shortfalls in the wiki technology.
It also became evident that the barriers fall into two distinct categories: cultural and technical.
Some cultural barriers are based on assumptions and hearsay that originated in media reports about Wikipedia; others are rooted in bad experiences caused by a rush to implement. Often such barriers will inform later decisions, even though it only takes a little research to address and eliminate most cultural concerns.
Here are some of the most common “BUT” statements I hear in this category:
There is a general perception that because wikis can be edited by everyone, that for a wiki to be successful everyone should contribute. Numerous studies show that no matter the technology, any collaborative project or social group will be the product of a small vocal minority. In the case of wikis, it appears that a 90-9-1 rule applies, where 90% of the user community will access the wiki just to find and read information, 9% will contribute something, but only 1% will be active contributors.
For corporate wikis with a clearly defined business purpose, the number of occasional contributors may rise to 30%, and active participants may rise to around 10% of the community. When setting up a wiki, define what an acceptable, but realistic, level of usage is and over what time scale. It can take time to build a community, and getting people to contribute needs encouragement. As with all other cultural barriers, the potential user/contributor has to see a perceived benefit from the activity.
One common statement I hear when discussing wikis in a business environment is the view that, “the application of a wiki does not offer enough benefit to justify the cost of maintaining it.” I’ve heard this same sentiment voiced several times in different ways. Yes, to be successful a wiki does need maintenance – it needs someone with a sense of ownership who will do various administration tasks, such as cleaning up content and installing software updates.
But this is true of any software application. In fact, it’s true of nearly all sources of information in business, from the most complex database system to the humblest of spreadsheets. To remain relevant, an information source has to be maintained. If you’re going to judge any information system on its benefits, then you need to clearly define how those benefits are to be measured and what makes an acceptable return.
In the case of an information and collaboration system like a wiki, such measurements may not be as straightforward as a financial return on investment, because they may have more of a subjective social impact. But even so, a desired outcome needs to be articulated, and you need to be realistic.
A statement like this is not just about wikis; rather, it’s an indication of a fear of change – any change. The biggest challenge here is not a technical one, it’s one of managing change and educating the potential audience about how the new technology or process can make their day-to-day job easier.
This is invariably an indication that a new piece of technology, which may or may not be a wiki, has been introduced and its use was mandated without training or with no clear introductory project or need defined. Technology for technology’s sake is doomed to failure.
The problem is often made worse when it is introduced by excited and enthusiastic technology geeks who overwhelm potential users with techno-babble and a “look at all the cool things this can do” attitude. With any new technology, you must first define a clear need and then map out a slow, step-by-step introductory process where benefits to the user community are clearly articulated. Start small, build familiarity, and growth will follow.
A very good question, and once again one that applies to new technology in general rather than wikis in particular. As with any technology, if you can clearly demonstrate the things that appeal to management / business owners, such as a measurable benefit, lower costs, and improved efficiencies, then you will start to get their attention.
One of the most interesting observations of the recent growth in the adoption of wikis is that they demonstrate this exact process. The majority of wiki implementations start with small teams, and once others begin to see the benefits, adoption spreads across the company; only then does management buy in.
It’s also worth mentioning that in the opposite scenario, where a management team instigates the implementation of a wiki, the management team should be active participants. Mandating any technology and then not using it yourself is a clear indication that you have no real personal investment in it.
One of the most common and oft-repeated misconceptions of any collaborative authoring process in general, and wikis in particular, is that if a large group of people are contributing, then the influence of subject matter experts will be diluted and the resulting content will be full of inaccuracies. As noted previously, even an open, collaborative system will only attract a statistically small number of contributors. Those contributors tend to be the subject matter experts and people who have a vested interest in the subject matter. And when inaccuracies do occur, they are corrected a lot quicker than in traditional media. The net result of collaborative authoring is not only the perceived knowledge of designated experts, but also the informed contribution of others who are passionate about a subject and can bring a fresh perspective.
The best collaborative environment is the face-to-face meeting, because we communicate not only with words, but with tone, inflection, and body language. But, face-to-face meetings are not always practical, especially for a distributed team. In such instances, a collaborative workspace of any kind can be a real benefit.
Even for co-located teams, a collaborative workspace where meeting preparation and briefing documents can be compiled, reviewed, and commented on before a physical meeting can make the face-to-face sessions more efficient and productive, as participants should arrive fully briefed and aware of other participants’ viewpoints.
A wiki can also be the place where the results of a meeting are communicated to non-participants and where action items can be recorded and tracked.