If you want to see the possibilities and limits of Web 2.0 as they apply to the enterprise, there is no better place to look than a Wiki. In part because they are so easy to get started, they positively invite a fatal lack of planning.Wikis start out wonderful but rapidly morph from a grand experiment in bottoms-up community to a wasteland of out-of-date marketing collateral. As such, they become exhibit "A" that the self-service concept only goes so far in IT.
Without up front planning, clear ownership and constant maintenance, the primary service offered by self-service IT is the ability to shoot yourself in the foot. David Precipio recently had a good post about the future of Wikis that got me thinking about ActiveGrid's own less than stellar corporate Wiki.
Six months ago, we launched a bold new corporate wiki that rapidly became an object lesson in why wikis get a bad rap. Here are some of the lessons learned from our own experiment in wiki-style self service:
- Designate a wiki "csar": just like our communal refrigerator, every so often, someone has to come in with a big garbage bag and clear out all the stinky stuff.
- Define required functionality: it is amazing what a wiki won't do out of the box. Ours doesn't keep people logged in on their computers, has bizarre navigation and an almost unusable search functionality. Some critical functionality for us is the ability to publish MS Office documents (particularly tables) directly to the wiki.
- Pay for an expert who can set it up right: we are using Twiki, which needs someone with perl expertise to administer it and its many plug-ins.
- Create a clear update process: in addition to an overall csar, there should be a clear owner for each section and a process for updating document on a regular basis.
Adam Carson of Morgan Stanley made a similar point recently at the Office 2.0 conference (podcast here), when he pointed out that Morgan Stanley's use of wikis worked because of, not inspite of, heavy involvement from IT.
