bookmark_borderTo Wiki or not to Wiki

The other day one of our genius developers (I think his official ranking is Jedi Knight) asked me why we don’t provide the product documentation on a Wiki. I answered him stating that it was because I wasn’t allowed. That’s not strictly true.

My answer should have been that, quite simply, I’ve failed to provide a good enough reason to my boss (and my bosses boss) as to why that may be a good thing.

And the reason I’ve failed to do that?

Because I’m still not 100% convinced that it is a good solution for our product.

What is more likely is that, if we do decide to embrace Wikis (we haven’t managed blogs yet, but that’s another issue) we take a split approach and offer a knowledge base style information centre (something like the Author-it Knowledge Center) and host a Wiki as a way of capturing and sharing what I refer to as ‘grey information’.

It’s this latter set of information which, whilst it has always existed, has never really had a place to live until the internet came along. These days all it takes is a quick internet search and you’ll find masses of information, all generated by the users. Some of it is useful, hints and tips, ways to workaround product limitations, and clever uses that were never thought of by the manufacturer.

To me, that user created content is where Wikis hold their true power and finding the balance between that content, and the content provided by my team is still something I’ve to get my head around. Ultimately the argument (business case) for investing in the creation, maintenance and policing of a Wiki needs to be focussed on how much value we will gain (ROI).

On that basis it shouldn’t be a hard business case to put together, the tricky bit is making it such a compelling argument that it moves to (close to) the top of the list, and that will require a lot more discussion around why embracing Wikis, and blogs, will stand us in better stead in the future.