QUALITY FUNCTION DEPLOYMENT
QFD is a methodology for translating customer needs into specific system or product
characteristics, and then for specifying the processes and tasks needed to produce that system
or product. As demonstrated in numerous applications, QFD not only yields end-item results
that meet customer needs, it does so in less time and at a lower cost than possible with
traditional development methodologies. QFD was developed by Mitsubishi ’ s Kobe Shipyards
in 1972, adopted by Toyota in 1978, and has since been implemented by companies
throughout the world.
The house of quality suggests areas in which designers might focus the effort to gain a
market niche. For example, the rating on the right in Figure 4-9 indicates that no company does
particularly well in terms of “ buttons easy to see ”despite the fact that customers rank that
requirement second in importance. A requirement that customers rank high, yet on which they
rank all companies low, suggests a design feature that could be exploited to improve a company
’ s competitive standing. The company making the RC, for example, might try to improve the
visibility of the buttons by increasing the size of the buttons and/or using bright colors. The
house provides a systematic way of organizing, analyzing, and comparing the how ’ s with the
what ’ s, and prevents things from being overlooked. It justifies where to devote time and
money, and where to refrain from adding resources. Still, the results of QFD are only as good
as the data that go into the house. At minimum, the competitive evaluations require two
perspectives: the customers ’ viewpoints regarding how the product compares to the
competition, and the views from engineers and technicians regarding how well the product
objectively meets technical requirements.
The data may come from many sources, including focus groups, telephone and
questionnaire surveys, experimental tests of competitors ’ products, and published materials.
As mentioned earlier, an important aspect of requirements definition is to determine
priorities—to distinguish between the critical few and trivial many aspects of the end-item
system to ensure that the critical ones are done correctly. As an example, a computer printer
might have as many as 30 different design features that affect print quality, but the most
important feature is the fusion process of melting toner on the page, which is a function of the
right combination of temperature, pressure, and time. Focusing on temperature, pressure, and
time narrows the design emphasis to the relatively few technical parameters of greatest
importance to performance. 13 These parameters become the ones for which designers seek
the “ optimum ” values. Once the optimum values have been set, the analysis moves on to
identify important factors in the manufacturing process necessary to achieve the design
requirements. In other words, the house of quality is just the first of several steps in the QFD
process that leads to a project plan.
Scope Definition
Scope definition is the process of specifying the breath of the project and its full span
of outputs, end-items, or deliverables; these sought-after requirements and end-results are
termed “ inclusions, ” referring to what is to be included in the project. Sometimes, to ensure
clarity about expected outcomes, the scope definition also specifies items, conditions, or
results not to be included within the project, i.e., “ exclusions ” (a project to construct a building,
for example, might exclude interior decorating and landscaping). Distinguishing between
inclusions (contractor responsibilities) and exclusions (possible customer responsibilities) is
important to prevent misunderstanding and false expectations. Scope definition focuses
primarily on project outputs and deliverables, not on time and cost—although certainly time
and cost delimit or dictate the deliverables; as such, time and cost are often listed as “
constraints ” in the scope definition. The result of scope definition is a scope statement , which
besides the main deliverables of the project and some background about the problem being
addressed or the opportunity being exploited might also contain project objectives, functions
to be fulfilled by the deliverables, user requirements or high-level specifications, assumptions
and constraints (to provide the rationale as to why the project has these deliverables and not
others), and high-level project tasks or major areas of work. Necessary information for scope
definition includes user needs and requirements, a business case or other expression of needs,
and constraints and assumptions; ideally the principal subsystems and components of the end-
item will also have been identified.
Everything considered as part of the project or contract, including support, side-items,
as well as related areas of work or deliverables not considered part of the project (exclusions)
are mentioned. Sometimes the scope statement also lists results or consequences to be
avoided, such as negative publicity, interference with other systems, pollution, or damage to
vegetation, soil, or wildlife. Vague terms that preclude measurement or direct observation
should be avoided in the scope statement. The scope statement is initially determined during
project initiation and is expanded and specified in detail during project definition. When the
project is unique, this preliminary scope statement may be somewhat vague; it should however
be revised and clarified while the detailed plan for the first phase is being developed. In
programs and large projects, separate scope statements are developed for the program,
individual projects that form the program, and major activities within projects.
