Re: $ per word - quantifying TW New Slant

Subject: Re: $ per word - quantifying TW New Slant
From: "Dimock, Dick" <red -at- ELSEGUNDOCA -dot- ATTGIS -dot- COM>
Date: Thu, 18 Jan 1996 15:22:00 PST

from Steve Jong
via Dick Dimock

From: Steve_Jong/Lightbridge*LIGHTBRIDGE
To: red
Subject: Re: $ per word - quantifying TW
Date: Thursday, January 18, 1996 3:12PM


[I'm frustrated by my inability to post to TECHWR-L (we changed something
the summer and I was cut off mid-sentence). I still read the digest, and
discussion of metrics touches questions near and dear to my heart. I would
like to offer you some thoughts personally; I ask, please, that you post
message (less its attachment) to the list.]

I agree that the question of metrics is both elusive and vitally important.

The obvious metrics, like pages per hour or cents per word or readability,
obvious flaws, and in some cases are counterintuitive.

You wrote that you have tried a variety of metrics as a writing manager and
an individual contributor, and that none of them was satisfactory. There is

solution to the problem, but it requires a different conceptual framework to


A user information product (a printed document, a help file, a training
etc.) is a manufactured product. As such its quality, or its worth, has two

components: its value and utility as seen by the person who uses or
it, and its value and cost to the agent that produced it. The two
are separable, though not entirely unrelated. Thus, to take a concrete
example, a document that is timely, accurate, clear, concise, attractive,
friendly, and so forth and so on, can be said to be of high quality; but
same document can be of high quality OR low quality to the agent that
it, depending on a different set of conditions. Did it satisfy the
Was it economical to create? Is it easy to maintain? Expressed another

given document could fall anywhere in a two-dimensional space along the axes
"easy to use" and "easy to make" (assuming for the moment that it's possible
measure both these attributes):

Hard to | X X
Make |
Easy to | X X
Make |_________________________________

Hard to Use Easy to Use

Viewed as a two-dimensional problem, it becomes easy to see that both
dimensions -- user information as a product, and user information as the end

result of a process -- are important.
Ideally, we would like to produce a document that is both easy to make and
to use; I think in practice one can argue the two factors correlate, such
it's hard to make an easy-to-use document -- in short, there are tradeoffs.

It's also apparent that as technical communicators we tend to be interested
maximizing the product, while managers naturally tend to be interested in
minimizing the cost. Should we print this book in full color? The question
not one simply of customer satisfaction; of course they'd like color. But
neither is it entirely one simply of cost; of course it's more expensive.
elements must be considered to reach a sound decision.

Now, given the two dimensions, it becomes apparent why productivity metrics
such as pages per day (or dollars per word) are attractive, and in fact
*relevant*, to managers. It also becomes clear why writers don't care for
metrics, but are more interested with other factors, such as clarity and use
illustration -- and why managers don't care for those.

Which to use? Obviously, you need a mixture. You need to measure and track

the costs of producing product, as with any other manufacturing business, to

maximize results and minimize expenses. At the same time, you need to
those elements of the finished product that result in customer satisfaction
efficacy. (Do they like art? Give 'em more art!) So I argue for a suite
metrics; none individually amounts to much, but collectively they are

I don't wish to leave you with an empty theoretical lecture, so I will add
in my research I have discovered that some metrics are more useful than
others. For example, an IBM study found that measuring productivity in
of weighted pages per day was meaningful. A weighted page was a page
that is) times the effort to create it, with a page of new documentation
weighted as 1.0, a revision as 0.5, and an update, I think, as 0.25. (Being

more precise than that is not worth the effort.) The cost of documentation
primarily the cost of labor, so the time to finish is meaningful;
time overruns should be tracked and analyzed. Did the project slip because
slow writing? Or was it slow review? Or late specs? 3M discovered that
three greatest contributors to slippage were no specs, late specs, and
specs. No surprise there, but having data in your hand is the only way to
effect change.

To create metrics for the finished product, ask your customers what they
and don't like, about your products in particular and about all such
in general. Collect statistically significant samples, not just the three
closest customers. Generate weighted lists of critical success factors
based on their responses; use them to learn what to measure. I'm willing to

bet that you'll come up with a very plausible list of important factors.
last time I did it, we ended up with these:

More examples
More illustrations
More headings
Better index

Once you collect CSFs, you know what will satisfy your customers; can you
up ways to measure your products to see how well they meet these needs?

(Don't take these as your solution. These were *our* solution, *at that
time.* You will get your own answer, based on your own customers at the
you ask. But that's good!)

-- Steve

Steven Jong, Documentation Specialist ("Typo? What tpyo?")
Lightbridge, Inc, 281 Winter St., Waltham, MA 02154 USA
<jong -at- lightbridge -dot- com>, 617.672.4902 [voice], 617.890.2681 [FAX]
Great Stuff, Steve! Yeah!

Foist uv all, TECHWR-L has a new address for subscribed posters:


The VM stuff dropped out. Eric cut over to that address Saturday.
Try that address. Look for the most recent EJRAY or ERIC post
for subscription directions.

I particularly like your CSFs. Excellent food for thought!

But I gotta write - deadline tomorrow, vacation after that.
I would like to chat more about this, and I wish I were not
missing the list discussion while I vacate!


Dick Dimock
richard -dot- dimock -at- elsegundoca -dot- attgis -dot- com
red -at- elsegundoca -dot- attgis -dot- com

Previous by Author: $ per word - quantifying TW
Next by Author: Challenge to active-verb advocates
Previous by Thread: Re: Wildcard searches & Frame doc error
Next by Thread: Re: Frame + Acrobat + Screen grabs

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

Sponsored Ads

Sponsored Ads