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: Andrew Plato <gilliankitty -at- yahoo -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Fri, 11 Apr 2003 09:10:31 -0700 (PDT)


<SteveFJong -at- aol -dot- com> wrote ...
>
> 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.

As I have said many times before Steve, Deming and his ideas were formulated
with a manufacturing-centric view of a business. A view where the core workers
were not using a great deal of personal judgment in their work. Deming's ideas
also pre-date the high-tech / Internet boom.

Also, if you look at the Japanese economy right now, I'd have to wonder what
happen to all these great ideas. In reality, Steve, Japan beat the US in a few
key markets not across the board, and almost all of them were manufacturing
based. No other country has ever come close to the US in terms of high tech
research and development.

Deming's ideas are interesting an have value. And finding root causes does have
some value in an organization. The fallacy is that often, in the process of
looking for root causes, the organization gets distracted and fails to just fix
errors.

Also, I think you put to much weight into these ideas. If Japan is a model for
business, then we're screwed. The Japanese economy has been in the toilet for
almost 10 years now. So clearly, all those brilliant ideas weren't enough.

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

And sometimes that randomness produces amazing results. As has been also
repeated many times, some of the most amazing technologies in history arose
from chaos (or Level 0). Randomness holds great potential.

Unfortunately, thanks to thinks like Maturity Models, there is this notion
beaten into people's skulls that disorganization is bad. These models want you
to believe that the only way to quality is through the rigid application of
process. This is patently false. It wants you to ignore the entire history of
invention and intellectual thought and favor some "business religion" where
process Uber Alles. It also assumes that process can compensate for ignorance.
In a manufacturing environment, where jobs are very limited, this is true to
some extent. In a high tech environment where jobs are broad and require a
great deal of judgment, these ideas simply don't hold.

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. Mostly, they didn't
limit themselves or waste energy on in-depth process analysis.

That isn't to say they didn't look at the causes of failures. Failures were
often the core of new inventions or breakthroughs.

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

Again, this 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. And then send it off to a
manufacturing company that DOES do stuff over and over again.

Its very important to differentiate these two models, Steve. You're trying to
apply manufacturing model concepts to everything here. In a software
development environment, manufacturing models don't work. There are many
reasons, the main one being that the core people doing the work must rely on
their own judgment and creativity, something that is generally ruled out in
manufacturing environments.

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

Of course he says that. What is he going to say? "Yeah, only some companies can
benefit from my wisdom."

Again, root-cause analysis has its benefits. But they are not absolute. There
is a time and place for it. In technical writing, this is not the instant a
single error is discovered. One error does not make a pattern.

I also think the best root-cause analysis is done at an individual level. A
professional is always asking him/herself "how can I do this better?" or "what
can I learn from that person or this company?" That is perhaps the most
powerful form of root-cause analysis, because its a single person trying to
better themselves.

The reason I am shy to root-cause analysis is because it is dangerously close
to "sanctioned blame hunting." Its very often used to merely point fingers and
obsess over minutia. Its why I suggested that the only people truly capable of
performing objective root-cause analysis at an organizational level are
external sources.

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.



Previous by Author: Re: YOU are responsible, even when YOU are not to blame
Next by Author: Blame vs. Responsibility
Previous by Thread: RE: YOU are responsible, even when YOU are not to blame (long)
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