Re: $/Word coming to TWing?

[Robert Plamondon <robert -at- PLAMONDON -dot- COM>]

Paying by the word makes sense for magazines, which are buying articles
to fill pages with -- it makes the editor's life easier to buy copy
at a uniform price per square inch.  Furthermore, the editors pay
by the PUBLISHED word, so they have two immediate incentives to trim
back puffery: making the article fit the space available, and cutting
cost.

In tech writing, however, manuals do not generally have to fit in
a sharply limited number of square inches of paper.  Nor do technical
editors have the same motivation to trim things that magazine editors
do.

Thus, if you paid by the word, writers would probably get away with
bloating up their manuals.  A little redundancy here, keeping a little
semi-irrelevant material there, and a moderately interesting program
listings thrown in for good measure, and you get Really Good Statistics.

This all happened in the programming world in the Bad Old Days -- programmers
had their "productivity" measured by lines of code per day.   All you
had to do was avoid the use of subroutines (using in-line code instead),
and generally write code at an inappropriately low level, and your scored
would be high, and management would be happy.  Write something elegant
and fast, and you were dead meat.  Not too many people were such saints
that their code was unaffected by these policies.

In a normal $/word arrangement, only the word count of the final document
matters.  If you also counted thrashing (words changed during development),
you actually get penalized by getting things letter-perfect on the first
draft.  Rewriting would pay off big-time; the sloppier the first draft,
the better the pay.

The problem with documentation productivity is that the value of the document
is largely independent of its cost.  Plenty of unusable manuals were
written at vast expense, and some excellent ones cost almost nothing,
because circumstances (for once) allowed complete, accurate information to
drop into the lap of someone who knew exactly what to do with it.

Since technical writing tends to involve the documentation of a product
that doesn't exist, based on outdated information provided by people
who haven't quite figured out how to make the product, the opportunities
for wasting money are endless.  I think that the right thing for management
to do is not to nail down documentation development costs (which can
easily cost ten times more for a document prepared before the product
exists, and consantly revised during development, than one prepared
afterwards), but to focus on documentation VALUE.

If the following three questions were answered:

1. How much would having no documentation at all affect sales and support?

2. How much would crappy documentation affect sales and support?

3. How much would superb documentation affect sales and support?

Then one can put a value on documentation.  This is business, after all:
everything has finite value, and you shouldn't laving more money on
any one task than it's worth.

Only after management puts a value on documentation is it sensible
to plan the documentation itself.  You don't want to write the same
kinds of manuals if the documentation is valued at $5,000 that you
would if it were valued at a million dollars.

        -- Robert

--
Robert Plamondon, President/Managing Editor, High-Tech Technical Writing, Inc.
36475 Norton Creek Road * Blodgett * Oregon * 97326
robert -at- plamondon -dot- com * (541) 453-5841 * Fax: (541) 453-4139