On Saturday, September 13, 2003, at 04:14 AM, Randall Clague wrote:
On Fri, 12 Sep 2003 18:44:08 -0400 (EDT), Henry Spencer <[EMAIL PROTECTED]> wrote:
The "documentation" is mostly part of the problem, not part of the solution. Its presence, in overwhelming profusion, should lead you to expect more of this, not less.
We were talking about this at work today. One person expressed the opinion that it's human nature not to check something you know was fine last week. I got my back up: "That's WHY you FOLLOW the CHECKLIST."
Perzackly- and the checklist must, therefore, not be onerously long and complicated, else the temptation to skip items and take shortcuts will arise. (Full disclosure- I write the checklists at XCOR, and Randall critiques them, then holds my feet to the fire when we carry them out. This makes for some useful give & take on the detail needed in the checklist.)
This is also why it's incumbent on the checklist writer to make an easy-to-follow checklist, and on whoever designs the procedure to make an easy to follow procedure, and on whoever designs the equipment to design in such a way as to make it easy to do the right thing and hard to do the wrong things, etc. etc.
That's a lot easier when the same small group designs the hardware, the procedures, and the checklist, then actually does the work. Reading and re-reading books like "To Engineer is Human" and "Inviting Disaster" regularly also helps maintain healthy paranoia. One of the good things I learned from skydiving was the routine unselfconscious cross checking and verification, right up to doing pin checks on th eground and in the plane on the way up. Verify, verify, verify.
This is a little hard to do in an R&D environment where flexibility
> is important, but even there the people doing the checklists and > procedures have choices about how to set them up. It's tempting to > say "just do it right" but reality is that humans tend to make > certain kinds of errors more easily than others, and taking
that into account reduces the chances of mistakes like this one.
Yep. Designing the work flow and checklist so that you don't get instructions like "Clip the red wire. But first, clip the green wire," requires a fair amount of humility, some mental organization, and a sense of humor.
I get the impression that NASA in particular has a Superman
> complex about people's ability to follow complex, poorly written, > jargon heavy documentation and checklists.
Eschew Obfuscation. We don't use acronyms like (for instance) LMVV, we say LOX Manual Vent Valve, and use simple unambiguous verbs like Open and Close, not puffery like "Actuate". A checklist must be clear and coherent, and to hell with cool jargon. A reasonable technical vocabulary is okay, but Nasa's penchant for making acronyms (often contrived puns) is frankly stupid.
Example: Space Station Remote Manipulator System, or SSRMS. A five syllable acronym for "Arm". Gah. Worst case, with a shuttle docked, you may need to refer to the "Shuttle arm" or the "Station arm". It's utter foolishness to do otherwise, but damn, those buzzwords do sound cool on the comm circuit, don't they?
Doug, feeling a rant coming on.
_______________________________________________ ERPS-list mailing list [EMAIL PROTECTED] http://lists.erps.org/mailman/listinfo/erps-list
