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

Subject: Re: YOU are responsible, even when YOU are not to blame (long)
From: SteveFJong -at- aol -dot- com
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Fri, 11 Apr 2003 09:12:18 EDT


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.



Follow-Ups:

Previous by Author: Re: YOU are responsible, even when YOU are not to blame
Next by Author: Re: YOU are responsible, even when YOU are not to blame (long)
Previous by Thread: Re: Developer's Guide
Next by Thread: RE: YOU are responsible, even when YOU are not to blame (long)


What this post helpful? Share it with friends and colleagues:


Sponsored Ads