Build an Enterprise Wiki
Wikis have been around for over a decade. During this time they have proven to be an extremely useful tool for many organizations and the internet at large. Wikipedia.org is one of the top ten websites and the poster child of what a successful wiki should be. It is no accident that an immense number of websites reference Wikipedia via hyperlinks; including this one. Nevertheless, creating a vibrant and successful wiki within a larger organization is not a trivial task. We will describe many of issues to consider while engaging such project.
To download a PDF copy of this article, go to the Download menu or click here.
What is a wiki?
It is the somewhat subtle corporate strategic advantages that are worth their weight in gold.
A wiki is a web software application which allows people to create, edit, publish and search information via wiki web pages on a network. The network could be the world-wide-web or an intranet. These pages are generally interlinked to one another, thus making navigation easy. A person only needs to use a current web browser such as Firefox, Google chrome, Safari, Internet Explorer, etc., in order to create wiki pages and/or modify existing pages.
Since software tracks and backs up every change made to a wiki page, it is extremely easy to undo changes, restoring the wiki back to a previous state. Wikis are based on the premise that literally anybody within the organization can and should contribute to the wiki: Collaboration is Key!
Of course, one could set up security permissions which would restrict the viewing or modification of portions or all of the wiki. However, this is generally not the correct approach because collaboration is Key.
There are many technical advantages to a wiki such as:
- Wide range of data types; text, video, sound, images, files, etc.
- Wide accessibility since anyone can edit it
- It is easy to train people on how to use a wiki
- Universal access to up-to-date information
- Ease of simultaneous collaboration
- Unlimited number of document revisions
- Non-techies can create content and publish it quickly
- Widely available Open Source software offerings
As compelling as the technical advantages are, it is the somewhat subtle corporate strategic advantages that are worth their weight in gold. Over time, wikis can embody the organization’s intelligence, policy, direction and culture: An important component of Enterprise 2.0.
By reading a wiki newcomers to the organization can quickly come up to speed as to the “how to” and “why’s” of the organization without relying on a hand holding process.
Wikis can quickly become consensus builders through collaboration. This is an area that should not be looked upon as the “tyranny of the mob” but rather as an organization’s Collective Intelligence, Eventually, the wiki repository will be mature enough so that one could perform data mining on it and discover organizational trends.
We should be mindful that there are several caveats, if we are to achieve a successful wiki project.
Such organizations might not be willing to cooperate to make information readily available and it might even sabotage the project.
To begin with, we should dwell for a moment on the implications. For example, some organizations are overzealous about their information. Furthermore, departments within such organizations might not be willing to cooperate to make information readily available and it might even sabotage the project. They might feel threatened by the seeming loss of control and/or advantage, to what they consider their information. Up-to-date wiki information may contradict the information coming from a given department and in some cases this might make them look bad.
For larger organizations, setting up a wiki is not a trivial matter. In fact, the technical aspects of it are not the problem. As we said earlier the wiki software has come a long way. Instead, the non-trivial aspects of a wiki project have to do with issues such as: corporate policy, department tasks or roles, obsolescence, legal / liability, security, wiki content responsibility, wiki reliability, editorial roles, scrap-data, technical support, training, incentives, etc.
Your project may require the creation of new functional roles and responsibilities which encourage organization-wide collaboration and volunteerism.
Without a doubt, a good strategy will increase the chances of success of a wiki project. Top management’s early buy-in is highly desirable. As such, management should ask a) How important is the wiki project to the management of the organization and b) Is this project viewed as critical to the overall well being of the organization by all? It is also important to identify the Corporate Stakeholders and perhaps draft a simple but concise Mission Statement for the wiki project.
We could also increase the project’s viability by tying part of the executive team’s bonuses to the success of the wiki, such as: number of articles posted and number of page views within the exec’s span of control. We will discuss incentives towards participation later on.
Next, one needs to identify a member of the top management team to become the project’s champion or executive sponsor. His or her role is critical in smoothing out any bureaucratic hurdles and keeping the necessary enthusiasm; moving the project forward. Of course, this is also true of any major project.
Although at first, there might be the temptation to make IT the project’s champion since it seems like a shoe-in, one should consider an alternative project driver instead. IT’s focus might be to narrow and technically inclined towards its needs. Instead, an organization-wide-wiki should strive toward a broad base audience.
Openness must be a key strategic policy.
Openness must be a key strategic policy. It should be emphasized in order to counter the almost knee-jerk reaction of trying to impose a strict hierarchical form of organizational control on the wiki. For many people who are accustomed to viewing the work environment as a giant organizational chart in which people’s duties and responsibilities are neatly packed into little boxes, the idea of a self-organizing and self-regulating wiki, which is based on a trust-honor system, is simply not feasible. It may take some mentoring effort to bring most participants on board to an open-world view.
Finally, we need to focus on the wiki project goals. Effectiveness, efficiency and creativity should be prominent on this list. We should also include wiki metrics, such as the number of wikis contributors, which allow measuring the level of success or failure and perhaps, in the latter case, allow us to institute corrective actions.
Similar to other software projects, the wiki project team will draft a detailed plan with its corresponding time-table, tasks and deliverables. Some tasks will be directly defendant on the particulars of the organization in question. For example, the organization may be operating in multiple countries and it may be necessary to support multiple languages. Training may have to be conducted in multiple languages as well. It could be that a phased approach is used whereby different organizational units are rolled into the project based on a schedule.
The legal and security teams will be responsible for guidelines on wiki usage, disclaimers, liability issues, slander, discrimination which should be discussed early on. The objective is to cover all the legal and security bases without hampering the openness or wiki collaboration efforts. On the security side, guidelines should be drafted which will prevent, for example, publishing extremely sensitive organizational information. Once again, this is not much different from other software projects. In a way, there could be a lot more latitude in a wiki project, provided that the wiki remains on the intranet away from the public.
Wiki software selection will take some time. Be careful not to fall prey to decision-by-committee where a lot of compromises and personal biases will come up with a less than optimal product for your organization. There are many commercial and Free Open Source (FOSS) offerings. Most provide a robust basic functionality. Some may interface better with other software products currently used by the organization. One of the arguments that come up time and again regarding commercial products versus FOSS products is that of support. For some people, the support element is more pressing and for other people the ability to modify the code is more important. Finally, the wiki software chosen should first and foremost work for the whole organization.
We mentioned Wikipedia.org early on. It is an excellent wiki and a good choice for different organizations. Their wiki engine is a FOSS application built by Mediawiki.org. It is based on the PHP language and runs on the LAMP platform which is also FOSS and very common on the Internet. This wiki application is constantly being upgraded to make the software more secure, to eliminate bugs and make it more reliable. Because one has access to the source code, this wiki can be customized to integrate it with other applications. LDAP is supported out-of-the-box and this would allow an organization to include the wiki into its single sign-on strategy.
Other IT planning considerations include:
- CAPACITY PLANNING
- DATA SECURITY
- DATA CLASSIFICATION
- DISASTER RECOVERY
- CRITICAL SYSTEM UP-TIME
Planning should also include the wiki permission or editing structure which is controlled via an access control list or ACL. Using the wiki’s ACL you will assign the system administrators, sysops, updaters, viewers, page creators, etc. Much care should be taken so that the permission restrictions do not stifle the wiki’s growth. Remember the value of a wiki is its broad base openness. However, some wiki pages, by the very nature of their content, may require limited or no editing capability other than that conferred to their originators. Some super users may be allowed to override changes.
Depending on the wiki’s design architecture you should plan for growth. For example, you may choose to have multiple wikis within your organization. Planning to link them so that a search on one can also search the other wikis, should be considered. But even if you only have one large wiki, you may in the future, allow your customers, suppliers and people from outside of the organization to have access to portions of the wiki. You may choose to implement named spaces to this effect.
Let’s not forget to plan for training. Some wiki software applications require using a simple markup language which might confuse and deter some people from collaborating. Training materials such as videos can be made available on the wiki itself.
We usually think that volunteer work is associated with not-for-profit organizations. We assume that for private enterprise, work activities such as contribution are regulated by commercial interests. In other words, employees are paid to perform a job and that’s all there is to it. One could be tempted to view an enterprise wiki in the same manner. But is this actually true? If we stop and think abou it for a minute we could come up with countless instances where actions performed by employees for the betterment of the “common good” are not mandated by their job descriptions. This is especially true when dealing with customers in which an employee will go the proverbial “extra mile” to help a customer; over and above his or her job’s responsibilities.
We believe that volunteer work within the organization will make or break a successful wiki project; it is that important. This is true for Wikipedia.org which relies almost 100% on volunteer effort, and it’s also true for any other wiki implementation, as well. Therefore, we should dedicate a great deal of effort to encourage volunteerism until the wiki reaches critical mass.
Critical mass is a point in time whereby the wiki becomes self-sustaining. We will know that this point has been reached when large numbers of people access the wiki periodically in order to obtain information that pertains to their job. At the same time a fair number of people continue to add new information (contributing) to the wiki, thus making it fresh and relevant.
For example, a ratio of 100:1 tells us that for every 100 users only one person contributes to the wiki repository.
Identifying the volunteer ratio early on will allow for making adjustments which will improve the success of the wiki project. This important metric is based on the number of people who contribute versus the number of people who use the wiki. It is well known that a significantly smaller number of people actively contribute. If the ratio of contributors is too low then project might be jeopardized.
For example, a ratio of 100:1 tells us that for every 100 users only one person contributes to the wiki repository. If your organization has 1,000 people, only 10 people will contribute in the creation and maintenance of wiki pages. At first glance it may not be enough. We have to remember that these volunteers are not dedicated full time, so in practice the ratio might be much smaller, say 200:1. If on the other hand we have a volunteer ratio of 10:1 then in an organization with 1,000 about 100 people are regular contributors; a much different picture emerges.
We need to create incentives to stimulate wiki collaboration. For example, we could keep track of those individuals who are top contributors and promote them as employee of the month. Mention them in a monthly newsletter. If no newsletter exists then create an e-newsletter for the wiki and mention these people there. Also, we could create a healthy competitive environment whereby top contributors will be listed on the wiki’s landing page. Peer recognition is very high on the list of incentives which have worked out well before.
Other forms of volunteer incentives include awards, prizes, bonuses, free tickets to an event, comp-time, favorable employee reviews, etc. You could add many other forms of incentives to stimulate collaboration.
Setting up a successful wiki within a large organization can be a challenging project. A wiki project will parallel many other IT based projects. From the technical perspective these are not major challenges. However, the organizational challenges are more difficult. These challenges can be met by a good strategy, planning, execution and a lot of dedication toward stimulating collaboration across the enterprise.