April 30, 2008
Corporate wiki deployment pitfalls
Posted by freelance samurai under corporate wiki, wiki | Tags: corporate wiki, deployment, pitfalls, wiki |[2] Comments
This is actually a repost (and remake from a bit of knowledge learned from the comments on the original blog post and throughout the deployment of yet another corporate wiki) of something I wrote on Safira’s wiki (you can find the link on the side bar), it’s more of an experiment to post it here as well…
So how do we go about to implement a corporate wiki?
ok, let’s brain storm a bit here…
First and far most Mediawiki has some serious input problems. It somehow resembles the way you input stuff on Latex, but without the permanent brain damage, It drives less tech-savvy users away and a wiki should be able to be edited by everyone, not just the people who are inclined to learn it’s Dante-like markup language.
To-Do: install a proper wysiwyg on your wiki. TinyMCE and fckeditor are good choices. As a simple workaround (but not nearly as good as the previously mentioned) you have a very cool greasemonkey script you can painlessly install called wiked.
And if you don’t? well… people will still edit it, they won’t like it, but they will. Commitment will be slow and painful. Reminiscent of the “whippings will continue until moral improves” motto.
Then there’s the desert. We are used to waltz into wikipedia or KDE TechBase and have the wiki populated with articles, it thrives with an active community, discussions and trolls…your corporate wiki is as fruitful as a 70 year old lady with the hots.
To-Do: small task force to populate the wiki before the whole team/corporation/client even has a glimpse of it.
And if you don’t? be ready to answear “what for?” questions, low level of commits (and commitment) and desertion from the intended end user. And if you are planning a wiki for a team that already has fine documentation, you can rest assured your team will continue to use that documentation (because it’s there!) and be spiffy about the wiki.
Limbo syndrome. So we have wonderful documentation (gotta love those templates!) and we have over 50 task procedures, niched in a fetal position in those documents. And then there’s a wiki…it’s got 15 of those documents, and the new ones someone added to the wiki but didn’t bother to write the doc for it…(figures, you’ve been pushing the wiki pretty hard, right?) information is scattered, some are up-to-date on the wiki, some on the documentation, some doesn’t exist but should…damn.
To-Do: several ways to go about this: you can use the task force to migrate every single document to the wiki, churn on the documentation and go full blown wiki on everybody. it’s do-able. You can try and maintain both silos of information until you are ready to yourself commit to the wiki (I strongly advise you to have this well though out and planned. if you are feeling ground…well…don’t! wikis are about first impressions and you never have a second go at those.) Make a decision and stick with it…it’s either go or no go…there’s no middle ground.
And if you don’t? imagine if the 10 commandments were scattered around….hyea, that’s the deal. “what do you mean I can’t covet the other guy’s wife??? the version I checked doesn’t mention any of that!”
Ongoing task: keeping your user based interested. Because a wiki without continuity is simply casted away into oblivion.
To-Do: make another blog post about it.
And If I Don’t: I’m a wanker.
This is a very shy attempt to some common pitfalls in the bootstraping process of deployment of corporate wiki. Feel free to comment and add your experiences. I hope to eventually create a page for the subject alone, a silo of all things “corporate wiki”.











