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.
Curtis Ward reports that his department (Tech Pubs/Training) <<... has been
charged with developing a set of productivity metrics to be used for both
individual and department evaluation and planning. I'm pretty underwhelmed
with most of the material I have found researching this issue.>>
First, ask yourself just what it is they want you to measure, and why.
"Productivity" is a meaningless term without that context. Do they consider
productivity to be meeting deadlines, satisfying customers, some combination
of the two, or something else entirely? The only really _good_ reason for
requesting a productivity metric is so that you can budget enough resources
to ensure you'll complete a product's documentation on schedule, with
adequate quality.
The problem with typical metrics is that techwhirlers are smarter than the
average bear, and as soon as you define a metric, lo and behold, you'll
start recording good values for that metric. So unless you've got an
unlimited printing budget, don't even think of setting a "pages per day"
metric; most of us can type fast enough to produce any arbitrary number of
pages you desire in a work day, particularly with the help of some simple
macros and a lot of cut and paste. Similarly, unless quality is meaningless
to you, don't aim for a "topics per day" metric, since then you'll get lots
of topics documented to a very minimal level. It's trivial to write "the
Print dialog box lets you print your document" and leave it at that. Sure,
you've completed a topic, but is that any good to the user? (OK, silly
example. But you get the point. Shallow and unhelpful writing is all that's
required to really churn out the topics.)
For a metric to be useful, it needs to account for the following features:
- a measure of the _number_ of concepts to be covered in a topic; the
documentation on how to exit from Word obviously contains far fewer concepts
than the section of the PageMaker manual that discusses typography.
- a measure of the _difficulty_ of the concepts; explaining typography is
much easier than explaining quantum chromodynamics, even if you choose to
cover the same number of points for each subject.
- a measure of the _scope_ of each concept; quitting a program is trivial
because of the narrow scope, but conceptualizing a page layout is anything
but trivial.
- a measure of the _difficulty in obtaining information_ on each concept; if
the SME is a saint and gives you his home phone number plus a detailed
product specification that he's scrupulously adhered to, you'll be much more
productive, even for a difficult topic, than if you've got the typical
"don't bother me" SME who programs by the seat of his pants without a spec,
who also happens to be working on another continent, and who won't return
your calls or e-mail.
- a measure of the _required quality_ for each concept; obviously,
documenting how to shut down Word requires far less quality than performing
CPR, and the extra quality is going to take some time to produce.
Come up with some magic number that sums up all these measurements and
you'll have a fair productivity metric. The reason you haven't seen one in
the literature yet is because each of these parameters is highly subjective
and very difficult to quantify in any meaningful way. There's an old joke
about an engineering consultant who comes to a factory to troubleshoot a
problem, and solves it in about 10 seconds by tightening a single screw.
When the company receives the bill for $5000, they hit the roof. "We need an
itemized account of your work to justify this. After all, you only worked
for 10 seconds." The engineer grabs a notepad, and scribbles the details of
his fee: "Tightening the screw: $0.10; knowing which screw to tighten:
$4999.90".
"Technical writing... requires understanding the audience, understanding
what activities the user wants to accomplish, and translating the often
idiosyncratic and unplanned design into something that appears to make
sense."--Donald Norman, The Invisible Computer
