Re: Consequences of inadequate docs/training

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

re:  I don't particularly appreciate the flippant responses some have given
this question. In my opinion, it's a serious writing/training/design issue.
This is one of those situations where you not doing your job properly--leave
your politics at the door when you take the job--can get people killed. (Tom
Murrell)

Nor I, but this may have been a failure shared by many and evidence that a
process requires review.

With my firm's products developed for the Military
(http://www.sandia.gov/Nuclear.htm), we participate in an extensive review
and approval of the user manual prior to turning over the product.  At the
final review, the Military itself is in charge of the proceedings, and
Military personnel read the manual and perform the steps and ask lots of
questions.  Changes are made until all agree on the final manual.  There is
much incentive to ask questions, and my experience is that the Sargeants and
officers show great concern for the safety as well as convenience of those
that would operate the equipment, and there is not a "see no evil" or "go
with the flow" or "get this over with" ambiance at all.  Even after the
final "handoff," an "unsatisfactory report" feedback system exists for
fielded products for further improving the manuals, and there is a
standardized replacement pages process.  Folks are even graded on whether
their manuals are current, I believe.

It's true that in many cases there is reliance on training of "general
mechanics," and, for example, every manual does not necessarily contain
procedures for using wrenches or other "common" things, but the case at hand
certainly appears to deal with a unique feature of a unique product, and
it's pretty hard to train for warnings that aren't in the manual (if that's
the case).  There appears plenty of blame to go around here, but I would
surely expect that Military systems and processes should have been in place
to uncover problems without total reliance on the manual writer and the
product designer.  And, it really is in the long run more about writing and
training than it is about design--no piloted military aircraft will fly
itself home should the pilot become disabled, for example.  That is, all or
most designs are not particularly fail-safe and have compromises for usually
known and accepted reasons, and the goal is to recognize and document the
hard stuff and train, train, train and practice, practice, practice and
document even more and continuously improve.

In my experience, the Military situation is never one where the users are
"tired of all the bureaucracy" and sometimes take shortcuts with potentially
dangerous procedures.  Rather, there is a very noticeable and delightful
spirit of doing the right thing, and it's really fun to be a manual writer
in all this, and the writer is quite motivated to do the right thing, too,
because the notion "no one reads the manual anyway" just doesn't exist and
because everyone is extra nice and always cooperative.  Really.  It's great
to be able to help people like this do their jobs and keep them as safe as
you can:  http://www.pilotonline.com/military/roosevelt/home1.html

Finally, with all the systems and checks and balances in place, it's still
pretty common for manual writers to understand the products they cover.  To
the extent they "need to know," I might add.  And, that's in the manuals
too--if the manual doesn't say you can take it apart or do this or that with
it, by rule you can't.


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PC Magazine gives RoboHelp Office 2002 five stars - a perfect score!
"The ultimate developer's tool for designing help systems. A product
no professional help designer should be without." Check out RoboHelp at
http://www.ehelp.com/techwr
---
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.