TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
> 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.
