I work in a company where the same product has been around since before I started 4 years ago.  We just keep refining and adding functionality to our product.  These years of work have resulted in a much better product than we had originally, but we've been butting our heads against a problem with seemingly no good solution:

   How do you manage the documentation for a product where dozens of different people are adding features to the same product?

• We've tried keeping one central document but Microsoft Word isn't very good about sharing the file and letting 20 people edit it at the same time.  VSS tends to want to check out to one person at a time and merging the doc changes in don't seem to work because VSS treats the file as a binary object.
• We've tried having people write design documents that show the new features but the problem here is that we end up with one out of date functional document and 300 out of date design documents.  People write the design document as they think things WILL be and then write the code as things HAVE to be.  The two are not always the same.  But deadlines being what they are, the design document doesn't get updated and becomes useless.  Also, when Person A writes a design and code for something then Person B makes a change for a different feature in that same code, Person A's document is now out of date because the changes are detailed in Person B's document.
• We've tried to force people to accept the "living document" model - where if a document dealing with your area of functionality exits you should be changing that document.  Only create new documents as a last resort.  The problem here is that we don't currently have a good framework of documentation covering all the areas of the code.  We have a single document that covers everything and hundreds of sub-documents dealing with new features, not specific areas of code functionality.  For example, if I want to add the ability to sell an non-inventory decrementing item I'll write a document about how to do that.  Then the next person comes along and wants to write about refunds for tax-free items.  My document didn't deal with Sales and Refunds so the next person will write a document about their specific feature.  These "delta" documents talk about how the new release has changed from the original Functional Specification (the 1 big umbrella document) but they're generally useless
• How do you relay this information to the customer?  You need something a customer can refer to for configuration and troubleshooting.  We need something internally for the same reasons.

We're a small company and we don't have the budget to implement a massively expensive product to help us manage this problem.  So I came up with an idea that I pitched to the management team (to lukewarm reception).  I proposed we implement a wiki internally.  A wiki is basically a website that allows anyone who views it to easily change it ("wiki" means quick or fast in Hawaiian).  The best example is the world's largest wiki - the Wikipedia, with over a million articles.  The beauty of a wiki for document management is that anyone who wants to can easily create marked up, cross linked documents with very little effort.  If I put my functional spec document into the wiki as a page, whenever I find a word I want to expand on (like Item Sales or Item Refunds) I can simply add a link and have a new page for my new information created automatically.  Since the effort to create entirely new documents suddenly becomes less than the effort to simply expand on an existing one, the document management process will slowly solve itself.

I picked FlexWiki for several reasons.  1) - it's free.  2) - it's based in .Net.  and 3) - it's markup syntax is really easy to use.  I slapped together a random sample of what it would look like and presented it to two of the managers.  They both liked the flexibility but both are worried about the lack of structure.  The other problem is that a wiki isn't very presentable to clients.  I picked FlexWiki because it supports user authentication for making modifications, but that still doesn't help us print up a fancy deliverable.  The other problem is that the lack of structure is great for adding content as you see fit but not necessarily condusive to easily understandable document structure.

A coworker was looking at this same problem and came up with an alternate solution.  He felt that some forums would be the way to go.  He chose the free Snitz forums. Structure is very rigid and easily understandable.  Just like a wiki, anyone (with access) can add to a forum topic.  The problem I have with the forums is that it does even less than a wiki does as far as creating documentation of a product.  Forums are great for trouble shooting (which is where my coworker started his forums - documenting our troubleshooting guide) but suck as far as readable documentation goes.

I personally prefer the wiki.  Look at the Wikipedia - a little effort can turn something small into a tremendous resource.  Forums have their place too, but especially where documentation is concerned, I don't think they fit the bill.

I know that I am not the only person working for a company that has struggled with this same issue.  Anyone have any advice or thoughts?

-- Matt Ranlett