Wikis+in+the+workplace



==[|Wikis in the workplace: a practical introduction]== //The wiki crops up in many companies' internal discussions about process improvements and efficient collaboration, but it is often shot down because so few people have exposure to good models of what a really successful business wiki can do. Ars is here to help with a practical introduction based on real-world examples.// By [|Alan J. Porter] | Last updated November 16, 2009 11:30 PM

When times get tough and belts get tight, one of the first things many companies do is begin casting about for ways increase efficiency and raise per-worker productivity. Many businesses turn to free and open-source tools to meet these needs, and at some point in such discussions someone invariably suggests a wiki for some internal project. But the wiki idea often gets rejected soon after it's floated, typically because wikis are perceived to be insecure, inaccurate, or difficult to use; either that, or someone in the discussion has gone the wiki route before, only to see their wiki languish from lack of interest and participation.

These perceptions and experiences that lead companies to reject wikis are rooted in a common problem: the vast majority of the public has formed 100 percent of their expectations about what a wiki can and should be based on the single example of Wikipedia. Few have ever seen wikis used creatively and successfully in a real-life business context, so even when IT professionals attempt to implement wikis in their own companies they lack real experience and good examples to imitate.

As someone who's currently writing a book on wikis (see my bio below), I've talked at length with a number of different organizations about the wiki's role in their business. In this article, I'll share with you some of what I've learned about wikis in the real-world by taking a case-study approach to describing how and why a handful very different organizations are successfully using wikis. After seeing the kinds of things that are being done with wikis, you might be motivated to give the technology a second look.

Wikis and communities: Webworks.com
Like standard websites before them, wikis have grown to be useful in any number of ways, and the potential of the wiki technology is only limited by the imagination of those who use it. But what makes a wiki so powerful for collaboration is that the "anyone can edit" capability means that the development of a wiki is typically driven by the community of people who use it, rather than being mandated and guided from on-high by a centralized IT or by company leadership.

The team at WebWorks.com uses different wikis to support distinct sets of user communities within the company. WebWorks.com first installed a wiki in 2003 to provide a collaborative environment for its software development team to share ideas, and to document and comment on the progress of a product build. A couple of years later, the company's services group chose a different wiki platform to manage projects and collaborate with customers. The company says that the introduction of the wiki made customer communication more efficient by enabling everyone to work from the same information source for troubleshooting and project planning, with the net effect that projects were completed quicker, there were fewer incidents of the project specifications changing, and everyone was kept informed of progress so there were no surprises.

By 2007, the software development wiki had grown and been transformed into the company's "innerwiki," which replaced a static, traditional, Web-based intranet. The wiki became the source for all company information and was treated as the canonical internal document of record. As CEO Tony McDow puts it, "if something isn't on the wiki, it doesn't officially exist."

The same year, WebWorks launched its first public-facing wiki: the WebWorks Help Center, which is aimed at the more active members of its user community. The [|wiki.webworks.com] site is a place for the WebWorks developers and support teams to post content, notes, and general information about the product, and for registered users to post enhancement requests, or even their own projects and ideas, so they can get assistance and feedback from their peers.

A new wiki was then launched the following year in order to assist in the promotion and planning of the company's annual [|'RoundUp'] users conference. Using a wiki instead of a standard website allowed the conference organizers to monitor and make quick changes to the areas they were responsible for, and it let speakers and exhibitors post their own information and make edits and additions right up until the opening day of the event. A special area of the wiki was set up for conference attendees to take notes and make observations as the event was taking place.

In the last twelve months, the latest WebWorks wiki, [|docs.webworks.com], was launched as an online destination for all of the company's product documentation. This wiki allows customers, prospects, and any other interested parties to review and comment on the documentation set. WebWorks also developed a technique for linking the product's embedded online help to the wiki documentation so that anyone accessing the online help can immediately see if the topic they are looking at has been updated or commented on in the public wiki.

As I said above: different wikis for different communities, each designed to meet a defined business need.

While the majority of corporate wikis currently reside behind company firewalls, there is a trend toward making them publicly available, as with three of the WebWorks wikis above. But moving a wiki into the public domain tends to immediately raise some concerns about quality and security.

The accuracy issue: Geometrica
There is a common perception that wikis are highly inaccurate; the best-known example of this is the online encyclopedia [|Wikipedia], which is often criticized for its errors. This is a common misconception, based on the idea that if "anyone" can contribute, the quality of data will suffer because there is no editorial control. But in practice, the opposite tends to happen, especially in wikis that are designed for internal corporate use. Any posted content is not subject to the whims, preferences, or even prejudices of a single editor or manager; it is now subject to the review of the whole community. As a consequence, other subject matter experts within the company can comment, change, and contribute quickly and easily. People with a passion for a particular subject tend to self-police the areas of a wiki covering that subject; they make changes very quickly, and if some misleading or incorrect information is posted then it is instantly challenged and rapidly corrected, with a consequential increase in the quality of the information.

The truth is that a wiki, like any other website, is as open or as secure as you want to make it.

Houston, Texas-based construction company [|Geometrica] experienced this exact result when implementing a wiki-based ISO9000 compliant quality management system. CEO Francisco Castano explained that originally there was resistance to the wiki due to "the ingrained perceptions about the need for the sequential authoring-editing-approval-publication process and the perception that when a document is published its information is correct, complete, permanent, and authoritative." But when Geometrica allowed every staff member the rights to edit or comment on its wiki, the distinction between author, editor and approver disappeared. Castano pointed out that "because the organization is working towards one goal [in this case ISO 9000 Quality Control Certification], anyone can share ideas, discuss, comment, change, edit, copy and paste as needed. Everyone's skills and knowledge are welcomed."

One unforeseen benefit of this open collaboration was a marked increase in the quality of the documentation being developed on the wiki. The ease of editing meant more people got involved with less effort as barriers to participation, such as knowledge of specialist editing tools, were eliminated. Many small corrections or improvements that might have previously been ignored as being tolerable, if not perfect, tend to get corrected. The aggregation of these many small improvements resulted in significant change, or "wiki magic," as Castano calls it.

Are wikis secure?
The "anyone can edit" philosophy that underpins most wiki implementations leads to the assumption that wikis are inherently insecure and open to vandalism, hacking, and other malicious behavior. This impression is reinforced by the all-too-frequent press reports about vandalism of various high-profile Wikipedia articles (the number of press reports being totally out of proportion to the actual number and frequency of attacks when compared with the actual number of pages on Wikipedia). The truth is that a wiki, like any other website, is as open or as secure as you want to make it.

The Wikipedia model is perhaps the most open, with just a simple, unverified, and automated login required before you can start editing. However, most wikis come with access controls built-in, and they can be set up so that only named individuals (or groups) have access to, or can even view, specific pages. It is also possible to set up wiki pages so that edits aren't allowed and only separate feedback comments can be made (the most common model for documentation wikis).

With the Geometrica wiki project, every contributor was identified by name, and all changes to the wiki were logged by author and timestamp so that the wiki administrator could track page changes by user or date.

Most wikis allow notification of changes to be sent out via RSS feed, which not only lets users interested in a specific topic to be notified when changes are made, but also allows administrators to be made aware of activity on the wiki.

In many ways, wikis are far more secure and manageable than a traditional website. But even before security becomes an issue, you have to consider how you will get people to use the wiki.

I recently heard from a user who felt that a project at her office would be ideal for a wiki implementation. She had raised the idea only to be told by her IT department that "we tried a wiki once, no one used it, so we are going to do something different this time." Unfortunately, this kind of thing is far from rare. Just setting up a wiki on a Web server and expecting it to work is dooming it to failure. You cannot force people to use a wiki, so you must encourage its use through word-of-mouth and let it grow organically. Even then, you may have to realize that the community it was designed to serve just prefers another way to collaborate and communicate. One wiki I set up for a local writers group was a spectacular failure, because they simply preferred sharing information by meeting regularly in a coffee shop (and I can't say I blame them), so the technology became superfluous to their community needs. However, not every company or organization can meet in the local Starbucks.
 * Build it and they may come—encourage it, and they will come**

So how do you get people to use a wiki? The most successful wikis are the ones that meet a distinct need; either they serve a specific end, such as Geometrica's certification goal, or they improve processes and promote efficiencies, such as the case of WebWorks.com projects wiki. Implementing technology for technology's sake, just because it's cool, will invariably lead to failure. Technology geeks also need to realize that many of the ideas, features and functions that get us excited and turn us into early adopters of new technology can intimidate the average user to the point where they will be scared off and not use a solution no matter how beneficial it may be.

One of the easiest ways to introduce the idea of a wiki is to use it for that most common (and most frustrating) group activity: organizing a meeting. How many times have you seen this scenario play out: you send out an e-mail trying to organize a meeting and agenda, and you get replies from various attendees proposing alternative schedules or asking for change and additions to the agenda. Before long, one simple e-mail has spawned multiple e-mail threads that have to be managed and reconciled. By posting the meeting agenda and details on a wiki and sending out one e-mail pointing to the relevant wiki page, everyone involved can see any proposed changes, make comments, discuss and quickly reach a consensus.

Another great way to introduce potential users to the benefits of a wiki is to use it to organize a fun event that all the potential users may be interested in—for instance, the WebWorks.com Christmas party mentioned at the beginning of the article. The Christmas party is one thing that everyone in the company was interested in participating in. By posting ideas for location, menu items, scheduled dates and even offers to car pool on the wiki, everyone could get involved, put forward their opinion, and feel that they had made a contribution to the end result. Similarly, when the WebWorks team were contemplating an office relocation, the wiki was used to gather input from members of staff as to what sort of facilities they wanted in a new office space, what an ideal location would be, and thoughts on environmental impact. Ideas for potential floor plans and layouts were posted to keep everyone informed, giving everyone a voice in the process.

Using internal fun projects like this is a great way to let people experience the benefits of using a wiki without mandating its use. Once a user can experience the benefits for themselves, they will be more open to continued use.

Many wikis, such as the popular Confluence wiki, come pre-configured with a template for each registered user to set up their own page and space on the wiki. Allowing each user their own private space is a great way to encourage wiki use. A sense of ownership is also a vital part of encouraging wiki growth and adoption. Ben Allums, the Director of Engineering at WebWorks.com, refers to this as the "tennis ball effect." He tells the story of how a previous WebWorks employee bought a tube of tennis balls to the office one day and left them in the server room. Over time, no one could remember who owned the tennis balls, even though the original owner had long departed the company. No one wanted to take the responsibility for throwing them out. In fact the tennis balls survived three office moves before being disposed of. As Allums points out, it's all too easy for wiki pages to be created that quickly become orphaned and just sit there, but by encouraging a sense of ownership and responsibility for the content and management of a page, the wiki's growth becomes more organic than scattershot, and the content continues to be useful to the community that has a stake in it.

Social reinforcement can also be a powerful tool in encouraging wiki adoption and usage. If a hallway discussion generates a great idea or observation, instead of ending the conversation with "send me an e-mail with that," a change to "put that on the wiki so everyone can take a look and comment," opens ideas up for discussion. Such an approach also removes the e-mail "black hole" where the sender is never sure if the recipient acted on ideas. After something useful has been posted, even verbal feedback such as a quick "nice wiki post" can add to the feeling that contributions are read and valued.

It is also important that the people implementing and encouraging the use of the wiki are seen to be active participants themselves. Asking others to use something you don't use yourself is a sure recipe for lack of acceptance.

When implementing a wiki, you need to have realistic expectations of the number of active users that will contribute. The more bounded the community, the more likely you are to see higher participation levels. This is especially true of wikis within a corporate firewall. The WebWorks.com innerwiki has had at least one contribution from 90 percent of the company, while the active participation level is around 50 percent. At Geometrica, around 36 percent of the company contributed.

With open public wikis, such as Wikipedia or a typical documentation wiki, the participation figures are orders of magnitude lower. In her book //[|Conversation & Community: The Social Web for Documentation]// (XML Press, 2009) author Anne Gentle discusses the 90-9-1 rule which postulates that for every 100 visitors to a public wiki, 90 will be just readers, nine will contribute something, and just one will be an active contributor.

Setting an expectation on the level of participation based on industry experience can help determine realistic goals for any wiki implementation acceptance criteria.

Bringing community together
In addition to encouraging cooperation in the development of information, wikis can also be very useful in opening up communication paths in large organizations where different divisions may have no visibility of similar work being done by others in the organization.

[|Outward Bound International], the umbrella agency for the Outward Bound adventure training schools, used a wiki as a central part of their initiative to coordinate and share the resources and experience of 18 different Outward Bound entities around the globe.

Previously, each national entity acted as a separate unit with little awareness of how things worked in the other units. By sharing resources and information on a wiki, each national group could start to learn from each other. Duplication of process was eliminated, and the newer groups could learn from the more established groups, benefiting from their experience.

New global initiatives could be rolled out quicker, with the central organization being able to confirm that each group had received updates at the same time. Using a wiki instead of the traditional website also meant that feedback and comments could be collected, and productive discussions could be held with contributions from across a true global community.

Noelle Thurlow, Project Manager of the Outward Bound World Resources Initiative, explained that "while wiki usage spiked after each new group was trained on and introduced to the wiki, the underlying number of core users has continued to grow as users become more familiar and the content more valuable." Following on from the success of the initial World Resources Project wiki, Outward Bound International is now looking at spinning off complementary wikis to provide similar benefits for its sister organizations.

So are wikis just for documents?
Given the text-based nature of wikis, it seems natural that they might be considered as purely a documentation tool, whether that documentation is product information, quality manuals, policies and procedures, developers notes, or even an online encyclopedia.

But, as mentioned earlier, wiki usage is only limited by the imagination of the community that uses it. Below are some examples of other wiki usage I have come across.

Leading wiki consultant, Stewart Mader, of [|Future Changes], often cites the belief that wikis have the potential to be as ubiquitous as e-mail is today, and that in the not too distant future we will take their use for granted.
 * For individuals**
 * Getting Things Done (GTD) productivity tool
 * Notebook for brainstorming / idea capture
 * Editing / content creation tool
 * Project tracking
 * Personal database
 * Mind mapping
 * Small groups**
 * Collaborative planning
 * Knowledge capture
 * Communication portal
 * Project tracking
 * Review tool
 * Special interest groups**
 * Common space for knowledge sharing
 * Collaboration
 * Research tool
 * Company internal**
 * Collaboration
 * Knowledge capture
 * Peer review
 * Database
 * Official document storage of records
 * Productivity tool
 * Project management
 * Meeting management and record keeping
 * Content creation tool
 * Content delivery mechanism
 * Website replacement**
 * Documentation online
 * Conference planning
 * Customer forums
 * Large open groups.**
 * Knowledge capture
 * Collaboration
 * User generated content
 * Research tool

//Alan J. Porter blogs at [|THE CONTENT POOL], where he discusses industry trends and offers observations on information development. He is currently writing [|'WIKI: Grow Your Own for Fun and Profit'] to be published by XML Press in May 2010.//