Most people have a love/hate relationship with documentation.  They love having good documentation, but hate having to create it themselves.  It's the part of the project that often suffers when time and resources are cut short, but can also drag a project into paralysis if overdone.

Documentation is a form of communication.  It’s the same transmission of thoughts, facts, opinions, and ideas, but in written form that is usually expected to last and be redistributed.  The key to good documentation is striking the right balance to make something truly useful.  More is not always better – a 345-page design document is no more valuable than a blank sheet of paper if no one bothers to read it because it’s so long!

When writing documentation as part of a project, be sure to consider:

• Purpose – Are you writing a document that someone will take action on, a reference document for future use, or an “insurance” document that will hopefully never be needed?  Are you consolidating information that is readily available elsewhere, or are you documenting knowledge that is only stored in “biological databases”?  Are you simply presenting the information itself, or are you driving toward a point or purpose?  Ask yourself “why am I writing this document?”  If you can't answer that question, maybe you shouldn't be writing it at all.
   
• Audience – Who is going to read this documentation, and what will they do with it?  Are they technical people, business leaders, or end users?  Are they within your organization or are they customers, vendors, or partners?  Do they know anything about the system or environment being described, or is this their sole reference and knowledge base?
   
• Structure - A configuration document should read differently than a project scope or charter.  Considering your purpose and your audience, you need to structure your document so that the information can be easily digested, scanned, searched, and potentially integrated into other documentation.
   
• Format – How many times have I seen a project document with no thought given to page breaks or headers, when the most likely use of that document is to be in printed form?  Or a wiki page used for large tabular data sets, with limited ability to sort or filter the information? Like structure, the format is a critical factor in making your document digestible, which directly affects its usefulness.
   
• Indexing – If your document is more than a few pages long, it needs to have a table of contents, and possibly an index.  Especially if your documentation will be printed, the search capabilities are limited and an index will make it infinitely more useful as a reference tool.
   

In the end, it's about quality, not quantity. There is no one-size-fits-all documentation model or set of templates that is right for every project and every organization (not that models or templates are bad - they are just not universal). If you care about developing your communication skills (and you should), you should also care about producing quality documentation.