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.

4 Replies to “Wiki While You Work”

  1. Josh
    Great to see a real life example from someone, who has set up a workplace wiki. I think each workplace will make its choices based on its own needs and the ideas of the wiki champions who introduce the idea. There is not a lot of shared experience out there yet, so it was good to see your story.
    Mark

  2. Hi Josh
    Really excellent post. I am a senior manager at a very large regulated company (pharmaceuticals). There is, in my opinion, inordinate concern within the firm about the legal exposure of permitting wikis within the firewall. The argument is apparently that we are increasing the volume of potentially inaccurate information that might be discoverable in any legal proceeding. For example, in a scientific wiki, it is possible that the safety profile of a medicine under development could be incorrectly or prematurely stated.

    My opinion is that such posts in relatively “controlled” environments such as wikis pale in comparison to the rubbish that can be broadcast via email, instant messaging and the like–all of which is also discoverable in such situations.

    Any thoughts on this, or any information that might be useful on this topic?
    Best regards,
    Lee

  3. Lee–very interesting example. The electronic storage nightmare that is discovery, is something I’ve become well-acquainted with in recent times. I call it a nightmare, not because I think there’s anything inherently bad about it, but because it’s a huge amount of work.

    When I read your comment, at first I thought “who would want to add to that?” but considering it more, I agree with your comment about the “relatively controlled” environment enabled by a wiki. (actually I think, perhaps it would have been smart to implement one a long time ago, but that’s another story). I’m wondering whether a wiki coudl actually make some aspects of discovery easier and more clear for all the parties involved. If nothing else, it could centralize and give order to a lot of chaos in a way that e-mail archives or instant messaging or a file server can’t. But I think it might be able to do more too.

    Our electronic communication methods now record and disseminate all kinds of communication in ways that nobody used to think about or intend. I believe you essentially said that this can lead to errors, and I would guess, often errors that take place this way can come about even through good-intentioned efforts. It’s a massive amount of work to find and understand what these electronic artefacts are and mean.

    With e-mail, it’s sometimes hard to understand the path of the message. Has it been forwarded outside of a work account? Who has been copied on which messages, did they see the entire string of messages or only part? At which points? Did the person forwarding a message change any part of it before forwarding it? Was the content of an attachment accurately represented or received? There are more issues, but e-mail is wild. It gets passed around very easily, and often though innocently, with little understanding of what the actual content (including things like tone of voice, intentions, etc.) of the e-mail message may mean or refer to. Unlike e-mail, wiki pages are not so easily sent to outside mail accounts, nor can they (if set up this way) be changed from person to person without the open and visible tracking of those changes.

    In an e-mail, people might be prone to summarize or leave out important points because these points might not be necessary to their particular message (though perhaps very important in some other way) or they don’t take the care to recopy all the information needed or are just careless. Maybe they don’t have the most up-to-date information to refer to in their messages. Again the easy linkability of wiki pages encourages people to link to the same, already existing pages (rather than reinvent the wheel). If they need to, they can correct and update those pages (of course, the history is typically tracked by the wiki with the person’s name, a timestamp, and before/after views), which are then also available to other people that need them. In other words, instead of having many copies of some information that could be inaccurate, there could be a page that many eyes refer to and visibly maintain its accuracy.

    A wiki might also decrease the confusion that results when someone innacurately responds to a forwarded or group e-mail, because s/he didn’t read the entire string of messages or certain key recipients were left off and didn’t have full knowledge of what was being written about. I suppose there is no guarantee that anyone will read an entire wiki page either, but at least there is just one version of the wiki page rather than any number of copies of different e-mail accounts.

    The wiki, though it feels at first glance like a lot of chaos, actually imposes a transparent control on its content which e-mail, instant messaging, shared file servers, etc. lack. If people were to use a wiki more frequently and e-mail less frequently maybe it would ultimately save a company a lot of work during a legal discovery process.

  4. Hi Josh,

    thanks for the nice words on Wikka. I agree that the popular security concern (“in a wiki everyone can edit and read anything”) is truly unjustified. Several 2nd generation wiki engines (including Wikka, but surprisingly not MediaWiki) offer fine-grained ACL allowing admins to determine who has privileges do access specific kinds of content (e.g. who can read/write/delete a page, read/write/delete a comment, upload/download a file etc).
    We’d love to hear more about your experience using Wikka: if you want to share some ideas or requests, feel free to start a userpage on our website or pop by on our #wikka IRC channel at freenode.net

Leave a Reply to Lee Ward Cancel reply

Your email address will not be published. Required fields are marked *