Re: YOU are responsible, even when YOU are not to blame (long)

[SteveFJong -at- aol -dot- com]

Andrew Plato <gilliankitty -at- yahoo -dot- com> responded to my description of 
root-cause analysis with a series of completely incorrect pronouncements. 
(Sometimes taking the contrary position just puts you in the wrong.) Rather 
than let them sit in the archive unchallenged, I feel I ought to clarify. My 
comments are mainly with reference to the works of Philip Crosby and W. 
Edwards Deming.

Root-cause analysis is not a "business fallacy;" it is part of the 
quality-improvement methodology that enabled the Japanese to beat our brains 
in and bankrupt many of our businesses in the 1980s and 1990s, until we 
adopted the same methods and started to return the favor. Error is not a 
"natural and normal part of any process;" that is tolerance of error. (Deming 
points out that we demand high quality of others and expect them to accept 
our errors--not gonna happen. Crosby asks what the acceptable level of error 
is for, say, dropping babies on their heads or amputating the wrong leg.) A 
process that consistently generates errors needs to be fixed. More to the 
point, a system that generates errors can't be fixed by the people working in 
it, and it's useless to blame workers for those errors. (That is "finding a 
scapegoat.")

People do make mistakes, but almost everyone naturally tries, and prefers, to 
do a good job. (This is a political statement which I prefer to believe 
personally, but it's also a basis of Crosby and Deming's work.) Editors are 
not needed because writers are irresponsible; they are needed to find errors 
(in the old model) or, preferably, to set and improve quality standards (in 
the modern model).

Finding a root cause is not "finding a scapegoat." The scapegoat was 
originally an animal chosen at random to be driven away from the village, 
taking the evils of the tribe with it. This became the idea of picking a 
person at random and punishing him for the faults of all. The essential 
nature of scapegoating is that (a) it wasn't really his fault and (b) blaming 
him won't solve the problem. Not locating the root cause, but instead blaming 
the workers in the system, is scapegoating. (Deming worked with a factory 
where holes were drilled. An unacceptable problem of misaligned holes was 
traced to one old dill press with worn bearings. No amount of training, 
hiring, and firing workers fixed the problem; replacing the bearings did.)

Andrew suggests that in the high-tech business model, nothing is repeated 
from project to project. There is no learning (and apparently no hugging 
either). Some businesses operate that way; in Watts Humphreys's Software 
Maturity Model, they're Level 1 organizations. (JoAnn Hackos adopted the 
model to doc groups, adding Level 0: Oblivious.) These businesses struggle 
for the obvious reason that they can't improve; the quality of their work is 
random. Who wants random quality? As soon as a business or organization 
becomes conscious, it realizes that its function is to do things over and 
over. (I don't write a book, I write books.)  Successful business try to 
avoid the approach Peter Cook once elucidated: "I have learned from my 
mistakes, and I feel I can repeat them exactly."

I'm afraid that in picking the typo example I played into Andrew's 
writer-bashing. Let me take a more realistic and significant example. Imagine 
a contract writing firm that bids on jobs based on estimates prepared by a 
set of project managers. When a bid is won, the project manager staffs and 
oversees the effort. There's a problem: Projects are consistently taking much 
longer than estimated, and clients are unhappy.

The blame-the-worker mentality leads to firing those incompetent, slow 
writers and hiring better people.  Indeed, that may be the problem; but I've 
said the problem is consistent. (Consistency of a problem is a big clue that 
it's systemic.) A root-cause analysis suggests other possible sources (which 
I make up, but you'll recognize them all as at least plausible):

PEOPLE
Incompetent, slow writers
Inexperienced writers

PROCESS
Hiring poor writers
Ill-defined exit criteria
Poor estimation
Inefficient process
Delays in review/approval
Insufficient training
Change of scope
No backup strategy--lost data

TOOLS
Computer crashes
No printer on site
No computer provided--contractor systems incompatible

MATERIALS
Requirements changes
Missing/late/poor specs

Let's concentrate on one cause that, for the sake of argument, pans out: poor 
estimation. Let's say that through analysis we discover that one of the 
project managers is consistently turning in overoptimistic estimates--50% 
low, say. You're getting the business because the clients are happy to hear 
you can do the work in half the time, but then you can't deliver. The 
writer-bashing question is: Why the hell can't those worthless slugs get the 
work done? You'll go through a lot of writers that way, and form a poor 
opinion of them in the process. A better question is: Why are your estimates 
so far off? On what do you base your estimates?

Obviously, if I pick the root cause, I can illustrate either point. It would 
take many projects, and an honest and thorough analysis of each, to locate 
actual root causes. In my experience, I've seen all of these problems, and 
sometimes there are other root causes. (A 3M study once determined that 
schedule problems were almost always due to missing/late/poor specs. Instead 
of bashing the writers, they improved their specs, and saved quite a lot of 
money in the process.) From looking at many processes in many industries, 
Deming, who did this for over 50 years, concluded that workers are the 
problem less than one time in ten; the rest of the time, it was the fault of 
the managers who set up and oversaw the systems. And he told top management 
to its face that they were at fault. (His seminars were legendary.) 

Finally, a point on "high tech is different": Crosby writes that everyone 
he's ever consulted with says his or her business is unique and special, and 
cannot benefit from his quality system. Crosby hasn't been at it as long as 
Deming was, but so far, he says, they've been wrong every time 8^)

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