Subject: TQM
From: Anatole Wilson <awilson -at- VNET -dot- IBM -dot- COM>
Date: Wed, 3 Nov 1993 13:34:26 PST

TQM, another one of my favorite subjects to ramble on and on about....

I've seen companies where TQM worked with fabulous results, and other
companies where the effort died because it was mismanaged. Federal Express
is interesting because their TQM program died for a year except in one
small department, whose consequential increase in productivity and profit
sparked renewed interest throughout the company.

The funny thing about TQM is that most of it is common sense: Listen to
your customer; Set up a process so everybody involved knows what is
expected of them; No piece of work moves to the next step in the process
until it meets specifications; and everybody in the process is reponsible
to watch for defects.

Before I leap into any project, I want to know the process--what are my
sources for information, what do I have to do with what I get, and what
do I do with it when it's finished.

The controversial points, the ones that kill TQM programs are:

managers are afraid that if they give up some of their decision making
power, they'll become obsolete. See Ayn Rand theories of management.

Massive documentation--
Applying for Baldrige and ISO9000 takes a incredible amount of time, money
and organization. Personally, I think the problem is that Quality managers
don't know what they need to document, and so they document way too much.

I'm convinced that no training programs in history have ever been as muddled
as TQM training programs. Most often, a company will send a handful of
people to learn TQM, and then count on them to "spread the faith." From
what I've seen, the usual result is that the handful tell a couple of
other people "hey you--everybody's a customer--pass it on" and it dies there.
There's no follow-up training, and no effort from anywhere to really get the
program rolling.

This, to me, is the Number One killer of Quality programs. If they aren't
reinforced concretely and often, everyone forgets. there's also the problem
in large organizations of getting different departments to work together or
even talk to each other about processes they're all involved in.

I worked in one company that was just beginning a TQM program. My department
developed a process that cut book production time by 30% and actually
added quality checks throughout the process. Our measurements were based
*not* on the bottom line, but on the quality of the books and the process
(number of technical errors, etc.) Not only did the quality of the books
go up, but real costs went down. This experience and the way it not only
affected productivity and profit but also the company culture, has me
sold on TQM.
Anatole Wilson If anyone objects to any
Sr. Assoc. Information Developer statement I make, I am
IBM, Santa Teresa Labs quite prepared not only
awilson -at- vnet -dot- ibm -dot- com to retract it, but to
deny under oath that I
all company disclaimers apply ever made it.

Previous by Author: tech writing vs. marketing writing
Next by Author: typefaces
Previous by Thread: Re: TQM
Next by Thread: TQM

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

Sponsored Ads