Six Guiding Principles for Wiki Use and Development
On their own, wikis won’t manage your content or create effective knowledge management structures, they won’t reach out to your customers, and they won’t create collaborative documents. A wiki is simply a tool that can help you achieve your goals. As with all tools, it’s important to select the right one for the job and just as important to have a plan in place for how that tool will help you meet your business objectives.
Wikis can harness the collective intelligence that is distributed among individuals. But harnessing that intelligence may require that technical documentation organizations relinquish—or at least loosen the reins on—some of the control they have traditionally maintained over content and published documentation. In addition, roles within the organization may shift subtly or dramatically depending on how the wiki is implemented, managed, and used. Writers who have traditionally written content, for example, may need to adapt to focus more on content analysis, editing, and management, and to view themselves more as content collaborators and stewards than as content creators.
Wikis can lead to faster and cheaper development cycles for technical content or documentation, but the shift from traditional development processes to collaborative ones will take careful thought and planning, as well as risk management plans for handling problems that might arise.
If you’re contemplating a leap into the wiki world, consider the following guiding principles before implementing a wiki in your organization:
- Understand your business objectives
- Create an intuitive design by defining the initial wiki taxonomy or overall hierarchy
- Identify a cross-functional group of content stewards
- Create an advisory or governance board
- Develop a program that encourages and rewards good contributors
- Consider limiting your contributors
Each of these guiding principles is explained in more detail in this article.
Understand your business objectives to determine if a wiki is the best tool for meeting them
Start by clearly identifying your business needs and objectives and then decide whether wikis can help you meet those objectives.
Wikis are quickly implemented and easily learned, and they are excellent tools for creating and editing collaborative content because it can be written, reviewed, edited, and restructured or recategorized by anyone with the appropriate log-in permissions. In addition, wikis provide useful content management features such as content versioning, which allows recovery if information is incorrectly deleted or changed.
Consider a wiki as a “many-to-many” communication channel—that is, many content creators communicating with many readers (with neither role necessarily static or stable). If you determine that these characteristics make a wiki the best tool for the job, define its scope as it pertains to your business needs, then monitor and manage the wiki carefully to maintain that scope.
In addition to planning your wiki around how you hope or anticipate that people will use it, monitor how people are actually using it once it’s up and running. If you find that the contribution rate is low but user comments are turning into conversations, consider implementing a discussion forum, which might be more appropriate for this type of communication. Similarly, if you discover that many people are reading your wiki but few feel the need to contribute, reevaluate whether a tool such as a blog might be more appropriate for the subject matter. You may even decide that a combination of these tools—a blog for announcing content additions to the wiki, for example, or wikis with built-in discussion forums where conversations can take place—best meets your needs.
Determine during the planning phase how you will assess wiki content for its long-term corporate, product, or documentation value, and how you will move high-value content into other media or content management systems. Content on a wiki may be part of a larger content or product lifecycle, with wiki development as simply one phase in that lifecycle. Once wiki content appears to be stable and no longer requires collaborative effort or editing, follow the plan by moving that content to a web site or into your conventional online or printed documentation.
As the wiki grows, you may determine that the site has evolved in directions you hadn’t anticipated. Revisit your business needs and, if necessary, reevaluate the scope and goals of the wiki.
Create an intuitive design by defining the initial wiki taxonomy or overall hierarchy
Before seeding your wiki with content, consider how it should be organized.
Wiki users set adrift in an unstructured environment are not likely to quickly impose order in a way that makes sense for most readers, and an inability to easily determine where to find or contribute content can frustrate users and discourage participation. At the same time, too much structure could dissuade active participation and lead to lost opportunities to understand how users think content should be organized.
Although we often think of technical documentation organizations as “content creators,” they also structure content so that customers can access information quickly and efficiently. Put these skills to work in your wiki by providing initial structure at the highest levels of content organization. Visitors and potential contributors to the wiki should be able to understand at a glance how information is structured.
At the same time, understand that flexibility is crucial to the success of a wiki. Provide a “drop box”—that is, a special page or section of your wiki—where users can contribute content that they are unable (or unwilling) to categorize within your initial taxonomy. Monitor this content carefully, both so that you can move it into the appropriate sections of the wiki and so that you can determine where the gaps in your taxonomy may lie.
In addition, monitor user comments closely to determine whether your wiki design contributes to quick and efficient information retrieval or contribution. Empty pages on your wiki may indicate that users don’t find a particular taxonomy useful or accessible, and you may need to reevaluate your design.
In other words, provide an initial and high-level content structure, then follow the lead of your users and be willing to adjust that structure if it doesn’t appear to meet their needs.
Identify a cross-functional group of content stewards committed to maintaining the integrity of the wiki and helping it to grow successfully
The freedom and flexibility of a wiki comes with its own inherent challenges, the most pressing of which is that content must be closely monitored and managed.
Along with your business needs and objectives, identify the appropriate cross-functional stewards who can take responsibility for monitoring and managing the wiki. Create clear guidelines, procedures, and role descriptions for these stakeholders, and ensure that everyone understands their responsibilities and levels of authority.
Wiki stewards can be divided into various roles. Wikipatterns.com, a site that describes itself as a “toolbox of patterns and anti-patterns that can be applied to understanding how to grow a wiki,” lists numerous roles important to the development of a wiki. These include “Wiki Champions,” those who are typically the early and enthusiastic adopters of wiki technology. In addition, the role of Wiki Champions can also include the following activities:
- Generate interest in the wiki.
- Determine and provide the appropriate levels of training at the appropriate times.
- Monitor growth through the implementation of usage-monitoring and statistics tools.
- Fix problems that could derail the wiki.
“WikiGnomes” or “WikiGardeners” work alongside champions to ensure the quality of the wiki by editing content, fixing links, maintaining formatting and overall appearance, and setting positive examples for others about how and when to use the wiki.
Regardless of the roles and responsibilities you develop in your wiki plan, starting with a small, focused, and dedicated team of wiki stewards can mean the difference between a wiki that helps you fulfill your business objectives and one that frustrates and confuses its users and is eventually abandoned or under–utilized.
Create an advisory or governance board to develop and oversee policies and to monitor wiki quality and usage
While wikis are often implemented or championed at the grassroots level, instituting an advisory or governance board can help ensure that wiki policies are continually developed, maintained, understood, and followed. The governance board should write the wiki policies and guidelines, which might include the following information:
- the charter and purpose of the wiki
- expectations of users and contributors
- wiki etiquette, including appropriate and inappropriate behaviors and content
- policy enforcement methods
- terms and conditions that contributors must read and understand (and possibly formally accept) before contributing content to the wiki
Policies and guidelines can also provide potential contributors with practical information about content style, editing, and classification. Policies and guidelines should be periodically reviewed and updated as the site evolves.
The governance board can also serve as an appropriate channel for change management. The board should create clear guidelines detailing the responsibilities of the board members and wiki stewards, and document processes for resolving issues, handling change requests, and so on.
Ensure that a clear communication channel exists between the wiki stewards and the governance board. Wiki stewards can ensure that the governance board is aware of problems that arise and issues that need attention.
At the same time, guard against governance that begins to take too much control and attempts to implement lock-downs or wholesale structural changes that could threaten the successful growth or innovative evolution of the wiki.
Develop a program that encourages and rewards contributors for accurate and complete content submissions
High-quality content is the goal of your wiki, and high-quality content submissions can reduce the effort required on the backend to edit, clean up, verify, or relocate content. To develop a program that both encourages high-quality content submissions and discourages vandalism, inappropriate content, or low-quality content submissions, consider implementing the following practices:
- Provide clear wiki policies and guidelines that are available to every user and that set the goals, the rules, and even the tone of the wiki. People will seek clues about how to “behave” in this environment. Provide that information up front, then reinforce it through careful monitoring and maintenance.
- Require a login or permissions system that requires all potential contributors to register and be identified by their real names.
- Use a star or other type of marker that publicly rates contributors based on the quality, accuracy, and completeness of their submissions. This practice both rewards contributors for quality content and builds confidence among other users that this contributor can be trusted.
Evaluate potential contributors’ motives for contributing to your site. People are more likely to take their contributions seriously, for example, if their postings have the potential to enhance or harm their reputations. At the same time, learn to distinguish innocent mistakes from malicious behavior. New users should not be punished or publicly chastised for posting content in the wrong area, for example, but should be allowed the flexibility to make mistakes, and then to learn from them.
Consider limiting your contributors to those with a particular role, qualification, or certification
In the early phases of wiki implementation, you may not be prepared—due to limited or unavailable processes or resources, for example—to monitor content contributions as carefully as they require. If that’s the case, consider limiting initial contributions to those users with particular roles (support engineer, for example, or technical writer), qualifications, or industry certifications that are relevant to your product or technical content. Content from trusted contributors can dramatically reduce the time required to read, edit, correct, delete, or move information in the wiki.
Don’t assume, however, that you can forego these activities altogether by limiting contributors. Instead, implement a skeletal monitoring and management program but develop a plan for growing the program to eventually allow for a wider contributor base. If your goal is to truly take advantage of “collective intelligence,” you will ultimately want to ensure that your wiki contributors comprise the broadest possible base.
Wikis don’t just provide collaborative spaces in which to create content, information, or knowledge. By providing a shared platform where your customers and users can come together to discuss and exchange ideas and knowledge, you are encouraging the formation of a community. Like any community, this one will have its share of opportunities, challenges, struggles, and triumphs, and it will be up to you to learn to manage it in ways that are beneficial to your company while still meeting the expectations of community members.
Wikis provide an excellent tool for collaborative knowledge creation and management, and they are relatively easy to implement and use, which are all factors that might encourage quick adoption in your organization. But without a well-conceived implementation plan, you could find your wiki quickly out of control. In this article, we’ve described six key principles that can help make your wiki successful. Although you may have to resist pressure to just “put a wiki out there and see what happens,” the ultimate rewards for your customers, your organization, your writing staff, and the developing knowledge you manage will be well worth the investment of time and planning.
Cisco Systems, Inc.
Michele Guthrie is a Technical Writer in the Knowledge Management and Delivery (KMD) group at Cisco Systems. Michele is interested in and currently leading teams related to Web 2.0 technologies. She is pursuing certification in project management and is a member of PMI. Michele has been active in information development for over 15 years as a writer, editor, instructor, and project lead.
Cisco Systems, Inc.
Neville Fleet is the Senior Documentation Manager for the Knowledge Management and Delivery (KMD) group at Cisco Systems, Inc., in San Jose, California. This group of 90 technical writers has overall responsibility for the majority of the software documentation for Cisco’s Internet Operating System (IOS). Neville has 25 years of experience in technical documentation and product management for major international corporations in the IT industry. Prior to joining Cisco in 2001, Neville held management roles at IBM’s Application Development Group, Mercury One-2-One, and Digital Equipment Corporation. KMD is currently in transition to an XML-based structured content environment.
Cisco Systems, Inc.
Paul Zimmerman is a Program Manager in the Knowledge Management and Delivery (KMD) group at Cisco Systems, Inc., in San Jose, California. He counts involvement with departmental metrics and Web 2.0 implementation among his interests at Cisco. Paul has been working in technical communications for over 18 years, including a management position at Lucent Technologies and individual contributions at Octel Communications, Touch Communications, and Comtech Services.