Chapter 4. 11 Steps to a Successful Wiki Pilot


Courtesy of Oliver Widder – Geek And Poke. Used with permission.

The first major step in making the wiki a core collaboration tool in your organization is to run a pilot. Every successful enterprise wiki roll out I’ve run or advised began with a pilot involving a small number of groups that are representative of the most common functions of the organization. The pilot is important because it allows you to get wiki use started in a controlled environment, build examples that are extremely relevant to your organization, and develop the administrative and support structure that will keep things running smoothly when the wiki is a full production service. It also lets you work out the kinks that are inevitable with a major software project.

The growth of the iPod is an excellent example of the benefits of a controlled roll-out. Today, you see the iconic white headphones everywhere you go, but the iPod has reached this status through a steady and well-managed rise instead of an overnight explosion.

When the iPod was first launched in 2001, there was just one model, and it only worked with the Mac – think of this as the pilot phase. In fact, in an interview with Newsweek’s Steven Levy in October 2006, Apple CEO Steve Jobs explained how the Mac’s small market share relative to PCs was used as leverage with the recording industry:

Levy: ‘Let’s talk about the iTunes store. How did you get the record labels, which had been resisting digital music, to sign up?’

Jobs: ‘Now, remember, it was initially just on the Mac, so one of the arguments that we used was, “If we’re completely wrong and you completely screw up the entire music market for Mac owners, the sandbox is small enough that you really won’t damage the overall music industry very much.” Then about six months later we were able to successfully persuade them to take down the barriers and let us move it out to the whole market.'(Levy, 2006)

This is the quintessential rationale for a pilot project to test something new before spreading it everywhere. Testing with a small subset of users – in this case by restricting iTunes to just Mac users – Apple was able to test the market for legally downloaded music. This pilot gave it both the experience necessary to expand its online presence to PC users, and the evidence to convince record labels that consumers would buy fairly priced and easily accessible digital music as an alternative to piracy.

This same argument holds true in organizations, where people need to see the value of a tool before they will adopt it _en masse_. Since the wiki represents a big change in how people gather and organize information, and collaborate, a pilot project gives you the experience necessary to expand the wiki’s presence throughout your organization, and the evidence necessary to convince skeptical users, inform pragmatic users, and inspire the early adopters to help you spread the word.

11 Steps to a Successful Pilot

Here are eleven steps for running a successful pilot. Some of this advice is intended for you to directly use and some is intended for you to give to people within pilot groups.

1. Establish a Time-frame

Set a reasonable time-frame for groups to get familiar with the wiki, move the work relating to their pilot goal onto it, and reach the goal they set at the beginning of the pilot. Roughly three months is adequate – a fiscal quarter in business or a semester in educational institutions. The entire pilot, including setting up the wiki, technical integration with other enterprise services like LDAP directory for accounts, and testing will take approximately six months.

2. Make It Representative

Include groups that are representative of typical projects and activities so that you can build replicable strategies that other groups can use later on. This makes wiki use more attractive to other, similar groups since they can see directly relevant examples. It also gives you an opportunity to see how groups use the wiki and help them get the most value from using it.

3. Keep It Compact

Keep your pilot size small enough that you can work closely with each pilot group. This allows you to have a remarkable command of the types of activities, which you can use whenever you need to report on the progress of the pilot. Keeping in close contact with pilot users enables you to quickly respond to potential problems as early as possible, and give groups timely guidance.

4. Choose Participants Carefully

Make sure they include multiple types of users. Including only early adopters and tech savvy users won’t just limit the appeal of the wiki to mainstream users; it will also limit your exposure to the types of issues common to the majority of future users.

5. Seek or Be Sought?

Should you advertise for participants in your pilot or hand pick them? This depends on the culture of your organization. In a tech savvy organization people may already know about the wiki so putting out a call for participation will give you a pool of applicants from which to choose.

In an organization where people are comfortable with the technology they regularly use but don’t necessarily follow the latest tech trends, it’s better to hand pick some groups that you know would be
receptive to trying new technology, but would approach it from a pragmatic perspective and be able to use their positive experiences to convince skeptical users later on.

6. Wiki with a Purpose

The wiki is no different than any other tool in that it has to have a purpose to be successful. If you just show people the mechanics of editing a wiki page, they’re not likely to become regular wiki users because they won’t know how it relates to what they already do. If you’ve ever sat through any kind of technology training that only focuses on the tool itself, then you know what I’m talking about. You can’t teach someone how to make an image by starting with a tutorial on Photoshop; you’ve got to start by asking what they want to include in the image, finding source material, and _then_ putting it all together in Photoshop.

The wiki will have the greatest impact when used in response to specific _pain points_ where knowledge construction and collaboration are not efficient. Once you know where it’s needed, the best way to start is to get everyone together who will be using a wiki and have a conversation to mutually agree on how it will be used, and establish it as part of the existing social structure of your group, team, or project.

This is so important because it ensures that people see the wiki as a tool that helps them meet common needs, and see use of it as a activity everyone is welcome to – and should – participate in. One problem that has hindered earlier, more complex tools is the perception that they’re just for “techies” or early adopters. The biggest strength of the wiki is that it isn’t just for the most technically savvy groups, and has the highest probability of success when the greatest number of people buy into it and actively participate.

7. Define House Rules

Define a basic set of guidelines for content, conduct, and community and post them prominently on the wiki. You can use these guidelines as the basis to develop a more detailed wiki use policy for large-scale adoption. We’ll talk more about this in the next chapter.

The Sony Ericsson Developer World Wiki has an excellent set of house rules that are concise, informative, and posted prominently on the home page (http://developer.sonyericsson.com/wiki). Regarding community and conduct, they urge contributors to make constructive edits that are on topic, cite sources, respect others, be responsible, and use good judgment. Regarding content, they advise contributors to regard information on the wiki as constantly changing and shouldn’t be taken as official, and that English is the official language in which contributions should be written.

8. Personal Spaces

Get spaces set up for the groups and have them get familiar with the wiki by creating Personal Spaces. A Personal Space (Figure 4-1) gives each user a place to post:

  • Contact information: email, phone, IM – AIM, Yahoo, Google Talk, Skype, etc.
  • Blog and personal website URL
  • Biography
  • Encourage blogging in personal spaces – this can be a good way for people to get to know more about each other and build community in teams, as well as a good place to update progress on projects, get informal feedback via comments, and float ideas.

This builds the social foundation of the wiki and gives people a place to get comfortable with editing
pages. Once groups start to work in their project spaces, this page editing experience will make it much easier for them to focus on getting used to collaborative editing – where they will change content someone else wrote or see content they wrote changed by someone else.

If someone is completely new to wiki editing, learning the mechanics of editing _and_ grappling with the notion that content can be changed so quickly and collaboratively can be overwhelming. If they have editing experience, they will feel much more confident about engaging in the back and forth revision process that is central to the wiki and results in higher quality, more well rounded information.

Once people are comfortable using the wiki, you can help them explore how to apply it to their work. Discuss projects, tasks, knowledge for critical processes, etc. that could make use of the wiki. Find out what’s most important for the group to do their jobs well, and if possible where they feel information flow, collaboration, etc. is weak. This gives you specific instances to demonstrate how the wiki can meet their most important needs.

For example, a department might start by putting meeting agendas on the wiki before each staff meeting. Anyone in the department can add a new item, add additional information about an existing item, or delete something that’s no longer relevant to the meeting.

During the meeting, people can take notes as items are discussed, effectively taking meeting minutes right on the wiki. From here, items that turn into projects or initiatives can be given their own space on the wiki for project management and collaboration, and the wiki becomes a *[Magnet]* for all manner of collaborative work.
* More on this pattern: [http://www.wikipatterns.com/MySpace]
* Contributors to this pattern on Wikipatterns.com: lukehe, Sunir Shah, Trevor Pike, wikifirst, Remi Bachelet, Ronja Addams-Moring

9. Never an Empty Page

As people set up new pages, encourage them to create a Scaffold or template to guide others on what to put on each page. The scaffold can be as simple as a set of section headings, or it can be a set of brief guidelines so people can see what types of information to include.

10. Make it a Magnet

When someone asks for information that you know is on the wiki, email a link to the appropriate wiki page. This helps people get in the habit of looking at the wiki, and increases the value of the wiki to each person because they can collaborate with more people via the wiki than email.

It’s also a good idea to put some exclusive content on the wiki so people get used to looking there. Pretty soon, “It’s on the wiki.” will become the default answer whenever people ask for information.

11. Be Firm, and Think Long Term

Once your group starts using the wiki, be firm about making sure people use it and don’t drift back to earlier means of collaboration. For example, if you used to send out meeting agendas by email, and now you put them on the wiki and email a link to the appropriate page, you may get someone who protests and asks for the agenda by email. They may argue that it’s more work to get an email and have to link to a wiki page, instead of just having the agenda right in the email.

If this happens, I’d suggest responding that although it seems like an inconvenience in the short term, it’s really only a temporary inconvenience that paves the way for several improvements. First is a reduction in email when people get used to going to the wiki–an email with a link to the meeting agenda wiki page will no longer be necessary. The second is a further reduction in email when people who need to edit the agenda do so directly on the wiki instead of emailing the person who sent the agenda.

The third improvement is that now information is stored in a more archival, accessible, and secure format than email: if you were to lose your laptop or it’s stolen, email is lost along with it and this can compromise the security of sensitive information. However, if you’re using a wiki, that information is stored on a secure server and won’t be lost or compromised as easily.

The fourth improvement is that once you start using the wiki for meeting agendas, it lays the foundation for further wiki use, like managing the tasks and projects that arise from the agenda. It’s this organic use that makes the wiki quickly become an indispensable tool for information and collaboration.

One of the most interesting observations I’ve made recently regarding wikis has to do with financial services firms, and how they’re perceived. Most people are inclined to think of financial services firms – investment banks, securities trading firms, retail banks, etc. as very conservative, serious, and probably not the most likely to be early adopters of leading edge technology tools.

In my experience, however, the reality is quite different. That’s not to say they aren’t serious – after all, keeping track of someone else’s money is serious business! They are, however, regularly looking for tools that make their work easier since their work is highly regulated and monitored by government agencies such as the Securities and Exchange Commission (SEC) and Congress in the US. As a result, financial services firms are using wikis for maintaining and updating documents containing federal policies and rules that must be followed, and keeping internal policies up to date. These kinds of documents are constantly changing as new laws take effect, rules are updated and changed, so the wiki is an ideal tool for housing this information and enabling information to be quickly changed and immediately accessible so thousands of employees who use it daily.

So the lesson here is that if companies in an industry traditionally viewed as very conservative are embracing wikis, you should too. A wiki is not only an innovative way to keep critical information constantly up to date and immediately accessible; think of the cost savings and environmental benefit as well!

What’s My Role in Wikipatterns.com?

As Atlassian’s wiki evangelist, one of my main projects was launching Wikipatterns.com and helping it grow into a worthwhile, valuable resource for all wiki users.

But what exactly is my role on the site?

In every other wiki I’ve set up, I’ve been the sole champion or one of a small group of champions, and it’s much the same with Wikipatterns.com. The types of things I’m doing can be done by any champion who is starting a wiki within an organization or for a broader web-based community like the new (and fast growing) Wikipatterns community.

For instance, when someone wrote a comment suggesting that we add a new page, I replied back with a brief note encouraging him to create the page and showing him how. I could have just created the page myself, but encouraging someone else to do it helps that person get more deeply involved in the wiki, and feel a sense of ownership in the content he or she contributes.

In a couple of other instances, I’ve created pages and added just section headings as a way to guide people on what to add – this is the scaffold pattern in action. To avoid the Do-it-all anti-pattern, I’ve proposed changes to some pages by adding a comment to the page instead of just arbitrarily making the changes. This gives others a chance to weigh in on the change, and even make the change themselves if they feel so inclined.

What happens if someone adds a page that I don’t like? Maybe I don’t like where the page was located in the hierarchy. For example I might think it should be linked to a different page or moved to a new section. Or, what if someone adds a paragraph of content that I think should be moved to a different page? What is my role as the guy who started the wiki?

Well… it’s a wiki. I could move it myself, contact the contributor and discuss it with him or her, or someone else in the community could move it. Other contributors might feel trepidation about changing someone else’s content, and that’s to be expected, especially when they first start using the wiki. The best thing to do is encourage people to make changes that are constructive, take into account the value of previous contributions, and improve the overall quality of information.

Launching a new wiki involves hard-work, planning, contributing, and community-building, and it’s very rewarding to see others get enthused enough to contribute and invite even more people to join in.

So what’s your role on the wiki?

References

  1. Levy, Steven. ‘Good for the Soul’, _Newsweek_ http://www.msnbc.msn.com/id/15262121/site/newsweek/, 15 October 2006 (Retrieved 22 July 2007).
  2. ‘The House Rules’ _Sony Ericsson Developer World Wiki_ http://developer.sonyericsson.com/wiki/display/leftnav/Welcome+to+our+Wiki+community, 26 July 2007 (Retrieved 14 August 2007).