TWATS Wiki (or implementing a wiki at work)

My dev manager at Tourism (Steve) recently suggested we implement a wiki with the intention of improving our project and software documentation and making easily accessible. He'd been involved with the launch of a wiki at a previous job and found it beneficial. 

We previously built a wiki on our MOSS-based intranet using one of the MOSS templates but it was ugly, weird, boring, and wasn't adopted by the team. This time we've gone with MediaWiki and setting it up has taken the form of a mini project with our junior dev Tim assigned the task of learning/doing the configuring. We work for Tourism Western Australia so naturally we've named the wiki TWATS (Tourism WA Technical Support). 

The three of us also sat down to plan the wiki's structure: we settled on top level categories for project documentation, third-party application/platform documentation and training, templates, and code snippets/work-arounds/etc. Our customer service (help desk) training materials will also fit in there somewhere. Tim hasn't quite launched the wiki but I'm already thinking to myself "hey, I could wiki this if the wiki were up" every time I unearth some rare bit of info (I've been doing some legacy project work recently...). 

At this point I think the wiki is a brilliant idea and building it on a trusted platform (MediaWiki) means it should be easy for the team to use--both in terms of accessing content and updating wikis. We've traditionally stored our documentation as Word docs on the intranet; a document gets "finished" and quickly forgotten about because people are too scared to touch it--it's too formal and it's "finished". In theory this should be less of a problem with a brief wiki page. With the wiki being broadly accessible (eg. http://twats or http://wiki) and editable by nature, I'm hoping it will also get read and that should lead to the content being maintained as required.