Re: Internal wikis - do they ever live up to expectations?
Personally, I don't believe that a Wiki can ever be an alternative to a properly structured document management system.
The problem with Wikis is that they're almost impossible to impose any structure to. Whilst they become a good place to drop hints, tips and the various miscellanea of wisdom, using one to be the primary document repository leads to you never being able to find anything without using the search function. And using search is fine until you get to a certain critical point where reading through the myriad of hits for common terms, especially if more than one team are using the wiki, becomes a burden in it's own right.
I suppose it is possible to impose a structure by convention, but such systems are easy to get wrong.
I prefer a system where the storage method imposes structure on the documents, at least for the formal documentation. So, you define a documentation template that includes all of the sections you're ever likely to need. Requirements, Design decisions, implementation details. Implementation plans, Operational procedures, Support procedures, Disaster Recovery etc. etc.
The idea is to try to cover all the bases, so define more sections than you're ever likely to need, and just miss out sections that are not needed for certain projects.
If you store this in some hierarchical storage structure (I actually like just using a tree-structured file system) with change control at every level, finding particular documentats becomes easy. And writing the documentation becomes easier too, as you can populate a new branch for a project from a pre-defined template, and all of the boring dross of getting the look-and-feel correct is done for you. You can immediately tell if a particular section of the documentation has been written or not.
And with regular section numbering and naming conventions, you can 'slice' the tree horizontally to get the first cut of a set of operational procedures for many systems to generate a new document for, say, your operators quickly.
I first saw this done for a UNIX system in the late 1980's, using the directory structure to organise the files, shell scripts to populate and customise a new branch from a template, files containing the sections written in troff/memorendum macros/pic/tbl/eqn/grap in each directory, and SCCS as the change control in each directory.
IMHO, it worked so well that I've adopted something similar whenever I've needed to write something in an organisation without it's own documentation standards.
I know that there are a whole slew of tools that will allow you to do something similar (even with MS Word documents in all their binary obtuseness), but I think this fits in with the UNIX way of doing things. And for search, well, you've got find and grep, and everything is text! And you can always create a permuted index with ptx if you're using troff.