Substantive Issues

[Bonni Graham <Bonni_Graham_at_Enfin-SD -at- RELAY -dot- PROTEON -dot- COM>]

 Saul Carliner notes:
 "I'd like to make a painful observation, however.  I find that, on this list,
 it is easier to get a discussion going about an "easy" subject--such as
 the tool of choice (a subject we repeat at least once a month) or the
 term to use for mainframe operating systems--than on more substantive
 subjects, such as uses of multimedia, quality initiatives, and the value
 of technical communication."

 I agree to an extent (I've seen some other useful issues come up, such as
 how to best address naive/technophobic users, some of the postings on
 multimedia, etc.).  However, we must remember that this has been (so far,
 and in my experience), a question-based forum.  If no one's asking the
 substantive questions, no one is going to respond  Maybe we should
 occasionally include a ruminative posting?  I don't know.

 I'll try to start a thread, though.  How do others "prove their worth" to
 their employers?

 At my first company, I had to do it by keeping statistics on support
 calls.  No one did it for me.  I got into the database and looked at the
 kinds of questions being asked before my manual was release and after.  I
 was able to prove in a salary review that I had reduced the number of
 "How do I?" calls (calls in which the customer simply needed directions
 on a procedure) by over 25%.

 At my second company, the truly horrific awfulness of the earlier manuals
 did it for me.  They'd been written in "Germlish" by engineer (speaking
 English as a third language -- German, Smalltalk, then English <g>).  No
 one could use them, and sales were demonstrably down because of it.  For
 the new product I'm working on, I was able to not only prove the worth of
 a tech writer, I was able to justify their sending me to Dallas -- I
 brought back some doc testing procedures that helped us create a more
 usable product (we're not selling any yet, but I'm pretty sure that
 that's a marketing problem -- everyone who's used the program has
 commented on how easy it is to use with the manual).

 At my contracting job, the naivete of the users did it for me, although
 I'm also showing that producing new technical sales material (data
 sheets, technical overviews, etc.) helps invigorate the sales staff and
 increases sales.  I'm also proving that word of mouth about the manual is
 helping sales.  Of course, one of the VPs is a good friend of mine, and
 he already believes in good technical manuals, so I've had it easy.

 What has anyone else done?  (I may not always be this lucky!)  How are
 people defining quality documentation?  How are people proving that it
 adds to the value of the product?  I know STC is studying this formally,
 but what do we know informally?

Bonni Graham                               |
Technical Writer                           |
Easel Corporation, ENFIN Technology Lab    | Never tell people how to
Bonni_Graham_at_Enfin-SD -at- relay -dot- proteon -dot- com | do things.  Tell them
President, San Diego STC                   | what to do and they will
                                           | surprise you with their
NOTE: apparently my email address needs    | ingenuity.
to be typed exactly as it appears here,    |
punctuation and all, or the system gets    |          --George Patton
upset.                                     |