RE. Productivity metrics?

Subject: RE. Productivity metrics?
From: "Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>
To: "Techwr-L (E-mail)" <TECHWR-L -at- lists -dot- raycomm -dot- com>
Date: Fri, 7 Jul 2000 15:28:47 -0400

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".

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca

"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




Previous by Author: "Me too!" reviews (was SMEs and me)
Next by Author: Productivity metrics, take II
Previous by Thread: RE: Document Convention
Next by Thread: Re: RE. Productivity metrics?


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

Sponsored Ads


Sponsored Ads