Wiki While You Work

The Globe and Mail published an article about using wiki applications in the workplace. While not a new notion, this is the first time I’ve seen it in a regular newspaper and not an IT business rag. A point the article touches on is the wiki’s security. I think wiki security may be one of the more misunderstood issues about using a wiki for work and an important differentiating factor in determining when to use an enterprise content or document management system (CMS/DMS) and when to use a wiki. In fact, I think it’s hard to beat a wiki if you need an application to capture and disseminate employee knowledge.

“One drawback is security. Much of the hype around wikis concerns their ability to place everyone from the receptionists to clients to chief executive officers on the same virtual playing field.”

The key phrase above is that it puts people “on the same virtual playing field.” Useful things take place when people are uniformly able to document their activities, collaborative or otherwise. Simplicity is a defining aspect of wiki applications–they make it incredibly simple to collaborate on developing, publishing, or otherwise contributing to company information, documents, in some cases products, etc. I’ll talk about an internal wiki only, as I realize that one open to clients as well may present a slightly different set of issues. Still, I’d argue that in most cases the somewhat loose security issue is more of a benefit than a drawback. Let me illustrate this with how the company I work for, uses one.

Some time ago, frustrated with the problems of repeatedly sending mass e-mails to everyone in our company, I set up an internal corporate wiki. A wiki is excellent for work that is in constant flux or must be accessible by everyone in the company.

• communicate important news or announcements
• inform about policies that must be adhered to
• distribute documents
• collaborate on work issues
• capture and disseminate the day-to-day knowledge that employees develop

I think these things fail through e-mail but work with a wiki. I think most of these things are usually (though not always) too encumbered with hierarchy structures, metadata entry, and access controls to be the most effective for the types of things I mentioned above. Even when people save e-mail messages, they must make repeated archaeological expeditions through their e-mail histories. If announcements need to be referred to in the future, there’s no guarantee people will be able to find them in an inbox. Policies and problems that have been solved are likely to be forgotten if they’re not easily present and visible, as they are in a wiki. Ensuring that people always use the most up-to-date versions of documents means making them easily accessible and that is so nicely accomplished with a wiki. Using e-mail to collaborate on projects can become a nightmare of criss-crossing information, which often leaves people out of the loop. If people are in the habit of working with a wiki on all sorts of general day-to-day tasks, it becomes an automatic, company-wide storehouse of employee knowledge.

Using a wiki facilitates these activities. For example, at TEC, internally we use the fantastic, open source Wikka Wiki application. It’s simple enough that people can be productive with it after about five/ten minutes of instruction. It doesn’t confuse with over-sparkly and burdensome features. It’s fast–takes fractions of a second to access and edit in a web browser. It doesn’t require manipulating difficult access permissions. These are all important features because they make it at least on par, if not sometimes easier than sending an e-mail or accessing a DMS. If you want to change peoples’ work habits from constant e-mail use, then I think the alternative ought to be at least as easy and efficient or else offer something so incredibly good as to compel its use.

Before the wiki, people would forget what an important policy might be after six months. Now, even if forgotten, it can be easily found for reference. Before the wiki, frequently used documents were sometimes difficult to disseminate in their most up-to-date form. Now they’re updated, in short order, on their corresponding wiki page.

Before the wiki, information about projects that different groups in the company had to collaborate on, was spread across different people’s e-mails. There was the risk that someone wouldn’t get all the information s/he needed. Now it gets collaboratively updated on pages that anyone within the company can see, which has the added benefit that sometimes people without an obvious, direct connection to the project can discover it and contribute or use it in positive ways that nobody would have imagined previously.

I don’t think a wiki replaces a DMS or vice versa. A DMS might sound like it is designed to capture and better enable such collaboration but I don’t believe that is necessarily its strongest point. I think a DMS is probably better-suited to developing documents that require tight version control, traditional hierarchy structures, and cannot necessarily be developed as content within web pages. A DMS might be more useful for archival purposes or for documents that are sensitive and absolutely must have special access controls. But a DMS tends to be more cumbersome in the security and access area, and thus loses utility in the area of capturing and disseminating employee knowledge.

Spreading the wiki. In the past, people sometimes would tell me about some sort of project they needed to work on or information they wanted to store in an easily usable way. I’d recommend they try the wiki to facilitate it. So they’d ask of course, “what’s that?” and I’d spend five/ten minutes explaining it. The interesting thing is that then they go off and explain it to other people on their teams, then the different teams work on things with the wiki, word-of-mouth makes its use spread. I’m sure this isn’t a 100% effective way to promote its use but I was pleasantly surprised that after implementing the wiki and announcing it, people started pushing its use of their own accord.

A system that requires a lot of security, perhaps needing more of a top-down approach, wouldn’t permit this type of usage to happen. Setting up access controls, accounts, and maybe designing structures for how a company uses its systems of collaboration and knowledge sharing may be time-consuming and ultimately not do the job for which they’re intended. On the other hand, a wiki method allows this to self-organize. The chaos of knowledge that frequently gets developed and lost throughout a work place gains a facility in which to reside and that attracts use.