Re: Estimating Quality Documentation?

Subject: Re: Estimating Quality Documentation?
From: "Elna Tymes" <etymes -at- lts -dot- com>
To: TECHWR-L <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Sun, 12 Sep 1999 13:13:25 -0700

Bettina and Scott Wahl wrote:

> Reliance on page counts is one of the major problems I have with metrics
> proposed by Joanne Hackos and others. I am no project management specialist,
> but I know from experience that there is only a marginal correlation between
> page count and writing time. Many designers I know have the same complaints
> about estimating software design projects based on number of lines of code.

I suspect the true purpose of the metrics used by JoAnn Hackos, et al, is to give
bottom-line project managers a feel for what they're getting into. Almost every
experienced project manager knows that there are likely to be slips and gotchas and
things that mess up the best-planned schedule, but in order to get some signoff at
the beginning, you need to put some numbers down to make people feel comfortable.
It's a little like planning a trip: you know where you're going, and you know the
route to get there, but there may be delays due to construction or car problems or
other unforeseen incidents. You plan ahead as best you can and be flexible enough
to deal with the unexpected. And page counts are about the reasonably useful
measure of a writer's productivity, going in.

However, once into the project, there are other productivity gauges that come into
play, things that you really can't quantify. These are things like willingness to
rewrite when (a) the language isn't right for the audience, (b) the product design
changes (ohhhh, that *never* happens, right?), or (c) testing discovers that the
product doesn't do what it's supposed to, and some workaround has to be explained
(naaaah, never in a million years <cough, choke>). And things like willingness to
pitch in to create the glossary you didn't think you'd need, or the release notes
you forgot to plan for, or the programmers' notes that the project team decides at
the 11th hour need to be included. And things like fighting with templates that
don't do what you thought they'd do, or file storage/translation/transmission
problems, etc. You can't plan for those, but a truly productive, team-oriented
writer will pitch in and help make the deadline the team signed up for. Within
limits, of course.

Elna Tymes
Los Trancos Systems

Previous by Author: Re: HTML vs PDF for online manuals
Next by Author: Wish list for academic research
Previous by Thread: Re: Estimating Quality Documentation?
Next by Thread: Estimating Quality Documentation?

What this post helpful? Share it with friends and colleagues:

Sponsored Ads