- Duplicate work; as long as the wiki doesn't replace existing processes, placing things there is simply additional work. Moreover, because it's additional, there's no guarantee that any desired piece of information will exist in the wiki.
- People don't like not having an "owner" to a document, especially regarding private edits and such.
- Wiki's make you search for a topic (i.e. they require work), whereas email threads are pushed to you by others motivated enough to CC. Unfortunately, my motivation in tracking an issue will never be the same as the person directly affected by the issue.
- Mostly, however, wiki's don't provide a substantial functionality improvement to what I'm now going to dub the "enterprise wiki": i.e., Word documents on a shared drive. Here, Windows provides structure (well, technically Solaris does, but it's accessed by the user via Windows Explorer), while Word provides the standard document editing interface (although we do work with many document types).
The main drawbacks are terrible search, manual (and content limited) revision control, and an inability to track updates.
The main upsides are a rich editing environment for documents (compare Word to a textarea), support for any document format (don't like doc files? Use something else), and the opportunity for private collaboration & edits without implementing temporary ACLs (i.e., copy a file to the local drive, and email back and forth until publishable).
Personally, I think wiki's are great for collaboration between a heterogeneous, dispersed population. However, at the large corporation where I work, Word + Explorer is a ironic example of the worse-is-better Unix approach (many tools, barely working together) clearly beating the wiki/web-based Monolithic design.
Wikis are for text that people want to read and change, regardless of its source. This makes them ideal for Wikipedia but inherently out of tune with the big-corporate environment, a large crowd in which people prioritize based on who is talking to them. A boilerplate memo from the generic HR-department address can be skimmed very quickly; an email from HR addressed solely to you might need to be read; an email from the HR rep who has been assigned to your team might need a more careful reading and perhaps an acknowledgement; even a boilerplate email from HR might need careful attention if the author is someone you befriended at the company Christmas party.
You don't want an automated alert every time your boss's assistant reorders the columns on the weekly report. Ideally, your boss will only call your attention to the report when it is important for you to read it. That's part of the boss's job -- to protect your attention so that you can spend your time being useful instead of rooting through irrelevant wiki documents! And how is the boss going to direct your attention? Email. And while she's sending email, what's wrong with just pasting the information itself right into the message and saving the recipient some additional clicking?
Put all that stuff on the wiki and file off the TOs and FROMs and datestamps and you might as well just label it BOILERPLATE, because nobody's going to have the time to sort through it all. Even a genius super-librarian can only help so much, because the social context of email (its timing; the number and identity of the CCs, the history embedded in all the quoted emails that extend far down the page, etc.) is hard for a librarian to capture, let alone convey in wiki form. And, no, the version history does not help much. (Deriving people's motivations by reading their diffs is a techie art, not a liberal art. And emails carry a semi-reliable record of who has read the message as well as who has helped to write it.)
(A minor note: You left out Powerpoint in your description of the "enterprise wiki". It's pretty important, and for more than just stupid effects-laden bullet points. I worked in an engineering firm. All of us were capable of understanding wikis. I never tried to set up a wiki, though, because people communicated in charts and graphs, and at the time I couldn't find a wiki whose chart-and-graph workflow was anything short of "excruciating". The state of the art was to mail out arguments that consisted of stacks of graphs with commentary, rendered as Powerpoint docs.)
- Duplicate work; as long as the wiki doesn't replace existing processes, placing things there is simply additional work. Moreover, because it's additional, there's no guarantee that any desired piece of information will exist in the wiki.
- People don't like not having an "owner" to a document, especially regarding private edits and such.
- Wiki's make you search for a topic (i.e. they require work), whereas email threads are pushed to you by others motivated enough to CC. Unfortunately, my motivation in tracking an issue will never be the same as the person directly affected by the issue.
- Mostly, however, wiki's don't provide a substantial functionality improvement to what I'm now going to dub the "enterprise wiki": i.e., Word documents on a shared drive. Here, Windows provides structure (well, technically Solaris does, but it's accessed by the user via Windows Explorer), while Word provides the standard document editing interface (although we do work with many document types).
The main drawbacks are terrible search, manual (and content limited) revision control, and an inability to track updates.
The main upsides are a rich editing environment for documents (compare Word to a textarea), support for any document format (don't like doc files? Use something else), and the opportunity for private collaboration & edits without implementing temporary ACLs (i.e., copy a file to the local drive, and email back and forth until publishable).
Personally, I think wiki's are great for collaboration between a heterogeneous, dispersed population. However, at the large corporation where I work, Word + Explorer is a ironic example of the worse-is-better Unix approach (many tools, barely working together) clearly beating the wiki/web-based Monolithic design.