Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
I would like to get information about measurements and metrics for documentation work in a project.
The project can be itself limited to documentation as a deliverable or documentation as part of entire product delivery.
How can I measure performance around a paper deliverable?
When anyone asks this question in this way, it implies the desire to measure for the sake of measuring, an end versus a means to an end.
You metrics pop out as a result of decomposing your project goals. Any other measurement that has no parent goal will be looked at by bored stakeholders, who will eventually learn to ignore that report. Goals are decomposed into objectives that are deliverd by plans. The question becomes, how do you know when you get there, how do you know your plan was achieved? The metrics you need answer that question.
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").
(Concur with everything that @David Espina said). Are you writing the quality management plan for your project? If the project is effectively to produce a document, then the "metrics" are really your quality goals.
There is a management philosophy that says that if you can't measure it, perhaps you shouldn't be doing it. I'm not sure I subscribe to that, but the corollary1 makes some sense: if there is a purpose in doing it, you can probably measure it.
In this case, and I am speculating here, you could do something simple like compare word count with documents from similar projects. More ambitiously, how about submitting a 360 degree feedback survey to your document's audience. Many ISPs and shrink-wrap software vendors ask "How helpful was this?" on every online help page.
Alex Bottoni's answer mentions conciseness and readability. These too can be measured. I won't repeat Alex's measures but I will add this. If your document is in English and will be published, or your employer or client is a member of the Plain English Campaign(PEC), you might choose to apply for the PEC Crystal Mark.
There are also the FOG score and Flesch test.
http://www.plainenglish.co.uk/crystal-mark.html
http://www.plainenglish.co.uk/faqs.html#Anchor-8232
If the docs are online, you could even measure how often they are read.
Don't forget that word count and reading frequency should inversely correlate to how intuitive or self-documenting your software is (and that applies both to end user software and to APIs.) So, though a need for hefty documentation might reflect the complexity of your problem domain, it is also a warning sign.
1: more properly I should have said contrapositive
K at Eight to Late offered a fairly comprehensive answer to the quality question in the blog post What is good?.
I'm not sure that I agree with K - I'm more inclined to believe that Quality is conformance to the requirements under discussion, but the entire post struck me as applicable to your question.
