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.
>The biggest problem with productivity measurements is that it's measuring output
>from a process that is usually not well defined or contained. It's one thing to
>measure pages per day or character strokes per minute, but that assumes that the
>source material is (a) available, (b) accurate, and (c) not going to change.
>Most of us in the software industry have armloads of war stories about trying to
>write about a product that has sketchy or no specs, development schedules that
>are routinely ignored, review processes that turn into endless loops of
>correction/rewrite, and prima donna developers who think they can write. Since
>half of most productivity measures is the time variable, the ability to work to
>some sort of reasonable schedule is an assumption - but one that in my
>experience is subject to far too many unpredictable outside forces. To be held
>accountable to a schedule that is subject to the whims of others is
>unreasonable. To thus consider it as a factor in productivity metrics is simply
>ridiculous.
I suspect that the problem is not with metrics, so much as how
they are used. If they are used as a rough guide for planning
purposes, they have their uses. As Rebecca said, if you're a
contractor, metrics are unavoidable; for some reason, companies
have an aversion to hiring you for open-ended projects. There's
only a problem if they're used narrowly, and everyone is held to
a narow range of circumstances.
Instead of providing a single metric, I like to provide several,
to show how the job could change according to the degree of
co-operation I get and what the company wants. Then, if I'm in
the kind of situation that Elna describes (and, like many
writers, I often am), I can point to my initial estimates and
explain that there's an overrun because things didn't happen that
were supposed to.
In short, the problem isn't with the tool so much as with
inflexible minds - and they're even more common than time
overruns on projects.
--
Bruce Byfield, Outlaw Communications
Contributing Editor, Maximum Linux
bbyfield -at- axionet -dot- com | Tel: 604.421.7189
"At the sick bed of Cuhullain,
We'll kneel and say a prayer,
When the ghosts are rattling at the door
And the devil's in the chair."
- The Pogues
