The Dilemma of Improving Quality In New Product Development
First presented at the Altshuller Institute
Conference "TRIZCON99" March 7-8, 1999
Larry R. Smith, Ford Motor Company
Boris Zlotin, Ideation International, Inc.
Alla Zusman, Ideation International, Inc.
Winning companies improve at a rate faster than that of their competitors. What can be
done to overcome system inhibitors and accelerate change associated with quality
improvement? The authors, with a team at Ford, studied this problem using TRIZ. Generic
system models containing inhibitors and enablers for quality improvement were created.
From these models, contradictions were formulated. Solution ideas were then generated
using selected TRIZ tools. Specific insights obtained by looking at this problem with TRIZ
will be discussed.
Key Words: Change, Inhibitors, Quality Improvement, TRIZ
Dr. Deming used to say, "The best thing you could do at Ford is to make your
customers so happy that they begin to brag about your product to others. When it comes
time to buy a new one, not only do they come back to buy yours
. they bring their
neighbors with them." This is the problem we choose to work on: "How do we
design the product right the first time?" "How do we introduce into an
organization like engineering, the necessary skills and methods so that changes are not
needed after the drawings are released?"
The problem is generic. "How do you introduce methodology 'XXXXX' in an
organization?", where "XXXXX" might be Taguchi methods, TQM, QFD, or even
TRIZ. "How do you accelerate the process of implementation of new, more powerful
methods?" The company that implements effectively and learns the fastest will
eventually win, no matter the starting competitive position.
The objectives of this study are to:
- Share an important, generic problem with others, get more people thinking
- Demonstrate how TRIZ may be utilized in a non-technical situation
- Provide an example of working with a Problem Formulator and Operators
- Provide an example of a situation related to the introduction of new engineering
Our process steps were as follows:
- TEAM: The first step in working with any problem is to form an effective team. Ours was
one of the best and consisted of: Don Brock, Vince Hagedorn, Joseph Hughlett, Radha
Krishnan, Larry Smith, Dmitry Tananko, Bill Tinney, Boris Zlotin, and Alla Zusman.
- CREATE PROBLEM FORMULATORS: Because our problem was generic, the system, enablers, and
issues we wanted to explore were well documented in literature. In particular the article,
"The Barriers to Total Quality Mangement," (Tamimi and Sebastianelli, 1998),
contained comments from a sample of 188 quality professionals. We used input from this
source and others (for example, Jones, 1982) to construct models of the problem. Each
model mapped causal relationships (both reinforcing and balancing) between the system
elements (Senge, 1991). George Box, from the University of Wisconsin, states, "All
models are wrong, but some are useful." These models are not perfect, nor do they
need to be. They are, however, useful in providing a context for idea generation. The
models created, shown in Attachment 1, are titled:
Fire-fighting, Quality Inhibitors, Main Inhibitors, Operational Management, Developmental
Management, Strategic Management, Quality System, Poor Quality Reinforcement, Short Term
Drivers, Ideal Engineering I, and Ideal Engineering II. Attachment
1 also contains an operational description of Problem Formulation, written by Alla
Zusman and Boris Zlotin.
- CREATE PROBLEM STATEMENTS: Problem statements were generated from the problem formulator
models. These statements define high leverage areas of the system, where change could
redefine the system archetypes and modify system performance. These high leverage areas
are contradictions, system nodes where reinforcing and balancing loops come together. Our
system models and problem statements, shown in Attachment 1,
were generated with software (Ideation, 1998). Our team worked by using the software as a
facilitation tool. We projected the software image onto a screen, then used the software
to record our ideas and thoughts, which we could later print for everyone's use.
- GENERATE SUGGESTIONS: The team used the problem statements and associated Operators and
examples to brainstorm ideas. The Operators we used were built into the software
(Ideation, 1998), and are part of the original TRIZ methodology (Altshuller and Shulyak,
1997) that has been further enhanced with the research of Boris Zlotin and Alla Zusman.
The software we used was programmed to provide the appropriate Operators for the types of
contradiction in our system model. The software also provided examples of how others used
these Operators. Even though the examples were technical in nature, we were able to find
many parallels for a non-technical system. For example, consider the physical principle of
resonance. Is it possible to "resonate" an organization with a new idea or a new
way of doing things? Systematically introduce the idea at the appropriate time using a
variety of inputs, to literally get the whole organization "percolating" in a
metaphor of "resonance"? The Operators and examples helped to "stretch our
minds" and generate "out of the box" ideas. We also used Lines of System
Evolution to stimulate ideas (Ideation, 1998).
In a typical brainstorming session, the idea flow is similar to the process of popping
popcorn. The ideas are slow to start, then proceed rapidly for a time, and then slowly
stop. When this happens, then another example of an Operator, or a different Operator is
presented for team consideration. The idea generating process then proceeds again. By
using this aspect of TRIZ, we were able to develop a much richer idea stream, with a much
greater number of ideas than we could have obtained by simple brainstorming. Our team
continued this way until the ideas we were generating were repeats of previous ideas, and
we had exhausted all the ideas that our particular group could contribute at the time.
- INTEGRATING IDEAS INTO CONCEPTS: Our team selected approximately fifty ideas for further
consideration. These ideas and some thoughts with regard to them are shown in Attachment
2. A few of these ideas were developed into a strategy proposal for presentation to Ford
Some of our team members have been thinking about this particular problem for over
fifteen years. The process we used helped to better understand the situation and generated
some new insights as to why it is so difficult to introduce new technology that improves
the ability to "design it right the first time":
- Fire-fighting: Reacting to events, "putting out fires" with an all-out
effort at the last minute, is fun. No wonder engineers and management like to do it. In
such a situation all constraints that are normal to the system disappear. The team can
literally, spend whatever they want, obtain whatever resources they need, over-run
budgets, take any action they like to resolve the situation. Often team members find
themselves "empowered" in such a way that they display leadership qualities to
senior management and later get promoted. It is a very different situation when the
engineers are asked early in a program to "design it right" and "prevent
problems". In the normal system, budget constraints make it difficult to get things
accomplished - it is a struggle and not fun. Is there a way to make the process of
preventing problems as much fun, and as rewarding, as "putting out fires"?
- The Effort of Designing It Right: Dr. Deming used to say that, "It costs just
as much to manufacture a defective part as it does to manufacture a good part."
Understanding the truth of this, and that manufacturing "bad" products is waste,
drives quality improvement in the manufacturing environment. The situation is different in
design. For the engineer, it is much easier to develop a poor design, and not use the new
and innovative tools necessary to develop an ideal design. No one knows whether a design
is good or bad until it is tested, something which happens very late in the design process
(perhaps years after the design work is initially done). In addition, testing only
identifies gross problems. The real quality of a design is not determined until real
customers provide feedback, often five or ten years after the design work is completed. Is
there a way to make it more difficult for an engineer to do a poor design than to do a
- The Problem of Measures: In the Product Development Process, engineers and
management have immediate measures relating to cost, weight, and timing. Quality and
customer satisfaction estimates are just that, opinions. Since teams which present a
negative opinion of their quality will receive a great deal of management attention, only
good opinions are ever reported. The actual results, reported years later, never reflect
the optimistic opinions of the original design team. Is there a way to make measurements
relating that strongly correlate with customer quality visable to engineers and management
real time in the Product Development Process?
Summary and Conclusions
Assisting an organization to implement new and exciting methods that produce results
years later is a very difficult challenge. Use of TRIZ methodology to study this problem
produced several useful insights, which help to explain why the problem is so difficult.
By sharing the problem, insights, and ideas with others, we can all work together to
overcome a difficult generic problem.
Altshuller, Genrich and Shulyak, Lev 1997, 40 Principles: TRIZ Keys To Technical
Innovation, Worchester, Massachusetts: Technical Innovation Center
Ideation Innovation Workbench Software System, 1998, Version 2.2,
Southfield, Michigan: Ideation International Inc.
Jones, Christopher J. 1982, Design Methods, New York: John Wiley & Sons,
Senge, Peter 1990, The Fifth Discipline, New York: Doubleday Currency, ISBN
Tamimi, Nabil and Sebastianelli, Rose 1998, "The Barriers to Total Quality
Management," Quality Progress, June, 1998, pp. 57-60