Re: TQM (longish)

Subject: Re: TQM (longish)
From: "Chet W. Cady" <cady -at- OCLC -dot- ORG>
Date: Fri, 5 Nov 1993 07:58:57 -0500

Carter Hansen wrote:

> Like the tired old
> phrase "Guns don't kill people; people do," TQM doesn't create quality,
> individuals do. TQM is simply a set of tools and principles that establish
> a strong framework for building quality in products and processes. Like any
> other tool, in the hands of a talented, conscientious craftsman it can work
> wonders; in the hands of an unskilled, unconcerned lout, it can perhaps do
> more harm than good.

I agree! Someone objected that someone else called Total Quality
Management was just a buzzword, and pointed out that the person really
agreed with Deming's principles.

Despite any agreement any of =us= might have with Deming, Total Quality
Management is in some quarters merely a buzzword. In my previous
job at the Evil Empire,* we had process and quality management (as it
was called there), and it helped =some=. But Deming and those of his
ilk assume that organizations that apply his ideas will do so with a
lick of sense. The Evil Empire lacked it. They talked quality but
didn't know what it was.

The process and quality management model prescribes a chain of
supplier-customer relationships. If you provided my input, you were
my supplier and I was your customer. Likewise, what I did with your
input resulted in my output, and I was the supplier to the people who
used my output as their input. They were my customers. And on and
on. Each level of customers defined what they wanted: that became the
standard for quality AT EACH LEVEL.

Theoretically, it could work, had we been dealing with numbers and
machines. Unfortunately, human factors are important and foul things
up.

The customers contracted with the Evil Empire through the salespeople.
The salespeople defined the customers' requirements for the system
engineers. The system engineers defined the salespeoples' requirements
for the next level of people who wrote design documents for several
areas. Then there were additional documents based on those documents.
There were about 5 levels between THE customers and us writers,
and there were people down the line from us! And no one but the
salespeople (and VPs) were allowed to talk to the customers.**

Whenever this process and quality management produced a garbage product,
however, each level of development could say, "Ah-ah-ah . . . we met
=your= requirements to the letter," and it was true. Participants
need to buy in not only to the means of quality management but also to the
intent of quality management. There are plenty of bureaucrats
out there who use quality management to further their cause of making
everything more complicated than it has to be.***

People with the power to fix things have to be willing to say, "Despite
our processes, something's gone awry." And people willing to say it have
to have power to say it and do something about it. But when the
process is cumbersome and quality as an ideal requires looking beyond
the specs and reqs documentation but quality as a practice is thought of
only in terms of that documentation, no manager (at least at the Evil Empire)
is going to jeopardize his or her reputation/career by missing deadlines
(which are part of the definition of quality).

Well, I know that if you're familiar with TQM you can poke holes in
the above process: it doesn't conform on several counts. That's the
problem: so many sites =think= they're "doing quality" but don't know
how far from the mark they really are.

Chet Cady
cady -at- oclc -dot- org
________
* Not its real name.

** As an aside: few people understood =why= they were doing things. Few
if any understood what another part of the product they were
developing did. A few did not understand even what their parts of the
product did: "I don't know =how= the customer plans to use this.
All I know is that the screen is supposed to look like the user
interface document's specification. The cursor has to move from field
to field in this order when the user presses <TAB>. These fields'
contents have to be validated before the cursor can move to the next
fields. These fields' contents have to be validated when the user
presses <ENTER>. These fields we =never= validate. These fields have
to be numeric. These fields have to be alphanumeric and start with an
alpha. These fields can contain no more than eight characters. These
fields contain exactly two characters." And such were the subject-matter
experts we worked with. BUT WE HAD A PROCESS THAT DEFINED QUALITY AND
SPECIFIED STAGES AND DATES AT WHICH WE WERE TO EVALUATE OUR WORK, BY GUM!

*** After being trained in process and quality management, one manager
related her being able to apply it in her very own home. One of
her kids refused to buckle his seatbelt. So this manager and her
her husband, who had also had this training (for the Evil Empire
seems to employ families), set themselves to applying the process
and quality management tools they had learned. The began to
analyze the situation. They asked their little "customer" what he
perceived the problem to be. And so on. It seems to me that any
parent with half a brain, especially two parents with advanced
degrees, should have intuitively known to ask the kid why he didn't
want to fasten his seatbelt, and found out that it wasn't that
he didn't =want= to but that he =couldn't= because it was too
tight and he wasn't strong enough to lengthen it himself.

Likewise, it seems that a lot of quality management is bone-
headedly obvious. It's just that there are some people below
the level of boneheads.


Previous by Author: FWD: SMTP delivery error
Next by Author: Contractions
Previous by Thread: Those "little boxes" are worth a fortune
Next by Thread: Re: TQM (longish)


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


Sponsored Ads