Sorry for the late answer but I just discovered this forum and joined it.
There are many ways to look at documentation so I have to make some question (and assumption) to limit the field of this discussion.
The first question is: are we talking of end-user's documentation (HTML files, printed manuals, etc.) or developer's documentation (JavaDoc and the similar)? In my answer I will assume we are talking of end user's doc because dev's doc is usually covered by many kinds of Programming Best Practices.
The second question is: are we talking of documentation as a set of (deliverable) documents or as the developement process that produces such documents? In my answer I will assume we are talking of deliverable documents because the dev. process is already covered by the same Best Practice used for software dev.
Given these assumptions, there are at least the following metrics to take into account.
Coverage. Does your documentation cover all of the features/aspects/capabilities of the documented project? This can easily be tracked using a simple database (or even a spreadsheet) listing all the implmented features and the related documents.
Understability/readability. Are the text and images of your docu understable for an average reader? This is sometime measured with a simple read/question&answer test: have a couple of users read your documents and answer a few questions. The "quiz" should contain questions regarding the documentation itself ("What does the docu says about this feature of our product?"), regarding the product features (What does our product do?) and regarding the working of the product (how do you perform this task?).
Conciseness/effectiveness. Does the docu use a reasonably small amount of word and images to communicate its concepts? There are a lot of good text metrics out there but you can reasonably assume that any feature should not require more than two (7 inches diagonal) pages to be illustrated. Each feature-related chapter should contain at least one image or one bullet list to draw attention. Each chapter should be divided in paragraphs and each paragraph should not be longer that 6 - 12 lines. Each phrase should not be longer than 12 -24 words. Long, weird/unusual and hard-to-spell words should be avoided when possible (and clearly defined in a glossary when not possible). Each image should not try to represent more that 5 or 6 objects/concepts/"things".
These concepts are typical of the software development industry but can be easily applicated to many other fields (mainly mechanical, automotive, aerospace, electronics and so on).
Of course, documentation is an interactive process (we document our product and you, user, read our documents and tell us if you understand them). The only way to have a really good documentation is to keep the communication channel open. Have a forum on the web, answer the user's question and collect the best Q&As in a well orgainized, well written FAQ. Publish a collection of articles on the most interesting topics and bugs (a public "knowledge base").