Six Sigma Forum Magazine

Volume 1 Issue 1 November 2001

Contents

Six Sigma and the Evolution of Quality in Product

Development
The evolution of Six Sigma parallels that of quality methods. Design for Six Sigma
can help take your organization even farther.
by Larry R. Smith, Ford North American Truck
George Box had it right when he said, All models are wrong but some are useful.
Nam Suh, chairman of the Mechanical Engineering Department at Massachusetts
Institute for Technology (MIT), developed a very useful model of Product
Development as a mapping of elements between various domains (customer
attributes to functional requirements to design parameters to process variables).
Peter Senge, also of MIT, developed a useful model concerning ways or levels of
thinking (in terms of events, patterns or structure). When these two models are
combined, a new model is created that can be used to understand the history and
evolution of quality and the role of Six Sigma and Design for Six Sigma (DFSS) in
product development.
Quality in product development began with attempts to inspect quality into products
or services either in the process domain (scrap and rework), the design domain
(verification tests and durability failures) or the customer domain (warranty costs
and complaints). The evolution of quality involved a significant mind-set transition
from reacting to inspection events to utilizing process patterns in engineering and
manufacturing to build quality into the product. Recent developments in quality
engineering involve the use of structural tools to lay the proper foundation for good
design and enable the process-level methods to work better. Six Sigma is used to
react to or fix unwanted events in the customer, design or process domains. DFSS is
used to prevent problems by building quality into the design process across domains
at the pattern level of thinking. Use of new structural tools such as TRIZ (a Russian
acronym for theory of inventive problem solving) and axiomatic design provide a
foundation for future enhancement of Six Sigma methodologies.
Model of Product Development
The process of design involves understanding what you want to achieve and then
selecting a strategy that achieves that intent. To better understand the history of
quality and the role of Six Sigma in product development, consider the domain model
of product development shown in Figure 1. Nam Suh, chairman of the Mechanical
Engineering Department at MIT, created this model, applicable to the development of
either products or services, in the late 1970s.1
Suh believes the creation of great products or services involves selecting strategies
associated with four primary activities or domains: customer domain, functional

domain, physical domain and process domain. The customer domain consists of
customer attributesa characterization of needs, wants or delights that define a
successful product or service from a customer perspective. The functional domain
consists of functional requirementsa characterization of design goals or what the
product or service must achieve to meet customer attributes from the viewpoint of
the designer. The physical domain consists of design parametersthe collection of
physical characteristics or activities that are selected to meet functional goals. The
process domain consists of process variablesthe collection of process
characteristics or resources that create the design parameters.
The development of products or services is highly iterative and involves selecting
elements in each domain and mapping these elements from one domain to another.
The better the mapping between these domains, the better the design. Figure 2
illustrates the generic nature of this model, which is literally applicable to any design
activity.
The evolution of design is correlated with the evolution of our thinking. Peter Senge,
a professor at MITs Sloan Management School, describes three levels of thinking:
events, patterns, and structure.2 The event level is all too familiar. Something
happens; we find out about it after the fact and are forced to react. Organizations
typically react to significant short-term events in measures such as sales, profits,
quality, etc. Pattern thinking involves understanding longer-term trends and
assessing implications. For example, a graph of U.S. automotive market shares for
Japanese, Korean and German automobile companies over the past decade is an
interesting pattern that should not be ignored by U.S. automakers. Structure
thinking involves looking at the total system to understand how system elements
relate to each other, and what in the system causes the patterns to behave the way
they do. Figure 3 overlays Senges levels of thinking onto Suhs domain model of
product development. This figure provides a convenient framework for thinking about
the evolution of quality and the role of Six Sigma.
The History and Evolution of Quality
The early history of quality in product development was based upon event thinking in
the various design domains (see Figure 4).
After World War II, the primary way of assuring quality to customers was inspection
after the process domain. Parts were produced, and then these parts were checked
to see if they were good enough to ship. If the parts were not good, then an event
occurred, resulting in rework or scrap and problem solving.
Event thinking also occurred in the physical domain. Many engineers simply threw a
design together and then tested it, expecting the design to fail. The failure of a
design verification test is an event that the engineers answered with a sequence of
build/test/fix cycles. Build/test/fix is actually a method used today by many
designers to inspect quality into the product or service. It is hoped the design gets
band-aided enough so it will function properly before the product or service gets to
the customer. Otherwise, the inevitable result is consumer complaints and warranty
in the customer domain.
Unfortunately, many companies today depend upon event thinking to assure quality
to customers. These companies learn about customers through analysis of warranty,

try to assure design integrity via batteries of expensive reliability tests and rely on
checks after assembly to assure that the product is good enough to ship. At a
company like GE, the cost of quality associated with event thinking in 1996 was
estimated to be as high as $10 billion each year in scrap, reworking of parts,
correction of transactional errors, inefficiencies and lost productivity.3
Event thinking companies, which typically operate at a sigma level between 3 and 4,
reap huge benefits by implementing Six Sigma. Six Sigma is an effective problem
solving methodology, and companies can utilize it to recoup a portion of their cost of
quality. Black Belts, who target projects based on warranty costs, test/durability
failures and manufacturing scrap/rework/productivity issues, save, on average,
$230,000 per project.4
Pattern level thinking was seriously introduced to product development when W.
Edwards Deming, Joseph M. Juran and others were invited to Japan shortly after
World War II. In 1950, Ichiro Ishikawa, president of the Union of Japanese Scientists
and Engineers, arranged for Deming to meet with the 21 top management
executives of Japanese industry and lecture about quality. Deming began by
introducing some ideas he had learned from Walter Shewhart, specifically the plando-study-act cycle of learning and statistical process control (SPC).
SPC, a pattern level quality method in the process domain, focuses on patterns or
trends in process data so that the process can be adjusted before an inspection
event occurs. When Japanese companies began to implement SPC, quality improved
dramatically. For the first time, product or design engineers knew that the parts they
designed were being manufactured according to print.
Companies begin to use Six Sigma at the pattern level when they target Six Sigma
for variation reduction in the process domain at their own and at supplier facilities.
Use of Six Sigma in this way can transition a company to sigma levels between 4 and
5. At a level of about 5 sigma, companies hit a wall and progress comes to a
standstill. Further improvement requires use of pattern thinking in the customer,
functional and physical domains, as well as in the process domain.
Use of pattern level thinking in the other design domains began when Kaoru
Ishikawa, known for Ishikawa diagrams and formalization of quality circles, noticed
that even though parts were being made to print, customers were still unhappy with
the products.5 Specifications and tolerance limits were stated in the drawings.
Measurements and chemical analysis were being performed. Standards existed for all
these things and the standards were being met, but these standards were created
without regard to what the customer wanted.
Ishikawa wrote, When I ask the designer what is a good car, what is a good
refrigerator and what is a good synthetic fiber, most of them cannot answer. It is
obvious that they cannot produce good products. You simply cannot design a good
product or service if you do not know what good means to a customer. Ishikawa
encouraged people to think at the pattern level in the customer domain, instead of
just reacting to a warranty event. He said that if you don't know what a good product
is, ask your customers. Customers will give you what Ishikawa called the true quality
characteristics.

The problem with true quality characteristics is that the designer cannot directly use
them. For example, a customer may want the steering of an automobile to be
comfortable. An engineer cannot write on a drawing, Make the steering
comfortable. The engineer must find substitute quality characteristics, dimensions or
characteristics of the design that are correlated with customer desires but have
meaning to an engineer.
Therefore, Ishikawa said that the designer must create a map that moves from the
world of the customer to the world of the designer. He used a tree diagram to create
such a map and called these maps quality tables. The Kobe Shipyard of Mitsubishi
Heavy Industries created the first quality table in 1972. Once the quality table was
completed, Ishikawa felt the designer had a customer-driven definition of a good
product or service. This definition or function of quality could then be deployed into
the product development activity. Thus quality function deployment (QFD) was born.
Popular and Powerful Methods
In subsequent years, about 120 different quality tools and methods have been
created at the pattern level for designers to manage product development process
trends, making inspection events a nonevent.
Some of the most popular and powerful methods are shown in Figure 5 and, in
addition to SPC and QFD, include: failure mode and effects analysis (FMEA) for both
the product and process domains, Genichi Taguchi's methods of parameter design
(for the product and process domains) and tolerance design (for the product
domain), design for assembly (DFA) and design for manufacturing (DFM), which
improve the mapping from the product to the process domain, and system
engineering, value analysis (VA) and value engineering (VE) in the functional
domain.
The transition from event thinking to pattern thinking is the transition from find and
fix to prevent. In the words of Henry Wadsworth Longfellow, It takes less time to do
a thing right than it does to explain why you did it wrong. So then why not do it
right the first time? The payoff in warranty savings, customer satisfaction and
productivity more than offset the relatively modest investment in longer-term
thinking.
The transition from event thinking to pattern thinking is also the transition from Six
Sigma to Design for Six Sigma (DFSS). Companies that rely on event thinking and
utilize Six Sigma realize that about 80% of the problems they are fixing (and the
money they are saving) are determined by design. DFSS is a rigorous approach to
designing products and services from the very beginning to ensure that they meet
customer expectations.6 DFSS is an integration of all the prevent quality tools across
the pattern level domains. Use of DFSS results in sigma levels between 5 and 6.
Further improvement requires implementation of structural thinking tools.
Thinking at a level of fundamental structure offers even higher leveraged
opportunities to create products and services that not only function as intended, but
also deliver unprecedented customer satisfaction. When the foundational structure of
design is properly established, the methods at the pattern level are much more
effective. When pattern level methods work well, the event outcomes become worldclass.

In the evolution of quality, two very powerful design methods have emerged at the
structural level: axiomatic design and TRIZ, a Russian acronym for theory of
inventive problem solving (see Figure 6).
Axiomatic design is the result of work by Suh. In the late 1970s, he asked himself
the question, Can the field of design be scientific? Suh wanted to establish a
theoretical foundation for design by identifying the underlying principles or axioms
that every great design must have in common. He knew that he could never prove
that these principles were true, but could he find a set of principles for which no one
could find a counterexample? After a decade of work, two principles emerged. From
these two principles, theorems and corollaries could be derived that, together, form a
scientific basis for the structure of great design.
The first principle that Suh discovered was the principle of independence. Consider
Suhs domain model shown in Figure 1. Mapping between domains represents a
mapping of whats to hows. The principle of independence states that in great
designs, the hows are chosen in such a way that the whats maintain independence.
For example, design parameters must be chosen in such a way that functional
requirements maintain independence. Consider the water faucet designs shown in
Figure 7.
The functional requirements for a water faucet are two: control the flow rate and
control the water temperature. The faucet on the left of Figure 7 has two design
parameters: a hot water knob and a cold water knob. What is the relationship
between these design parameters and the functional requirements? When the hot
water knob is turned, temperature is affected and so is flow. Turning the cold water
knob also affects temperature and flow. Therefore this design is coupled and the
functional requirements are not independent. If a consumer has optimized flow rate,
then turns one of the knobs to optimize temperature, the flow rate is changed and is
no longer optimal. Designs of this type eventually satisfy customers by iterating
between the two design parameters.
Consider the design on the right of Figure 7. This faucet has one handle and the
design parameters are to lift the handle to adjust flow and move the handle from
side to side to adjust temperature. In this design, adjusting temperature does not
affect flow and adjusting flow does not affect temperature. From an axiomatic design
point of view, this design is superior because the functional requirements maintain
independence.
Imagine what happens when a designer is working in a situation with a dozen or
more functional requirements. If the design is coupled, then optimization of one
function may adversely impact several other functions. When these functions are
fixed, the original function no longer works well. The designer is always tuning and
Band-Aiding such a design, and the customer will never be completely happy.
However, if the design is created in such a way that each of the functional
requirements is handled independently by the design parameters, then each function
of the design can easily be optimized with pattern level tools.
The principle of independence can be used to evaluate how good a design will be
when the design is still on paper. But suppose you have two design alternatives that
both follow the independence axiom. Now which one is better? The second principle
states that the better design will minimize the information content necessary for

implementation.7 Designs that have a solid axiomatic foundation simply work better
than designs that do not.
Suppose the designer cannot find a set of design parameters that keep all the
functional requirements independent. In this situation, improving one function
typically degrades another. An example in automotive steering is steering road feel
and parking efforts. When the steering efforts are high, the customer experiences
good road feel. However, high efforts can make it difficult for customers to park.
Adjusting efforts to make the vehicle easy to park will result in degraded road feel.
A typical approach to resolve this situation is compromisetrade off customer
functionality and hope for the best. This is where TRIZ is most helpful. TRIZ is the
result of more than 45 years of research by Genrich Altshuller and colleagues. 8
Altshuller hated compromise. He called the situation where functions oppose each
other contradictions and developed a methodology in which design teams could
systematically innovate and find design parameters that resolved contradictions,
creating win-win functional situations. The methodology began by identifying all
possible contradictions that existed in patent databases and identifying how these
contradictions were resolved. Altshuller found that only a few particular principles of
resolution have ever been used in the history of mankind to resolve certain pairs of
functional contradictions.
For example, suppose the functions of weight and reliability contradict. When the
design is changed to improve reliability, weight increases. When weight is decreased,
reliability degrades. Altshuller found there are only four principles that have ever
been used to resolve this contradiction.9 He created a matrix of contradictions and
resolution principles and used this information to guide design teams so that they
could brainstorm in areas that are likely to lead to win-win solutions. Altshuller also
believed in minimizing information content; he called this the principle of ideality.
Later, TRIZ was expanded to include an entire algorithm of innovation techniques,
including the study of system evolution.
Altshuller found that systems tend to evolve along specific laws and lines of
evolution. By studying system evolution for the past and present (for the
supersystem, system and subsystem), a designer can identify the current stage of
system evolution. By applying laws and lines of evolution, design teams can predict
what the next developments of the system will be. This is a huge competitive
advantage. Companies that operate at the event level obtain information about the
customer through warranty data. Companies at the pattern level interact with
customers and find out what customers believe is important today. No customer can
tell the designer what will be important tomorrow. At the structural level, TRIZ
directed evolution predicts what will be important to customers tomorrow.
So if TRIZ works at the structural foundation of design, why does the name imply
problem solving? The answer is simply that higher level thinking can always be used
as a methodology to solve lower level problems. The fact that problems exist in the
event realm means that the original process of design had serious flawspattern or
structural work that should have been done is either missing or incomplete. The
designer can always go back and complete this work at anytime.
This is why completing work associated with pattern or structural tools can quickly
lead to problem resolution. A good example of this is Six Sigma. It addresses

problems created by event level thinking, but the methodology of Six

Sigma utilizes pattern level tools such as FMEA.
The Roles of Six Sigma and DFSS
The product development model in Figure 6 is useful to illustrate the roles of Six
Sigma and DFSS and also provides implications for next steps. The role of Six Sigma
is to solve problems at the event level in the customer domain (customer complaints
or warranty), the product domain (design or service does not pass tests) or the
process domain (internal scrap, rework or capability issues). An effective Six Sigma
program, even though this program saves lots of money, is still an attempt to inspect
in quality by addressing events after the fact. A company that operates only at this
level will never be competitive with a company that prevents problems in the first
place using DFSS.
The role of DFSS is to build quality into the designby implementing prevent thinking
and tools in the product development process. DFSS is, in fact, an integration of
prevent methods at the pattern level across all four domains. The relative roles of Six
Sigma and DFSS in product development are shown in Figure 8.
An effective DFSS program must utilize tools that make a difference in each design
domain. For example, a DFSS program that does not interface with customers or
does not utilize powerful methods like Taguchis parameter design (to hit the design
with noise or uncontrolled variation and adjust controllable factors in the design to
make the design robust against noise) is a program that is guaranteed to leave
significant portions of the work of design incomplete. This will virtually guarantee
that the Six Sigma program will have plenty of issues to work on in the future.
Both Six Sigma and DFSS can be made more effective by incorporating structural
tools such as axiomatic design and TRIZ into the methodology. Because these tools
address design foundation flaws, they will enhance every aspect of Six Sigma and
DFSS, making the process of problem solving and problem prevention much more
insightful, productive and efficient than programs that do not utilize these methods.
Move Past the Competition
Quality tools and methods have evolved utilizing three stages of thinking (event,
pattern and structure) across various domains associated with product development.
The evolution of Six Sigma parallels the evolution of quality methods. Six Sigma
addresses event level concerns that occur in product development after the fact.
DFSS represents a higher evolution of the methodology, utilizing pattern level
thinking and tools to build quality into the product or service.
The future of Six Sigma and DFSS involves incorporating structural thinking methods
such as axiomatic design and TRIZ. Use of these methods will make Six Sigma and
DFSS more effective and more productive with less effort. Companies that wish to
accelerate development of their own quality programs can utilize the evolutionary
trends explained in this paper to understand their current level of evolution and to
implement focused actions that can quickly move them past their competition.
REFERENCES

1.
2.
3.

Nam P. Suh, The Principles of Design (New York: Oxford University Press, 1990).

4.
5.

Ibid.

6.
7.
8.
9.

Peter M. Senge, The Fifth Discipline (New York: Doubleday, 1990).

Mikel Harry and Richard Schroeder, Six Sigma: The Breakthrough Management Strategy Revolutionizing
the Worlds Top Corporations (New York: Doubleday, 2000).
Kaoru Ishikawa, Quality Analysis, 1977 ASQC Conference Transactions (Milwaukee: ASQ, 1977), pp.
423-429.
Mikel Harry and Richard Schroeder, Six Sigma: The Breakthrough Management Strategy Revolutionizing
the Worlds Top Corporations (see reference 3).
Nam P. Suh, Axiomatic Design: Advances and Applications (New York: Oxford University Press, 2001).
Genrich Altshuller and Lev Shulyak, 40 Principles: TRIZ Keys to Technical Innovation (Worchester, MA:
Technical Innovation Center, 1998).
Ibid.