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 some of my comments thusly:

>> The fallacy is that often, in the process of looking for root causes, the 
>> organization gets distracted and fails to just fix errors.

You claim that in attempt to fix errors, organizations often fail to fix 
errors? That sounds like something you made up to disagree with me. Can you 
cite an example of this? 

>> The Japanese economy has been in the toilet for
>> almost 10 years now. So clearly, all those brilliant ideas weren't enough.

Clearly. What's Japan's share of the US auto market these days? How about the 
consumer-electronics market? How about the watch market? They've given back 
few of their gains.

>> These models want you to believe that the only way to quality is through 
the 
>> rigid application of process. This is patently false.

Why? Because you say so? The idea is patently true, and it's patently obvious 
by inspection. Quality is consistent, and randomness and disorganization will 
not give consistent results.

>> If you study the history of invention and technology, you learn that many 
of
>> the great minds were not process freaks. They were idealists, like Edison, 
who
>> had great ideas and then worked to fulfill those ideas.

Edison created Menlo Park, a design workshop where hundreds of employees 
worked at the job of turning out inventions according to a system. (And he 
certainly did study the causes of failure of his light bulb filament; it was 
in learning what didn't work that he figured out what did.) The romantic 
notion of the lone inventor died two generations ago; almost all patents and 
advances today come from large idea factories, also known as the research 
labs of major corporations and universities.

>> [Process quality] is an extremely manufacturing-centric view of business.
>> In the case of software development, its not true. The function is not to 
do
>> something over and over. Its to do something brand new, once.

This is false, except for level 0 businesses that create a product and can't 
update it. The function of a software-development organization is to create 
release after release of software. The hallmark of a level 0 organization is 
that getting product out the door is a near-death experience. I'm sure, 
Andrew, that you appreciate the value of repeat business. If you enjoy 
success on a job, is your first instinct really to do the next one 
differently in the hope of doing better? What if you do worse?

>> In a software development environment, manufacturing models don't work.

Why? Because you say so? They do work. Watts Humphrey, who created the 
Software Capability Maturity Model, is a software guy. In fact, he was 
manager of an IBM software development organization before he went to 
Carnegie-Mellon. He likes to ask skeptics of his methods, "I managed 1,000 
engineers. How many do you have?" When you have responsibility at that level, 
you lose patience with lone wolves. I managed a group that turned out 100 
documents a year. They weren't 100 unique documents, and we learned the 
efficiencies we needed to produce that much work with the staffing available.

>> In technical writing ... [o]ne error does not make a pattern.

Did I imply otherwise? No, I did not. One error does not make a pattern. A 
pattern makes a pattern. One book is not enough to see systemic problems. Try 
100 books a year. (Is your business that large? If so, you could be finding 
patterns.)

>> I also think the best root-cause analysis is done at an individual level 
...
>> That is perhaps the most powerful form of root-cause analysis,
>> because its a single person trying to better themselves.

You contradict your previous argument, and you don't understand root-cause 
analysis. You won't recognize systemic problems through individual analysis.

>> [Root cause analysis] is dangerously close to "sanctioned blame hunting."
>> Its very often used to merely point fingers and obsess over minutia.

I think the blame-the-writer model you advocate is unsanctioned blame 
hunting. I'm much more interested in eliminating problems than merely fixing 
them (or fixing blame). To do that, one needs a sound analysis of the source o
f the problems.

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