Here’s what I think it’s important to think about when deploying a Wiki/Blog environment:
I think Wiki/Blog (let’s just say self-service publishing) can be very powerful where processes for publishing “formal” information channels to the Intranet are in place. That is to say, if the right people are publishing to the right place on the Intranet and have the right editorial flows/governance around that, then adding an open, less-structured layer to that is fine. If, on the other hand, if there are no good controls/process/tools in place, then handing everyone a Wiki is too loose a solution, in most cases.
Certainly there are models of total self-publishing which have worked well. Rational, for example, followed that model but this was a particularly techy and tight corporate culture (at least, before IBM acquired it ;) ). So overall, my advice would be to make sure they have their formal content publishing ducks in a row before introducing self-publishing, and I certainly would not advocate replacing a full-blown CMS with a Wiki.
Now – having said that, I think that there are some compelling examples of where Wiki can add value: In one example I recently heard, remote engineering teams used a Wiki to share information from Russia to China, these teams used the environment to share knowledge about certain work where they did not know it had been done before. So here’s an example of how Wiki can cheaply and easily empower a global workforce to connect over common topics.
I think the right processes around a Wiki installation should include some or all of the following:
Log in using pre-established common authentication to ensure accountability for posts/entries.
Customize the template to reflect the common look and feel of the rest of the Intranet, but also clearly identify the space as a Wiki or Blog
Publish and, if possible, require acceptance of, codes of conduct (or, to save proliferating codes of conduct for every new technology, make sure online communication is included in the overall code of conduct for the corporation)
Publish FAQ or Help for getting started, how to, etiquette, etc.
Search: Require users to “opt-in” to include Wikis in overall site search
Require labels/tags before publishing.
Automate archiving after n days of unused wikis, along with prompts/emails to owners advising of this archive process (“Your Wiki will be archived in 15 days for lack of use..” type of thing)
Use RSS output if available to provide feeds of Wiki content into Portal implementation (or elsewhere, as desired, on the Intranet)
Content managers/editors should know how to connect Formal content (stories, news articles, features, etc.) with these informal sources; CMS templates should allow content authors to easily add links to related Wikis/Blogs on a given topic, in a consistent way. (or provide a window connecting formal communication with related buzz on the matter)
