Writing for a Wiki – Wiki Diversification and Strangulation

Given the recent implementation of a 3 separate wiki’s (using MediaWiki) within the same company, it has become apparent that people are simply not used to working collaboratively.  We have three departments using the same wiki software you find on wikipedia.  For the sake of confidentiality, lets refer to the departments as Support, DevelopmentProject1 and DevelopmentProject2.

In all three instances, there are a range of different behaviours (human) when it comes to updating the wiki.

Scenario 1….Support 1

In Support1, the approach to documentation is such that it resembles a bureacracy.  They commissioned the development of the wiki as a primary information source for the running of their department and given that the nature of their business is ‘support’, the wiki contains procedures, background information about systems and a range of troubleshooting flowcharts.  In this instance, there is anxiety about just how much the information on the wiki can be messed with. To this end, two wiki masters were designated as the ‘master updaters’ of the wiki… I hear you all gasp – “that defies the whole object!”

Scenario 2…

In DevelopmentProject1, this department has been broken into a range of different teams, each handling a sub-set of projects and maintenance tasks for a set of systems that churn information on a 24/7 basis. The approach to the wiki has been one of random information capture, when and where it is deemed necessary.. some empty their emails into the wiki as if it were a bucket…. In this wiki, there have been some structure imposed in that the wiki has been divided into Teams and Products that is, the Wiki front page has been divided into TEAMS and PRODUCTS.

From here the organic growth of pages has been left largely to those who wish to contribute at any time they feel necessary.

 

Scenario 3…

In DevelopmentProject2, this department is developing a range of components for a national monitoring system. It is a development project that is considered cutting edge and the information depositing has been nothing short of random and haphazard. Contributions are at times just dumped into the wiki with no apparent organisation or consideration for the end reader.  As a result, uptake has been minimal.  Compounding the problem is the fact that several other incarnations of wiki (Twiki) abound so fragmentation of wiki’s have led back to the number one problem a wiki was designed to solve in the first place.  Wiki users now not only have 3 implementations of wiki in 3 different departments to refer to but also a number of different types of wiki to refer to, each with their own editing rules. These include Mediawiki, SharePoint Wiki and Twiki Wiki.

In hindsight with clarity, the only conclusions I can draw from this situation is as follows:

1. When implementing a wiki in your organisation, it should span all departments. In other words rollout ONE wiki that everyone can use from the outset. Avoid using multiple types of wiki software.
2. Educate users on how to use a wiki effectively in terms of information capture.  By this I mean that the wiki should not be used as an information dump (thus rendering it unwieldy and disorganised) but train users to consider their potential audience and to apply a little discipline when it comes to structure of the contribution.
3. If a wiki is intended to be used for procedures that affect business continuity, consider using SharePoint Document Libraries for that purpose and take advantage of its inbuilt document control procedures ie. Major and Minor Versioning, Security and Audit Trails.
4. Be aware of ‘wiki strangulation’. The original intention behind the wiki is collective collaboration not one or two ‘masters’ vetting every piece of information that appears on the site. This behaviour diminishes the wiki to the point where the power of this synergistic tool is lost.