There are a wide variety of uses for Wikis and a level of interest in using them that’s matched by an extensive range of Wiki software. Wikis introduce to the Internet a collaborative model that not only allows, but explicitly encourages, broad and open participation. The idea that anyone can contribute reflects an assumption that both content quantity and quality will arise out of the ‘wisdom of the crowd.’

There are, however, negative effects of this extreme openness. One problem is the deliberate vandalism of Wiki pages. Another is that even those with no destructive intent may yet degrade the quality of a Wiki’s content through lack of knowledge or skill. Anyone can write nonsense as though it were fact. Anyone can accidentally delete useful information. Someone with half-baked knowledge of grammar may change all the “its” to “it’s.” Of course, someone more knowledgeable may notice the problem and fix it … but then again maybe they won’t.

Wikis can impose various forms of control to protect against these risks, including user registration, moderation, enforced stylistic rules, and imposing prescribed topic structures and page layouts. These types of control, however, are typically seen as contrary to the basic Wiki concept.

Consequently, one of the central tensions when managing a Wiki is between centralized control and anarchy. In the public arena, the balance of power tends towards anarchy, but in a corporate environment a more centralized approach is often required.

In this article I describe one application of the Wiki way to a common corporate process and extract some guidelines for the effective use of Wikis in that context. In particular, I am seeking insight from this case study into the “balance of power” tension.

The example on which these reflections are based is a project within the software company CorVu [1] to improve the technical knowledge base related to the products we sell. Like many companies, CorVu has extensive knowledge of its own products and a desire to make that knowledge available to customers. A major block to achieving that desire has been a lack of people with the time to either record the internal knowledge or to fashion the knowledge into a customer-ready format. We needed to spread the load so that a broad range of developers, tech writers, professional service consultants and others could all contribute what time and knowledge they had to a shared goal. Our hope was that a process built around several Wiki sites would facilitate this collaborative approach.

There’s no guarantee, of course, that lessons learned in that context will transfer to others. But without documented cases such as this one, any theorizing about the balance of power issue is just speculation.

Three contexts for a Wiki

To start with, it is important to clarify the key differences between three contexts in which Wikis are used: public, team and enterprise Wikis. [2].

Public Wikis

By a “public Wiki,” I mean one where any Internet user can read and contribute to the collaborative effort. It may be that editing content is restricted to a registered user group (as is the case with Wikipedia), but anyone can register. Consequently, the size of the contributing community is potentially huge, there is a high level of anonymity, and the contributors do not typically relate to each other outside the confines of the Wiki.

In this context, very little centralized control is evident. You typically find some explicit guidelines for contributors, either formulated by the founders/hosts, or as an evolving page edited by the contributors themselves. There is also an implicit understanding of etiquette and an implied social contract that comes with joining the “community.” But in the end, anyone can edit anything … and anyone else can un-edit it. This is the essence of anarchy: not that anything goes, but that what goes depends on peer acceptance. In an anarchy, it is not the case that there is no control; rather, the control is exerted by peers (around the edges) rather than by an authority (in the centre).

Requiring registration prior to participation does not alter the anarchistic nature of the process. Registration has numerous benefits, not least of which is that contributors can be recognized and gain respect for their contributions. Registration may also increase the sense of belonging because it reflects each contributor’s conscious choice to join the community. That sense of belonging is essential to any viable anarchy.[3]

Moderation, on the other hand, inevitably moves the balance of power towards the centre. Moderation invests some users with the power to limit the contributions of other users. While moderation is sometimes seen as necessary in order to combat vandalism and dissension, this imposition of authority denies the libertarian aspirations of most public Wikis.

Team Wikis

A “team Wiki” is one where the people who read and contribute all belong to the same team or work-group. Perhaps the R&D team uses the Wiki to record evolving product specifications; or the members of a local church collaboratively documents its history; or a class of students collates the results of a research project. Membership of the team predates and takes precedence over membership of the Wiki community. A person joins the team and as a by-product may be requested or required to use the Wiki. The number of people participating tends to be small and the contributors are likely to relate to each other outside the context of the Wiki.

In contrast to public Wikis, where self-selection guarantees that the vast majority of users are technically savvy and keen to be involved, the people contributing to a team Wiki may not be doing so voluntarily or with much enthusiasm. It may well be a required part of their work that they would prefer to avoid. The need to make the Wiki as easy as possible to use becomes even more important in this context. This includes clear navigation and an effective search function, but more than anything else it means a simple, familiar user interface for editing text. Many team Wikis fail simply because the potential contributors refuse to learn Wiki markup or to use a non-wysiwyg editor.

In this context, registration is essential, but moderation is not. The restrictions on who can contribute protect against vandalism and, because the collaborators have pre-existing relationships and a common commitment to a higher cause, the community operates with a trust model. In fact, apart from the restrictions on membership, a team Wiki is unlikely to impose much control at all over contributions. Standards, structures, and conflicts will be resolved using the organization’s normal processes outside the Wiki. The collaborators will discuss and vote, or demand and threaten, or just do what the boss says, without that process being explicitly controlled by mechanisms within the Wiki.

Enterprise Wikis [4]

When it comes to implementing Wikis across a large enterprise such as a global corporation, a new set of concerns affect the balance of power. Management wisdom is required to maximize participation while keeping business objectives clearly in sight.

In my experience, it is rare that a single Wiki site within an enterprise is open to contributions by any employee. Where this is the case, moderation is likely to be required because of the large numbers of contributors who have no direct accountability to each other. The concerns at the enterprise level relate to how numerous organizational Wikis within the enterprise can be integrated into the IT infrastructure and how the use of Wikis can most effectively support corporate goals.

Rather than allow the proliferation of diverse Wiki projects throughout the enterprise, IT management is more likely to select the Wiki software that everyone is to use and perhaps host all instances centrally. It may be that some IT managers are “control freaks,” but there are good reasons for standardizing on Wiki software:

• Risk. If many work groups host their own Wiki using their own choice of software, there is a significant risk of knowledge loss. It is hard to guarantee that each work group will secure the Wiki adequately or ensure appropriate disaster recovery. What happens if the work group’s server dies? Will they have an adequate backup procedure? What happens if the work group’s IT expertise leaves the company? Will the knowledge of how to run the Wiki be passed on to the remaining team? What happens if the Wiki software no longer operates when the server’s operating system is upgraded? Centralized Wiki management can avoid such problems.
   
• Support. Most Wiki software is easy to learn (at least to us!), but some are certainly easier to learn than others. In a context where many employees participate in multiple Wikis within the enterprise, training and user frustration can be reduced by using the same software for all the Wikis.
   
• Cost. Centralized IT management can also reduce the total cost of ownership of Wiki projects. That may be counter-intuitive given that most Wiki software is free. But the costs of running a Wiki include the cost of the hardware that hosts the Wiki, the time it takes to manage the Wiki (installation, user admin and support, backup, etc.) and the time it takes to teach people how to use the system. Although these costs may be small for each work group, the total across the enterprise can be substantial, and can be reduced by standardization and centralization.

In this context, the balance of power swings inevitably towards centralized control. The challenge is how to do so without stifling the free and creative contributions that are essential to a Wiki’s success.

The CorVu case study

The company I work for, CorVu, started using Wikis within its R&D group back in 2000 using the original WikiWikiWeb software. The project described below was based on MoinMoin, but we have also used DoKuWiki and have since standardized on Confluence.

CorVu produces software that assists other enterprises to implement their strategy and to track their performance against that strategy over time. CorVu has a variety of channels for making its internal product knowledge available to its customers, but the product functionality grows at a faster rate than the Tech Writers can keep up with. Apart from the fundamental description of each feature, a complex assortment of configuration details need to be documented – performance optimization, best-practice implementation techniques, interactions with third-party software, etc. A lot of knowledge at that level resides with the Professional Services team rather than the Product Development team. Often, the people with the knowledge do not have the time nor the writing skills to record it, and the people with the responsibility to deliver documentation to the customers do not have the knowledge. There’s nothing uncommon about that problem!

Since the goal of capturing and disseminating quality technical documentation requires collaboration, I thought that a Wiki might help. So we set up two independent Wikis to capture knowledge from two different groups of employees, and a third so that customers could access a sanitized version of that knowledge.

I’m not putting my own case forward as the paradigm of success. In fact, although the project yielded a significant improvement in capturing internal knowledge, we have not yet achieved the final goal of effectively disseminating that knowledge to our customers.

Figure 1. Knowledge capture and dissemination using three Wikis

In this project, there was a clear business goal and a centrally-driven process to attain that goal. The Professional Services and Customer Wikis were seeded with pages that provided a structure for delivering accurate and accessible content to customers. While the ability to contribute was widespread, there were explicit “rules of engagement” around user registration, topic naming, page layout templates, content categorization, and navigation.

Although there was a degree of central control, we tried to balance that with encouragement for broad-based collaboration–otherwise, why use a Wiki? The distinction that guides this balance is between structure and content. Although the structure is imposed centrally, content is generated by a diverse range of people in a way that promotes openness, the recognition of contributors, editing of any content without fear of criticism, and shared responsibility for quality.

Since the quality of the documentation exposed to our customers is crucial, the process includes a QA step that is uncommon for Wikis. We did not want to constrain all contributors to adhere to strict grammar, spelling and style rules. Instead we left the knowledge capture stage free from those restrictions and used technical writers to edit the content before its dissemination to customers.

It may seem strange that we would use a Wiki to publish non-editable information, but this is a testament to the versatility of the software. Wikis provide a very fast means of building a web site, whether collaboration is the intention or not. In our case, we use one Wiki site to capture knowledge from one group of people and another Wiki site to disseminate the information to a different group of people. With regard to my categorization of Public, Team and Enterprise Wikis, the “Customer Wiki” is a hybrid: it is built by a specific team and hosted within an enterprise infrastructure in order to publish in the public arena. A more traditional approach to software documentation would have been to repackage the knowledge into some other HTML or PDF format for customer consumption. But the maintenance of that dichotomy would have been far more onerous than copying between two parallel Wikis.

Embedding Wiki tools across an enterprise is an organizational change project and as such requires appropriate planning and project management, along both technical and cultural dimensions. I won’t go over those generic processes, nor repeat suggestions for Wiki adoption that are documented in places like WikiPatterns. But drawing from CorVu’s experience, I will highlight some advice for project managers in the enterprise Wiki context.

People

1. Seek patronage at the highest possible level. That is, find a person with as much power within the enterprise as possible who will sponsor the project. The sponsor may do no more than ‘give the nod’ to your work, but that invests you with the authority to draw on other people’s time. In CorVu’s case, the CEO himself was a key supporter.
2. Enthuse a champion. This needs to be a person who is well respected, who will lead by example, and in doing so enthuse others. The champion will need to be able to put a lot of time into the project and will often be the primary contributor to the Wiki, especially at the beginning. In our case, that turned out to be myself.
3. Identify the group of people who can be expected to generate the majority of the Wiki content. These are typically subject matter experts. Discuss with them the value of writing down what they know or Wiki-izing what they have already written.
4. Identify anyone whose participation is mandatory. Is there a key political player or subject matter expert who absence from the project will cause others to think, “Well, if she’s not involved, I’m certainly not going to waste my time?”
5. Since our goal was to create a knowledge base for external consumption, it was important that the content generated by subject matter experts was checked for both accuracy and readability in the same way as other customer documentation. Consequently, the people involved in the project needed to include professional technical writers.

Tools

There are many different Wiki software tools in the market (Wiki Matrix lists over 100) but most are not adequate for an enterprise rollout. CorVu’s experience suggests that an enterprise Wiki requires at least the following:

1. Administration tools to manage a large number of users, with integration to enterprise security mechanisms (e.g. LDAP and single sign-on).
2. Separately secured spaces for different knowledge areas.
3. Effective management of attachments that includes versioning and a built-in search function that indexes the attachments.
4. Integration with other enterprise software such as portals, business intelligence, and content management systems.
5. Many contributors in an enterprise context will be non-technical. This makes it essential that the Wiki has a familiar, WYSIWYG editing mode rather than forcing users to learn some Wiki markup language.
6. An assortment of non-functional requirements such as good reputation, reference sites, some assurance of product longevity, and the availability of support.

Generating participation

All Wikis stand or fall based on whether an active community is formed. You can’t achieve the ‘wisdom of the crowd’ unless you have an active crowd. The means of achieving that across an enterprise are somewhat different from public Wikis.

1. Build a critical mass of contributors. Since the contributors are employed by the enterprise, it is possible to make the Wiki part of people’s responsibilities. At CorVu we found this to be imperative. Unlike a public Wiki (where there are many people who contribute huge amounts of time as a hobby), in a work context (where everyone is probably too busy already), this isn’t going to happen. So write it into job descriptions. Get managers to send emails to their staff saying that one hour a week should be spent writing up their knowledge on the Wiki. Arrange a seminar on how to use the system. Use the company newsletter to promote the value of the project.
2. Build a critical mass of topics. To be used, the site must be useful. To generate traffic to the site, make the most frequently required information available on the Wiki first, and make the Wiki the only source for that information. In CorVu’s case, for example, one significant page stored the latest product release information. When any software version was moved from internal QA to Beta, or from Beta to General Release, this page was updated. Once people learn that the Wiki contains a lot of useful information they will look there for answers to start with rather than wasting someone else’s time by phoning or emailing questions.
3. Send links rather than information. Set an expectation that when anyone is asked for some detailed information, the response should be a link to a Wiki page. If the information has not yet been Wiki-ized, don’t type a lengthy answer in an email; instead, spend an extra minute typing it into a Wiki page.
4. Provide recognition and rewards. As with most Wikis, the best way to encourage participation in the long term is to ensure that the efforts of the contributors are valued. This is easier in team and enterprise Wikis than in public Wikis because the contributors are known. Wiki pages can indicate explicitly who the primary authors were. There can also be rewards within the enterprise beyond the boundaries of the Wiki. For instance, some employees may have components of their annual review linked to their involvement in Wikis.

Our experience with Wikis at CorVu has been very positive and gives encouraging signs about the future potential of this approach to shared document workspaces. There are multiple offerings that meet enterprise IT standards, and the tools currently available are robust, simple to administer, simple to use, and inexpensive. The CorVu case also shows that enterprise Wikis can be used not only for internal purposes, but also as a means of publishing information to external stakeholders.

By putting minimal central control in place an enterprise can gain significant benefit from this simple technology, including improved knowledge capture, reduced time to build complex knowledge-based web sites, and increased collaboration. Although enterprise Wiki use requires a greater degree of centralized control than public Wikis, this need not impinge on the freedom to contribute that is the hallmark of a Wiki approach. The balance of power is different in an enterprise context, but fear of anarchy should not prohibit Wiki adoption.

Nevertheless, I predict that Wikis will disappear over the next 5 to 10 years. This is not because they will fail but precisely because they will succeed. The best technologies disappear from view because they become so common-place that nobody notices them. Wiki-style functionality will become embedded within other software – within portals, web design tools, word processors, and content management systems. Our children may not learn the word “Wiki,” but they will be surprised when we tell them that there was a time when you couldn’t just edit a web page to build the content collaboratively.