Re: Slow Tech Writers

["Christensen, Kent" <lkchris -at- sandia -dot- gov>]

re:  Call it what you want, but some of us think in different terms; like
first-tier projects that need first-tier writers, second-tier projects, etc.
Usually the first group comes from experience in writing that has to be
correct. Why there are even industries that expect it to be done right
because people can be killed, and/or thousands of dollars lost if the writer
makes an error and no one catches it before they turn the juice on during a
test -- you know, the little things that count world or writing. (letoured)


This could be and shouldn't be misread to indicate that slow, methodical
technical writing is the preferred solution when "it has to be done right
because people can be killed," etc.

Whether the writer works slowly or quickly in these instances, what is
needed is a *process* whereby the rough or review draft is indeed
methodically checked for correctness by the subject matter experts, usually
engineers, scientists, etc.  In our line of work it certainly "has to be
done right" and we have two milestone meetings:  the first meeting is among
company representatives wherein the procedures are performed as written to
shake out any problems.  Once the rough draft is updated based on findings
at this first meeting, a second meeting is held wherein the procedures are
performed/tested as written by representatives of customers that will
ultimately use the product.  The final manual is only issued (and only then
can the product be fielded) when all parties, including the customer, agree
it is as correct as it can be.

This process is expensive, as often travel costs are involved getting the
correct individuals to the meetings, and it is indeed often good to have a
"fast" technical writer that can update the rough draft quickly between
meeting sessions (or even meeting repeats).  In one instance where I was
technical writer for one of these "dangerous" products, the manual under
review was for an urgently needed retrofit of the original equipment
configuration, and, when the final manual was approved, I desktop published
it and the customer representative flew to Europe to perform the retrofit
the next day.

When I read the phrase "slow tech writers," I'm inclined to think
"government employees" and the like, although that term is used strictly for
image setting and not so much for stereotyping a particular group.  It's
when bureaucracy runs amok.  Back in the 1980s when I started at this here,
we were all very organized into specialized departments, and desktop
publishing was mostly a new concept.  We writers, then, produced our rough
drafts (some with pencil and paper) and submitted them to a word processing
department for formatting and publishing of the review and final drafts, and
that group's standard timetable, no matter the length of the document was
... six weeks.  This was the era of the beginning of the PC revolution, and
I would, I think favorably, stereotype our customers, the subject matter
experts (engineers), as early adopters, and the "six weeks" thing became
quickly despised by them.  It certainly paid to be a "quick" technical
writer who could desktop publish drafts in near real time, although company
political problems were difficult as others felt threatened, etc.

To summarize, I, too, think it a bit useless to discuss "slow" vs. "fast"
technical writers.  I feel engineers and other subject matter experts will
typically expect fast turnaround from technical writers.  But, whatever the
case, the best approach is to have a schedule or project plan that clearly
describes the milestone times allocated to technical writers and for review
of their work and that is agreed to up front, i.e., at project inception.
Being able to quickly respond to crises that can surely occur despite the
best planning will only help the technical writer, and the writer's taking a
defensive approach when crises occur will usually only cause problems.
During crises is a poor time to review the organization's basic project
planning, or indeed, to suggest there be some.  

So, to the other poster(English major and editor/writer)looking for "Online
or Distance Learning Tech Writing Courses," be sure to know project
planning, too.  Probably Microsoft Project.



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Save $600: Create great-looking Help files and software demos with
RoboHelp Deluxe. Get RoboHelp and RoboDemo - our new demo software - for one
low price. OR Save $100 on RoboHelp Office in June with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l

  Your monthly sponsorship message here reaches more than
  5000 technical writers, providing 2,500,000+ monthly impressions.
  Contact Eric (ejray -at- raycomm -dot- com) for details and availability.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit http://www.raycomm.com/techwhirl/ for more resources and info.