During the pilot, it’s possible – and necessary – to hand pick the groups that will benefit most from early wiki use, have people that are motivated to use new tools, and make excellent, representative examples of wiki use. Large-scale adoption is a much more complex endeavor because the ultimate goal is to get everyone using the wiki. This means that instead of working with a few dozen users, you’re likely dealing with a few hundred, and the profile of users changes as well. Not all will be as eager as the early adopters, but their reasons are legitimate and it’s incumbent upon you to convince them.
This is where careful planning and use of Wiki Patterns come into play. Planning allows you to scale the guidelines and practices you’ve developed during the pilot, so that others can use them in a more widespread way. Because large-scale adoption involves so many more people, patterns bring a level of commonality and consistency to the many different spaces being created by groups throughout the organization.
Develop a Wiki Use Policy
Writing a wiki use policy can be a great way to organize wiki use, help you clarify answers to questions that new users will likely ask when they get started, and remind people of some common sense approaches to how they handle information on the wiki.
Let’s take a look at an excellent example of a use policy. Sun Microsystems is using wikis for collaboration among people both inside and outside the company, and has spaces on a range of topics, including interning at Sun, Application Performance Tuning, documentation, global citizenship, security, and Storage Systems Patterns, to name just a few. Sun has a [policy on wiki use|http://www.sun.com/aboutsun/media/wiki/policy.html] that I particularly like for several reasons. It’s a length that’s not daunting and an average user can be expected to fully read it. Many policy documents read like legal briefs and are so long that it’s a joke to think that anyone other than the lawyers who write them would know what they say beyond the first few sentences.
The policy begins on a positive note: “Many of us at Sun are doing work that could change the world.” This is a great way to speak to people in a voice that recognizes this is a very different kind of wiki community use than something like Wikipedia. It acknowledges that people at Sun are working on shared goals, and goes on to explain the role of the wiki as supporting that aim, encourages people to use the wiki, and asks them to read the rest of the policy as advice for successful use.
The policy continues with seven points of advice that read like the policy authors were thinking more about how to ensure success from the start then about setting rules with the expectation that someone will break them. The first point emphasizes the need for a Sun employee to moderate each space: nurture growth, maintain organization and serve as the point of contact for questions. This is an excellent example of a combination of the WikiChampion, WikiGardener, and PageMaintainer patterns. A WikiChampion is essential to the success of a space because she or he nurtures growth, builds community, and encourages others to take active roles in the development of context. A WikiGardener keeps the space organized so that as context grows people can easily find what they’re looking for. This is important because finding the content they need is essential to building participation in the community. People add and edit pages containing context that’s relevant to them. A PageMaintainer is responsible for the activities on a specific – typically busy – page, and makes sure that people make necessary contributions to the page to keep collaboration moving along.
The section on moderating finishes with an important point. “A moderator must also remember that the wiki is owned by the community first and foremost and must resist controlling it.” It’s very smart to have this covered right at the start. Too much control drives people away – every person must feel a sense of personal ownership for a wiki to be successful, and this can only happen when no one person asserts dominance.
The next section addresses the difference between content on an intranet vs. the Internet, and emphasizes that people should take an approach that assumes anyone could see content posted on the wiki. Even though this isn’t necessarily the case, it’s a sensible approach to use caution and not post content that is private and needs to stay that way.
Continuing the emphasis on information sensitivity, the third section deals with the distinction between talking to the community about Sun’s products and technology, and rereading proprietary and confidential information regarding those products. What’s good about this section is it raises awareness of this, reminds people to be careful with Sun’s intellectual property, and also leaves room for judgment calls because it’s not always a clear-cut issue. For example, discussing a proprietary hardware design might be inappropriate, but answering a developer’s questions about software architecture for that hardware may be perfectly appropriate.
My own personal take here is that when in doubt, an employee would do well to ask her or his supervisor for advice on what’s safe to disclose and what’s not. Even if the supervisor doesn’t have the answer, the legal department could be asked to further clarity. Also, it establishes a trail of due diligence should someone ever questions what the employee disclosed. The bottom line here is that the more people who are aware of an information disclosure, the more likely it is that the right information will be disclosed.
The next section of Sun’s policy advocates just this approach. In advising wiki users about compliance with financial disclosure laws, journal tracking statements about products and roadmaps, it suggests consulting with management and setting sign-off before posting to the wiki if you’re unsure about a particular judgment call. The section does a good job of pointing out why this information shouldn’t be talked about too casually – discussing financial issues, for example, can bring on legal trouble if it violates disclosure laws – especially for publicly-traded companies. Sometimes people might not realize why certain information must be kept confidential and disclosed carefully – this serves as a good reminder.
In the section “Think About Consequences,” the policy points out that it’s also important to think about not just _what_ you say but _how_ you say it. The section advocates offering reasonable, constructive comments, especially if they’re critical of something. Amateurish comments don’t really offer anything that can be used to improve a product or service, and they run the risk of embarrassing other at Sun, especially if a customer sees them. The policy again advises people to use their judgment when deciding how they contribute to a wiki space.
The policy wraps up with a section on the use of disclaimers, and another section that looks at how the wiki fits in with other tools available at Sun. The disclaimers section points out that although people often post statements asserting that what they say does not necessarily reflect the official opinion of their employer, these statements don’t always have a lot of legal weight. Again, the bottom line here is to use judgment first and foremost.
The last section makes one of the most important points: the wiki does not necessarily replace other tools, and should be seen as complementary. I like it so much because it echoes what I’ve been saying – trying to rush the wiki in and replace everything else won’t work. The wiki should complement other tools so that the uses play to the strengths of each. In keeping with this idea, the policy ends with the statement, “Use your wiki’s policy page to make your wiki’s purpose clear.”
The bottom line here is that a good wiki policy, like Sun’s, should emphasize using sound judgment. A policy that lays down explicit boundaries is less effective because it only applies to specific scenarios, and takes a reactive approach. Sun’s policy takes a proactive approach, plays to the intelligence of its employees, and is more effective because good judgment can be applied to any situation.
Work in Phases
When you move from pilot to large-scale adoption, it doesn’t have to happen all at once. In fact, trying to do it all at once can actually cause a lot of problems because it’s a quantum leap to go from a few dozen users in pilot to potentially thousands of users. It’s better to think of your pilot as simply the first phase of a multi-phased approach, and grow to full use in successively larger stages.
For example, let’s say your organization has about a thousand people. If your pilot included five groups and a total of about fifty people, a good goal for the first phase of large-scale adoption is to add about a hundred people. Once you reach that goal and have a total of about 150 people using the wiki, add another 150-200 people in the next phase. By this time, you’ll have about 300-350 people, and momentum from the existing users will help propel that number higher.
The timing of phases is important as well. Your pilot will be the longest phase in this process, largely because it’s the proving ground and more work has to be done to get something of this scale started than to just grow it once it’s underway. In my experience, phases in the large-scale roll-out will be successively shorter because each one builds further momentum. The longer the wiki is around, the more people will know about it and be interested in using it as they see more and more people around them using it.
Overall, bringing in a wiki is about a two year process, from the time you first start exploring it to the time when it’s in full production use. The pilot phase, including initial setup, testing, and technical integration with LDAP directory and other enterprise services will take about six months. The first phase of large-scale adoption will take another four to six months, and the second phase will take another three to four months. This is a bit of a liberal estimate, and things will definitely move faster and slower at times.
Explain Why People Should Use the Wiki
Although the value of using the wiki may be apparent to you, it’s not necessarily apparent to somebody encountering the wiki for the first time. In fact, some people will be skeptical of this new tool and question whether it’s just another addition to their already busy lives. Anthony Rethans, a colleague of mine who works in business development says, “Just because we have more means of communication doesn’t mean we have more time to consume them.” This is a valid point, and to make the wiki a widespread success in your organization, you have to convince people that using it won’t add complexity to their day, but will actually simplify communication, speed up projects, reduce redundancy, and keep information more secure.
One thing organizations find when they first start using a wiki is that information storage and communication between groups is often quite fractured. In the absence of a centrally supported wiki, groups will often set up tools that are intended to be quick fixes to their information and collaboration needs, but these tools often stick around longer than they were originally intended to. This creates the phenomenon of a “server under someone’s desk” that isn’t secure against the threats of viruses, hackers, power and hardware failures. Furthermore, since people can’t easily see what others are doing in these “islands”, separate, disconnected silos of information are created. Ultimately this does the organization a disservice because people end up creating redundant information instead of just building on what already exists.
A wiki reduces this scenario of walled-off information because it starts without the heavy barriers between information and lets teams decide what needs to be secured and what information should stay open. Many organizations find that only a small fraction of information really needs to be completely restricted and walled-off from anyone but the people directly working with it, and the previously locked-up information that becomes more accessible with wiki use becomes more useful and up to date.
Another important point to make when explaining why people should use the wiki is that it keeps information more secure. It seems every time I turn around there’s another story about a major corporation or government agency losing a laptop with thousands of social security numbers, credit card numbers, and other personal identifying information that’s prized by identity thieves. When people collaborate using tools like email and shared drives, they often have copies of documents and the contents of their email inbox stored locally on the laptop. If that laptop is lost or stolen, all the sensitive data on it is compromised.
When you use a wiki, the data on pages is stored on a server, and since you access wiki pages through a web browser, files don’t need to be downloaded and stored locally to be edited. The server itself is also better protected from physical and data loss or theft than a laptop because it doesn’t leave the data center.
Use Pilot Cases as Examples
You’ll find that your pilot is the gift that keeps on giving, because in addition to getting the wiki started in your organization, helping you work out technical and integration issues, and giving you a controlled environment in which to test different wiki uses, it gives you a set of examples that can be used during large-scale adoption to help new wiki users get ideas and inspiration. One great way to make use of the pilot examples is to create a tour of some or all of the pilot groups’ wiki spaces, highlighting key points like the purpose of each, specific types of content different groups have used their spaces to collaboratively build, how groups organize their information, and the roles taken on by people in each.
LeapFrog, a company that creates technology-based educational products, has taken this approach with its own internal wiki. Sarah Cox, a member of the team that’s deploying and supporting the LeapFrog wiki, developed a tour that is part of the introduction to the wiki for new users. It includes screenshots of various spaces, showcasing a variety of uses that can give new users ideas as they get started. Since the examples are from other internal LeapFrog teams, the tour helps ensure a certain amount of consistency that makes the wiki more usable so that when people from different teams collaborate they’ll be able to easily navigate other spaces. Figure 5-1 shows how the Finance Team uses their wiki space to organize information for global meetings and provide pages for all the teams within the department, and Figure 5-2 shows how the development team for the Fly Fusion product uses their wiki space to organize news, collaborate, and even keep a list of local restaurants that deliver!
Offer Training and Support
It’s good to offer scheduled training sessions, and a support system for handling questions on both technical and strategic issues. Training helps boost peoples’ confidence in their ability to use the wiki, lets them know they have a place to go if they need help, and builds a peer support system between the people who attend sessions. Besides offering scheduled sessions, offer to drop in and visit groups using the wiki to see how things are going and offer advice and tips on current wiki use.
Let’s take a look at a series of patterns that help people get new wiki spaces started, encourage colleagues to use the wiki, tap into the social side of the wiki by creating user profiles, seed spaces with content, and alert others to the content needed on pages. These are some of the patterns I see in action most often, and regularly recommend when working with organizations on their large-scale adoption plans.
The Importance of WikiChampions
Getting people to use the wiki is a process that reduces information redundancy, lowers the barriers to collaboration, keeps information more up to date, and makes technology feel truly usable and responsive to users’ needs. The key to making this happen is helping people see that whole process, and realize the payoff if they get started using the wiki. In the large-scale adoption phases, you have something you didn’t have nearly as much during the pilot: satisfied users who are often so pleased with their experience that they’ll seize any opportunity to convince their colleagues of the benefits of using the wiki. These are your WikiChampions, and when you’re working to educate a lot of people about a new tool, you couldn’t ask for a better or more effective tool than the word-of-mouth evangelism these people willingly provide.
These WikiChampions are very valuable to spreading the wiki because of their existing relationships with colleagues they regularly work with. Every person in every organization has a network of people they regularly work with, and they’ll be able to introduce these colleagues from other groups to the wiki by using their knowledge of people and projects to pick the best places to introduce wiki use.
One pattern WikiChampions are naturally good at is inviting people to try the wiki. Early adopters are by nature eager to try new tools, but many mainstream users – the majority of people targeted during large-scale adoption – aren’t as likely to try, for a variety of reasons. Some are risk-averse, and want to wait until others have proven the viability of a new tool first. Others prefer more formal training whenever they start using something new, and still others are just too busy.
An invitation creates an opportunity to dedicate time to trying the wiki, and gives people reassurance that someone knowledgeable is there to help them get started.
A StartingPoint is a site that helps first-time users familiarize themselves with a wiki and get ideas for how to use it. It can include guidelines for wiki use, instructions for creating an account and setting up a wiki space, and information on training and support for wiki users. LeapFrog’s tour of example wikis is a prime example of this, because it offers new users concrete examples that are highly relevant because they’re from others inside the company. WikiChampions often use a StartingPoint like this because it’s complementary to the Invitation in guiding the first experience, and making sure they don’t say, “Ok, now what?” when they visit the wiki for the first time.
In the last chapter, we looked at the importance of personal spaces as a way for people to post information about themselves and practice editing before they get to using the wiki for group collaboration. This is even more important during large-scale adoption because the value of the social aspect of the wiki increases as the number of people using it increases. Large-scale adoption, when you’re aiming to get the whole organization using the wiki, is a perfect time to build out the social network since as people get started on the wiki. An added benefit, especially for organizations where people are spread across great distances, is that the presence of personal spaces helps strengthen social ties.
When a person makes that all important first edit, perhaps to post information in their personal space, leave a comment welcoming them to the wiki and acknowledging something specific from their contribution, nothing communicates the essence of the wiki to a first-time contributor better than getting a comment shortly after making their first edit. The personal welcome helps them immediately feel like part of the community, and the fact that someone acknowledged their contribution signals that they’ve joined an active community, which motivates them to keep making contributions.
Once people have familiarized themselves with the wiki, jump-start a group’s space with a BarnRaising. A BarnRaising is a planned event in which a group gets together in the same physical space at the same time to begin construction of their virtual space on the wiki. Whereas building a personal space helps people get comfortable with the mechanics of building a wiki and editing in a place of their own, a BarnRaising helps them get used to collaborative editing. It gets a critical mass of activity on the wiki, and allows the team to make decisions about what content to put on the wiki, and how they organize their space, name pages, etc.
For example, if a team is planning to use the wiki to manage meeting agendas and minutes, they can decide on a naming convention for individual meeting pages. Making decisions like this can seem trivial, but when organically developing a structure that suits each group’s needs is essential, as it is with the wiki, decisions like this are critical. A group doesn’t want to end up in a situation where content is poorly organized and unusable because each person is using their own organization system.
When people make these decisions together, it gives them a sense of buy-in and responsibility to uphold them in practice, strengthens the sense of community surrounding the wiki, and builds a support network that helps people mutually grow their wiki use.
Sometimes a group may not feel ready to commit to the wiki enough for a full BarnRaising, and want to have a successful “proving ground” experience first. In this case, find a project, task, or pain point that using the wiki will improve, and use this to demonstrate the value of the wiki. Once people solve one problem elegantly and simply using the wiki, they’ll begin to see other areas where it can have a similar impact, and wiki use will steadily grow.
My friend MarkDilley used this pattern to get union organizers to think about using wiki – here’s his take:
When I discovered wiki in January 2002 I immediately recognized its potential value in organizing work and people, especially in the intentional organizations that I worked with, labor unions. However after several years of speaking to people about the grand possibilities of mass collaboration with wiki, (read: banging my head against a wall) – a friend suggested that we use a wiki for simply getting contracts online in the same space for this particular labor coalition that we were involved in. Not all of the people involved in the coalition have uploaded their contract to date, but enough people have done so and even used the wiki for other things than the contracts.
Seed it With Content
The goal of the BarnRaising is to get people together to jumpstart wiki collaboration, and in addition to making operational decisions about things like content organization, uses, and naming conventions, it’s a great venue to seed the wiki with content. For the wiki to become a destination, the content people use every day has to be available on it. If everyone pitches in to move content during the BarnRaising, they’ll have set the stage for continuing to work with it on the wiki. This happens because they’ve invested the effort to move it, and because it’s now easier and faster to update.
For example, if a team has a handbook of common procedures that’s distributed as a text document, move the contents into the wiki. In the process, break out sections of content in the document into separate wiki pages to improve readability and avoid the phenomenon of extremely long pages. Shorter pages make content easier to find when browsing, and are more conducive to editing because it’s generally easier and less distracting to work with smaller, more focused blocks of content.
It’s much easier to keep existing information up to date and add new content when something like a handbook, how-to guide, or reference manual is on a wiki. When content is stored in a text document, that document can easily get lost in peoples’ inboxes, making information hard to find in a pinch. It’s also harder to keep up to date since changes made by each person to their own local copy need to be reconciled across all copies. It’s almost impossible for this to happen in a fluid, elegant manner that doesn’t involve someone dropping what they normally do to manually combine changes.
Using a wiki reverses the traditional course where information is of highest value when first published and declines in value over time. When a wiki is seeded with content, the value of that content actually _grows_ over time as new information is added, errors are fixed, and information is essentially insured against falling out of date.
Intentional error is one of the original wiki adoption patterns pioneered by Ward Cunningham, creator of the first wiki. It involves intentionally making errors which are left for others to find and fix, thus getting them used to editing a wiki.
When you’re editing a wiki page, just make some errors like misspelling a word or forgetting to capitalize at the beginning of a sentence. Then invite others to proofread your page and when they discover the errors, let them fix the errors themselves just by editing the wiki. However, be mindful that not all readers may recognize an error or choose to fix it, so introducing substantial or factual errors in content may prove to do more damage than good.
The ContentAlert pattern involves leaving specific messages that let people know a page needs content to be added, refined, or fixed. One of the best ways of doing this is to put a message in a box at the top of the page in question (Figure 5-3).
New Employee Wiki
An important part of large-scale adoption is making sure that new employees are introduced to the wiki. Since new employees are coming in with a fresh perspective, and haven’t used any tools within your organization yet, they’ll be able to start fresh with the wiki, and it can provide a good way to organize their first few days. For example, create a space specifically for new employees that contains orientation materials, a check list of things to do, forms to fill out, etc. An added benefit of doing this: the space can be easily updated whenever any of these procedures or documents change. Also link to pages that document work procedures so new employees can get up to speed faster.
Document Business Processes
Another great use for the wiki is to document common business processes. This strengthens the wiki’s role as a magnet, and gives people one more reason to use it. People can easily document processes and procedures that would otherwise reside only in their heads, and the wiki becomes a great place to preserve and update this information as processes change and people come and go. Also, it becomes an invaluable resource for new employees to quickly get up to speed on common processes, and they can refer to the wiki as often as they need.
“It’s on the wiki”
As your organization’s wiki becomes the central tool people rely on to find information, share knowledge, and collaborate on projects, people will be saying, “It’s on the wiki.” more and more often. If someone asks you for information, point them to the wiki. If they haven’t heard of it yet, give them a quick overview and show them how they can get started using it themselves. Pretty soon, when you ask them for information, they’ll say, “It’s on the wiki.”