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

[SteveFJong -at- aol -dot- com]

Andrew <gilliankitty -at- yahoo -dot- com> continues the discussion of root-cause 
analysis and quality:

>> Example, a document has consistently wrong data about a product feature. 
The
>> writer becomes obsessed with figuring out why he got the wrong data (or who
>> gave it to him) that he gets distracted and does not just plant his butt 
in a
>> chair and fix the doc. The need to justify an error is so powerful that it
>> overrides the need to repair that error.

Has this ever happened? I asked for a citation, not a made-up counterexample 
pulled out of your ear.

>> My methods assume right from the start that problems will happen.
>> Yours assumes that problems won't happen.
>> I know for a fact, problems always happen.

Strawman argument: I didn't say that. What I said was that the find-fix cycle 
is inefficient, and that with good processes, errors can be avoided. 
Find-and-fix is the management equivalent of the font fondling that you 
decry: it's useless scrap and rework. Do you always have to have problems? 
No. Notice that Japanese cars have gotten to the point where you can often 
get one without *any* defects whatsoever--sometimes one or two defects, but 
sometimes none. Because fixing even one defect after delivery can eat up the 
entire profit margin on a car, zero defects is enormously efficient. Detroit 
thought zero defects was an impossible goal; they're still working to catch 
up. Considering how many steps and (and people) are involved in automobile 
manufacture, how do you think they get to zero defects? By using good 
processes.

>> The funny thing is, Steve, most Jap [sic] cars are now made in the US.

First, ethnic slurs have no place in this forum. Cut it out.

Second, you're otherwise correct: many Japanese cars are now built in the US; 
as far as I know, they are of almost the same level of quality. The quality 
process is independent of culture. (It should be: the Japanese learned it 
from Deming.) The quality of Japanese products shows no evidence of your 
hypothetical obsessed-with-process-not-fixing-errors problem: Japanese 
products continue to set the standard for high quality. Other countries have 
market share too; do you claim they use a different quality process?

>> Consistency does not equal quality.

That's 100% wrong. (Are you unaware of that or are you simply debating?) 
Here's half a dozen URLs pointing to definitions of quality in various 
fields, mostly high tech, in which consistency is primary or prominent:

GNU software: http://www.gnuenterprise.org/project/docs/quality.html
Web site design: http://www.jsiteweb.com/philosophy/quality.asp
Web page design: http://www.pantos.org/atw/35271.html
Video closed captioning: http://closedcaptions.com/high_definition.htm
Digital imaging: 
http://www.library.cornell.edu/preservation/tutorial/quality/quality-01.html
Beer: http://www.probrewer.com/resources/library/bp-qualitycontrol.php

Consistency is a fundamental quality attribute; all definitions of quality 
include it directly or list it as the first corollary. Would you prefer a car 
that consistently starts, or not? A document that consistently spells terms, 
or not? A gun that consistently fires, or not? A table of database columns 
that's consistently correct, or not? A doctor who consistently diagnoses 
correct ailments, or not? Even a cheap product has quality if it's at least 
consistent; even an expensive product loaded with doodads is of poor quality 
if it's inconsistent.

You should notice consistency even in one document (internal consistency); 
when you run a group, or a business, you should notice consistency from 
document to document or project to project.

>> Moreover, consistency rarely leads to ingenuity.
>> And in the high-tech markets, ingenuity is critical to market success.
>> This is particularly true of software companies
>> (where many of us work).

So do I. No one is preventing you from achieving your goals in an innovative 
way. But innovation is not an excuse for poor work. There is no such thing as 
innovative accuracy--a statement is either right or wrong. There is no such 
thing as innovative spelling--you either spell the words right, or you don't. 
There is no such thing as innovative scheduling--you either finish on time, 
or you don't. The argument that consistency or process somehow gets in the 
way of innovation is a false dilemma.

>> IBM is NOTORIOUS for being a process obsessed monstrosity. And when was the
>> last time IBM had a huge software hit. IBM makes the grand, whopping 
majority
>> of their income in consulting. Handing out advice to people who, 
apparently,
>> think its important.

Humphrey is no longer at IBM, but you miss the point. He has more software 
development experience than you, me, and 99% of all software managers. He is 
showing them how to run their organizations as businesses, with greater 
efficiency, predictability, and quality, and less expense, uncertainty, and 
error. He is the leading authority in the field, and his results speak for 
themselves, and I'm quite happy to cite him.

>> My preference is to have the individuals analyze their own work and ask
>> themselves "how can I do my job, and fulfill the organization's objectives
>> better?" This is what professionals do. They are on a constant continuum of
>> self-improvement.

Please, Andrew. The same individuals who are 100% at fault for errors, and 
99.9% ignorant of the subject matter? We've all seen your rants and we all 
know your professed opinion of individuals. Blow smoke up someone else's rear 
end.

>> Your preference is to perform some rigid analysis of the system. And design
>> more processes and procedures to rule out the chance for error. This is 
what
>> bureaucrats do. They are on a constant continuum of organizing things and
>> striving for some zero-friction cycle. 

"Bureaucrat"? You cut me to the quick. As a writer, I'm simply trying to do 
the best work I can, as efficiently as I can, for my readers; in that 
context, "best" does not mean good one time, poor the next. As a manager, I'm 
interested in getting the best documents out to readers, as cheaply as 
possible for my clients; in that context, "best" does not mean one writer 
does great work, another poor.

Now, I didn't mean to suggest that if you only write one document, or you're 
a sole writer, that you should go through a root-cause analysis. There are 
more efficient ways to learn how to do better work. (I recommend STC for 
that.) But as soon as you have more than one writer, or more than one 
project, you might start to benefit; and once you get to the 50 
documents/year level, you will definitely benefit.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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/techwr-l/


   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.