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.
I like the corporate refridgerator analogy - wikis start out bright and shiny but end up smelly and fully of items of doubtful origin!
Nice analogy with the office fridge. Ours is a stink hole just like our wiki is. I am half certain that Google is on their way to rescue the corporate wiki with their own wiki animal that will come with their Google Apps offering. If they budle it with Google Apps, it won't get much publicity, but if its stand alone, it may have a chance.
Google can offer what most wikis lack, and that is a quality search algorithm that returns the most relative wiki pages. Sounds easy, but it's really not.
Whatever they come up with, it won't be hard to beat what is currently available in the wild today.
You make a very good point. Google search is part of the solution, but Wiki salvation will not come through search alone. There needs to be the equivalent of a defrost cycle that gets rid of all the stale old crap clogging the wiki/refridgerator. there also needs to be some sort of a workflow that forces a refresh cycle for key documents, such as a quarterly process that updates last quarter's results and puts up new objectives for this quarter.
Post a Comment