Re: YOU are responsible, even when YOU are not to blame

[Andrew Plato <gilliankitty -at- yahoo -dot- com>]

<SteveFJong -at- aol -dot- com> wrote ...
> 
> If, however, you want to *prevent* errors, you first have to determine where 
> they come from--their root cause. Root cause analysis considers four possible

> sources of error: people, processes, tool, and materials. Errors can come 
> from all four sources--not just in manufacturing, where the method origi
> nated, but in software and documentation too.

This is another one of those business fallacies. That if you find the "root
cause" of errors, you can prevent future errors. This kind of thinking tries to
ignore two salient laws:

1. Errors are natural and normal part of any process
2. Humans are prone to inconsistent results

Finding root causes can be an extreme waste of time in high tech and scientific
environments, unless there are scientific and objective analysis of the larger
picture. You cannot have the people making mistakes also be responsible for
locating their cause. Naturally, they are going to see something other than
themselves as the cause. This is why, in technical documentation, a writer must
be edited by external sources. 

Furthermore, finding "root causes"  is dangerously close to "locating a
scapegoat."  That is, there is a huge difference between analyzing a business
and how it works vs. seeking out people to blame. Analysis is fundamentally a
"pattern recognition" task. In other words, you don't look at a single error
and try to find the cause, you look at a general pattern of behavior or output
and then attempt to analyze the overall quality/capability of that.  A writer
that consistently repeats the same errors, is obviously not learning from those
mistakes. If the mistakes are minor, and easy to catch, then it can be seen as
a mere inconvenience. If a writer keeps missing the concepts and consistently
producing poor documentation, then clearly there is a larger issue at stake. 

Conversely, taking a single error and attempting to track down its root cause
is most often a misleading endeavor. Drawing conclusions from a single instance
is faulty reasoning. If I spell a word wrong once, it doesn't mean I can't
spell. But if I spell 1000 words out of 1500 wrong, that's a pattern. 

This is ultimately exactly the scenario another poster presented earlier. A
fictitious conversation was used as an example where the engineer or manager
was berating the writer for a single error, as if the writer was incompetent. 
Again, faulty reasoning. A single omission does not constitute a pattern of
incompetence. 

Lastly, "detailed analysis" of processes is not always an efficient use of
time, especially if the process will be chucked and rebuilt for the next
project. Many high tech environments use disposable project methods. That is to
say, they are thrown out at the end of the project and rebuilt for the next
iteration. There is a certain Zen in doing that. It results in constant renewal
within a group. People rarely like to do the same thing over and over again.
And since the success of any process is inherently tied to the people using it,
it can be beneficial to tear down a project's infrastructure at the end and
allow it to be rebuild by the people that must carry it forward. 

Andrew Plato 

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Purchase RoboHelp X3 in April and receive a $100 mail-in 
rebate, plus FREE RoboScreenCapture and WebHelp Merge Module.  
Order here: http://www.ehelp.com/products/robohelp/


   Help celebrate TECHWR-L's 10th Anniversary starting this month!
Check out the contests at http://www.raycomm.com/techwhirl/special/contests/
Happy birthday to you, happy birthday to you, happy birthday TECHWR-L....

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