A wiki - a webpage that can be simultaneously edited by multiple users and (ideally) done without any experience writing HTML code - takes a legitimate stab at the elusive "one version of the truth" problem in the modern corporation. Traditionally, groups have shared information with one another by e-mailing around documents, making corrections to them, and then e-mailing the new document back to the entire group. One major downside to this method is that there's no ability for people to make changes at once and see the modifications their colleagues have made at the same time.
On the other hand, changes to a wiki get made in real time. Wikis also have much better version control, allowing you to revert back to a previous version if incorrect or unacceptable edits get made.
Choosing the best wiki platform, however, can be difficult. Both new and old vendors are offering an array of wiki platforms. But before you start thinking about vendors you need to do your research on your IT and end-user requirements, says Gil Yehuda, senior analyst at , who recently authored a
CIO caught up with Yehuda to talk about these seven steps, and what it takes to pick a wiki that's just right for you and your company, both from a technical and end-user perspective.
1. Pick a Software Delivery Model
Most wikis can be delivered to your company in three formats: on-premise (you install the software on your machines and manage it), hosted (software as a service (SaaS), where the vendors store all the data on their servers), or as an appliance, which is a hybrid model between the first two options.
According to Yehuda, many larger enterprises choose to go with on-premise installs of wikis, especially if their industry has strict requirements around what type of proprietary data (if any) can be stored outside their company's server farms.
The hosted SaaS model can be attractive for small and medium sized businesses (SMBs) with leaner IT departments that have limited resources and can't take on the burden of managing more servers and software. In addition, SaaS is adopted sometimes within large enterprises by line of business departments who are tired of waiting for IT to provide them with a wiki or other collaborative technologies.
The third option, a wiki appliance, has also gained some popularity, Yehuda says. An appliance is what software gurus (and the tech jargon they speak) would call a "plug and play" offering. In other words, a company can plug the wiki appliance into their existing server environment, and after some minor install work by the vendor, the wiki is up and going, hosted in their current server farm.
Yehuda says the appliance also solves two complicated problems faced by companies interested in wikis. On one hand, many companies don't want to go through the complexity of installing the software themselves (making a full on-premise install unattractive), but they also have strict rules around storing data externally (thus eliminating SaaS as a viable option). An appliance "helps address those two problems," Yehuda says, by providing the in-house storage but avoiding the headache of the install.
2. Keep Track of Who's Who: Authenticating Users According to Yehuda's report, it's important that a wiki integrate with your existing authentication environment, which could include a single sign-on or LDAP (Lightweight Directory Access Protocol). On an enterprise wiki, there can't be any anonymity when it comes to who edits it. An enterprise wiki should verify the identity of each user so that edits are attributed to the right user. Activity on the wiki needs to be transparent, clear and traceable.
Any enterprise wiki should also have ways in which to set access. Some wikis, for instance, should only be accessed, read and edited by a group of executives, while other more public wikis can be modified by anyone within the company.
3. Give IT What They Want
If you picked an on-premise wiki, you likely did so because it would fill a certain set of IT requirements around data storage and integration with existing enterprise systems. If that's the case, you need to talk to your IT enterprise architects, who can give you the nitty-gritty requirements around what will work (and what won't) for installing an enterprise wiki.
What kinds of things will they consider in finding the right wiki? For one, they might have a certain set of standards and frameworks they prefer for Web applications, and any wiki would have to fall into that category.
Regardless of architecture, all IT administrators will want a wiki that allows them to analyze how much server space it occupies and tracks usage. If the wiki catches on like wildfire, for instance, and many people start using it, they need to make sure they can give it enough server power on the back-end.
4. Plan for Mistakes
As people use a wiki, accidents can happen. For instance, most wikis enable people to edit the document at the same time, but due to technical glitches, when the first person hits save, her edits get saved while the second person's get lost.
That's a very specific problem, but Yehuda says it's one you should ask a prospective vendor. Their wiki must track all the changes that occur to a wiki and have a way to revert back to a previous version to find valuable edits that accidently get lost in the saving process. The happiness of your users - who ultimately drive the success or failure of a wiki since it's a tool that harbors collective intelligence - depends on it.
"There's nothing more frustrating than donating content into a wiki and finding out it got lost because someone else was editing at the same time," he says.
5. Manage (and Follow) Change
Key to properly managing corporate wikis are good notification tools that allow users to keep up with changes or modifications made to wiki documents of interest to them.
For instance, if you worked at an ad agency and were concerned about a particular pitch document that you were a key author for, you might want to know momentarily after a change occurs to the wiki so you can go check it.
As the Forrester report lays out, there are two main technologies to enable this notifcation: e-mail and really simple syndication (RSS). Yehuda notes that it's nice when a wiki can decipher between minor tweaks versus big changes to avoid an excessive amount of e-mails.
For the more Web 2.0 inclined, however, RSS feeds provide the best way to monitor updates. Your wiki should be able to tell people in the feed what pages were changed recently, and give some sort of idea how big they were in scale (and who made them).
6. Plan for Wiki Success
Assuming users like the wiki, it's important that the wiki has features that make it highly searchable and easy to discover information as more and more information gets added over the years.
One feature that most wikis have (or should have) is tagging. For instance, you might tag a document as "marketing" or "operations." However, general tags such as those can lead to problems over time as the wiki (and its pages) grow in size. As the report notes, "disciplined wiki page tagging makes pages easier to find." Create a set of tags with your group when you begin rolling your wiki out. Some of the tags will be generated organically by users, but give them guidelines.
Make sure your wiki has a strong search capability. One of the ways to ensure a strong search bar is a strong tagging system (which the search feature works in tandem with to return relevant results).
7. Consider Extra Features
The Forrester report notes that you should also examine what value-added features your wiki vendor offers and how that could resonate with your users.
For instance, if you're a large corporation, wikis that offer multilingual support can help bridge communications between offices that speak different languages.
Another feature is the ability to attach documents, which can be especially helpful if you want to use the wiki as your document management system. Other wiki software allows you to make the wiki accessible via a widget that you could embed on a personalized web page, such as .
In assessing the usefulness of these extra features, and a wiki overall, Yehuda says start with the toughest end users in the bunch. If you can satisfy them, you can help make the wiki work for anyone.
"Go to the grumpiest people you have and have them test it," Yehuda says. "Hear their complaints. It will help you figure out how to provide a wiki that's helpful and not cumbersome."