Re: Slow Tech Writers

[letoured -at- together -dot- net]

In <9A4B2157EFDBE546BECD68C62AC3B1C8A676A2 -at- es05snlnt>, on 07/08/02 
   at 09:35 AM, "Christensen, Kent" <lkchris -at- sandia -dot- gov> said:

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

How do you know it isn't the preferred practice? -- You're making an
assumption. Not all industries function the same way.  In this case, do not
assume there are subject matter experts doing the review -- there are
industries and projects where the writer is also the subject matter expert --
Electric utilities are one example. Mass-transit (rail vehicles and
operations) are another. We can probably include oil refineries and other
process plants. 

That may not be clear to some, but the fact is that there is only one way to
write certain documents -- and that is to be slow and methodical -- simply
because there are too many variables, systems are too complex, and too many
things that depend on information from others -- who are also developing
instructions for interconnected systems, not to mention engineers who are
still designing and modifying designs, and suppliers who will not complete
their documentation until the designs are done -- and all the time you might
be working on parts of manuals -- when you know its right, and leaving holes
where you cannot work with valid material.

I'll draw you another view; some of these projects, the larger ones might have
a dozen writers, take a couple of years or more, cost millions to produce, and
come in several volumes. -- I've seen projects with 12 volumes of 500 pages,
and that did not include vendor literature, or design drawings.  They can take
up a room by themselves. 

Now think of those drawings; there might be 20 or 30 for each system, and they
are the simple ones. Complex control systems can have a hundred or more --
What that means is this; (I'll use a simple system like waste disposal) You
might start maybe 20 blueprints and 40 vendor booklets on the components,
maybe 10 pages of instrument data, and 5 pages of engineering and design
descriptions for source material -- from that you have to startup, normal
operating instructions, and abnormal operating instructions (with
trouble-shooting instructions), and emergency operating instructions -- and
the whole thing has been designed for the wastes of that plant, and the
environmental requirements of the location.  Do you really think there is a
way to do that fast?  Multiply that by 40 more systems, and they all
inter-connect in some way. When something happens here, something also happens
over there -- and someone else is writing that part -- and what his
instructions include relate back to yours and vice versa. 

You mentioned schedules. They are a guide. Not the objective. They slip and
slide and change as needed -- because these instructions have to match what is
actually being build and you are writing the material as its being engineered
and built... They are to be corrected and finalized after as-built drawings
and data sheets are available.

You go slow and methodically (that is you check and recheck) because you don't
want to be correcting anything but the minor things like, MCC numbers at the
end, and even then you try to get it 100% correct or leave a blank to
completed in the field.  The reason is simple; the instructions are used both
for operations, and parts are also used for the initial checkout, startup and
testing, as well as training before the construction is done.  The point is
obvious, you go slow because you can't possibly waste as much time and money
as damage to say a 100 thousand dollar pump, or 150 million dollar turbine
because somebody didn't go slow and check and recheck everything. 

In short, you don't trust multi-level on-paper reviews. You plan for, you
write for the electric-acid-on-line-under-fire test, on-site with people in
danger as they are doing it. You also have other considerations, such as a
mistake here -- can cause a problem all the way over there, on something you
were not even working on.  But they all need to be checked, and carefully
coordinated before someone gets to do it for real -- and that can't be done
without going slow and being careful. 

Now I don't know if you understand what I'm saying or not, and I can also see
that you are thinking in terms of bureaucracy and people being conditioned to
taking their time  -- but don't -- Because there really are first-tier
projects where safety and reliability are the prime objectives and getting it
right takes everyone towards that from day one.

Going further, documentation for projects like these become engineering
documents. Sometimes they are signed-off by a PE, sometimes not. Usually the
documents are used for the lifetime of a facility. That might be 25-35-40
years. Sometimes 70 or more in some cases. It is not documentation for the
sake of it. These things are actually used, and you don't find errors in
reviews around the table. They are found in the field. What you find in the
writing and the reviews are engineering and design errors. Its an unspoken
reason for writing them slowly (carefully) in the first place.

Am I slow compared to the guy who writes 100 pages of something in 3 weeks. I
most certainly am. Could that fellow do what I do in the same time period? 
Not without pages of errors that take longer to find and fix, then it would
take to do it right in the first place. 


-----------------------------------------------------------
letoured -at- together -dot- net
-----------------------------------------------------------



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