ISO 16355-4:2017

INTERNATIONAL ISO
STANDARD 16355-4
First edition
2017-02
Applications of statistical and related
methods to new technology and
product development process —
Part 4:
Analysis of non-quantitative and
quantitative Voice of Customer and
Voice of Stakeholder
Application des méthodes statistiques et des méthodes liées aux
nouvelles technologies et de développement de produi —
Partie 4: Analyse du retour client (Voice of Customer) ou du retour des
parties prenantes (Voice of stakholders) quantitatif et non-quantitatif
Reference number
©
ISO 2017
© ISO 2017, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2017 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Basic concepts of QFD . 1
5 Integration of VOC and VOS analysis and product development methods .1
5.1 QFD support for product development methods . 1
5.2 Flow of product development with VOC and VOS analysis . 2
5.2.1 Organization of the VOC and VOS analysis . 2
5.2.2 Outline of VOC and VOS analysis . 2
6 Types of QFD projects . 2
7 VOC and VOS analysis team membership. 2
7.1 VOC and VOS analysis uses cross-functional teams . 2
7.2 Core team membership . 2
7.3 Subject matter experts . 2
7.4 VOC and VOS analysis team leadership . 2
8 Seven management and planning tools . 3
9 Analysis of the voice of customer (VOC) or voice of stakeholder (VOS) .3
9.1 General . 3
9.1.1 Benefits of VOC and VOS analysis . 3
9.1.2 Sources of VOC and VOS . . 4
9.1.3 Information contained in VOC and VOS . 5
9.2 Translating VOC and VOS into customer needs . 7
9.2.1 General. 7
9.2.2 Verbal translation . 7
9.2.3 Cause-to-effect diagram . 7
9.2.4 Customer voice table . 9
10 Structuring information sets .10
10.1 General .10
10.2 Affinity diagram .10
10.2.1 General.10
10.2.2 Steps to make an affinity diagram.10
10.3 Hierarchy diagram .11
10.3.1 General.11
10.3.2 Steps to make a hierarchy diagram .12
11 Prioritization .13
11.1 General .13
11.2 Applying AHP to customer needs .14
11.3 Steps to AHP using a spreadsheet .15
11.4 AHP survey format for customer needs prioritization .16
11.5 Sample size for customer needs prioritization .17
11.6 Applying AHP to a customer needs hierarchy .18
11.7 Analytic network process (ANP), fuzzy AHP, and fuzzy ANP .19
12 Quantification .19
12.1 General .19
12.2 Quality planning table.20
Bibliography .25
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO’s adherence to the World Trade Organization (WTO) principles in the
Technical Barriers to Trade (TBT) see the following URL: www . i so .org/ iso/ foreword .html.
This document was prepared by Technical Committee ISO/TC 69, Applications of statistical methods,
Subcommittee SC 8, Application of statistical and related methodology for new technology and product
development.
A list of all the parts in the ISO 16355 series can be found on the ISO website.
iv © ISO 2017 – All rights reserved

Introduction
Quality Function Deployment (QFD) is a method to ensure customer or stakeholder satisfaction and
value with new and existing products by designing in, from different levels and different perspectives,
the requirements that are most important to the customer or stakeholder. These requirements should
be well understood through the use of quantitative and non-quantitative tools and methods to improve
confidence of the design and development phases that they are working on the right things. In addition
to satisfaction with the product, QFD improves the process by which new products are developed.
Reported results of using QFD include improved customer satisfaction with products at time of launch,
improved cross-functional communication, systematic and traceable design decisions, efficient use of
resources, reduced rework, reduced time-to-market, lower life cycle cost, and improved reputation of
the organization among its customers or stakeholders.
This document demonstrates the dynamic nature of a customer-driven approach. Since its inception
in 1966, QFD has broadened and deepened its methods and tools to respond to the changing business
conditions of QFD users, their management, their customers, and their products. Those who have
used older QFD models have found that these improvements make QFD easier and faster to use. The
methods and tools shown and referenced in this document represent decades of improvements to QFD;
the list is neither exhaustive nor exclusive. Users should consider the applicable methods and tools as
suggestions, not requirements.
This document is descriptive and discusses current best practice, it is not prescriptive by requiring
specific tools and methods.
INTERNATIONAL STANDARD ISO 16355-4:2017(E)
Applications of statistical and related methods to new
technology and product development process —
Part 4:
Analysis of non-quantitative and quantitative Voice of
Customer and Voice of Stakeholder
1 Scope
This document describes the analysis of the voice of the customer (VOC) and the voice of the
stakeholder (VOS). These include translation of VOC and VOS into true customer needs, prioritization
of these needs, and competitive benchmarking of alternatives from the customer’s perspective. This
document also provides recommendations on the use of the applicable tools and methods.
Users of this document include all organization functions necessary to ensure customer satisfaction,
including business planning, marketing, sales, research and development (R and D), engineering,
information technology (IT), manufacturing, procurement, quality, production, service, packaging and
logistics, support, testing, regulatory, and other phases in hardware, software, service, and system
organizations.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 16355-1:2015, Applications of statistical and related methods to new technology and product
development process
3 Terms and definitions
For the purpose of this document, the terms and definitions given in ISO 16355-1 apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http:// www .electropedia .org/
— ISO Online browsing platform: available at http:// www .iso .org/ obp
4 Basic concepts of QFD
The basic concepts of QFD are described in ISO 16355-1:2015, Clause 4.
5 Integration of VOC and VOS analysis and product development methods
5.1 QFD support for product development methods
QFD support for product development methods is referenced in ISO 16355-1:2015, 5.1.
5.2 Flow of product development with VOC and VOS analysis
5.2.1 Organization of the VOC and VOS analysis
The flow of VOC and VOS analysis methods and tools can vary according to the organization and project
requirements. Typically, they begin with broad concerns and through prioritization flow down to
specifics.
5.2.2 Outline of VOC and VOS analysis
Figure 1 illustrates the organization of the clauses of this document. Here is an outline of the specific
steps and their respective clause numbers. Further in the document, each clause describes the step and
suggests applicable methods and tools with guidance that can be used to accomplish the step.
f
Figure 1 — VOC and VOS analysis outline
6 Types of QFD projects
QFD projects can encompass new developments, as well as generational improvements, to existing
products. The types of QFD projects are referenced in ISO 16355-1:2015, Clause 6.
7 VOC and VOS analysis team membership
7.1 VOC and VOS analysis uses cross-functional teams
Cross-functional teams are referenced in ISO 16355-1:2015, 7.1
7.2 Core team membership
Core team membership is referenced in ISO 16355-1:2015, 7.2.
7.3 Subject matter experts
Subject matter experts involvement is referenced in ISO 16355-1:2015, 7.3.
7.4 VOC and VOS analysis team leadership
VOC and VOS analysis teams can be led by members of business functions such as sales, marketing,
market research, customer service, customer support, and others with firsthand knowledge or contact
with customers and stakeholders.
NOTE The VOC or VOS team leader can take a position of being function-agnostic so as to remain neutral to
any business department or activity.
2 © ISO 2017 – All rights reserved

8 Seven management and planning tools
The seven management and planning tools are referenced in ISO 16355-2:2017, 8.2.
9 Analysis of the voice of customer (VOC) or voice of stakeholder (VOS)
9.1 General
9.1.1 Benefits of VOC and VOS analysis
The benefits of VOC and VOS analysis include the following.
a) Simplify complex statements into single issue statements.
EXAMPLE A VOC can state that the process should be “quick and easy,” but are both equally important? The
VOC should be simplified into “quick” and “easy” so that the customer can prioritize more precisely.
b) Discover unspoken or latent customer or stakeholder needs.
EXAMPLE A VOC can state that the customer wishes to tag photographs with meta information. It is
reasonable to conclude that the customer can also with to tag videos, music and audio, and other types of
non-text information for ease of retrieval.
c) Improve accuracy of prioritizing which customer needs matter most.
Accurate prioritization requires having subject matter knowledge. Generally, customers have more
knowledge about their needs than about solutions. Similarly, producers have more knowledge
about solutions than customers. So, if VOC or VOS is about a solution, translating it into a need first
helps customers prioritize more accurately.
EXAMPLE A VOC for web access states account should have no more than one screen to login, and should
have high security. Both are product functions of ease of access and user account security. Translating these
into customer needs, these could mean “I can login quickly just to check on my bank balance while at the
register”, and “my money is safe when making online payments.” Depending on the use case, there would
be different priorities, and it would be more accurate for customers to prioritize these statements as needs
rather than as product functions.
d) Quantify current and hoped for levels of satisfaction.
EXAMPLE A customer buying a laptop computer can more easily state a desire to store twice as many
photographs as now, rather than needing a 500 GB hard drive.
e) Benchmark alternatives.
EXAMPLE A customer can more easily relate to how many photos can be stored on one laptop vs
another model.
f) Identify selling points.
EXAMPLE Sales promotion and labelling can point to photo storage capacity instead of hard drive size.
g) Keep from arriving at solutions too quickly.
EXAMPLE If solutions are identified before key stakeholder needs have been clarified, then the ability
to reconfigure the solution to satisfy missing needs can be precluded. As an example, in information
and communications technology (ICT) solution designs, key information access needs can be blocked if
extreme information security measures have been committed too early in the solution design. Similarly,
if information access needs are translated into solutions independently of consideration of security needs,
then solution security vulnerabilities can be introduced that are difficult or costly to address during solution
development.
h) Assure solutions are complete.
This ensures consistent quality in the solutions developed later in the product development process.
EXAMPLE A VOC for an industrial vehicle is for a 2,8 m lift height. What the customer forgets to mention
is that the loads typically weigh 250 kg and at that height would cause the vehicle to tip. By translating
this product specification into a customer need of “I can maximize the footprint of the storage facility,” the
QFD team was able to determine other product specifications related to centre of gravity, swing arc, mast
diameter, and others missing from the original VOC.
i) Greater solution options.
EXAMPLE A VOC for hot coffee translated into “It is cold outside and I want to feel warm.” The QFD team
identified other solutions for feeling warm, such as alcohol and spice.
j) Predict satisfaction with different solutions.
EXAMPLE A VOC for greater maneuverability of a farm tractor was more clearly understood when
translated into customer needs related to the soil type and travel speed. These identified different turning
radii that could later be tested in the field.
9.1.2 Sources of VOC and VOS
ISO 16355-2 and ISO 16355-3 identify potential sources of VOC and VOS that include, but are not limited
to, the following:
a) customer process model things-gone-right and things-gone-wrong;
b) customer gemba table clarified items;
c) customer support and help systems;
d) customer supplied specifications;
e) focus groups;
f) social media;
g) free response questionnaires;
h) interviews;
i) customer satisfaction surveys and sampling surveys;
j) lead user analysis;
k) warranty returns, scrap, maintenance records, unplanned field failures, and complaints;
l) sales, maintenance, and technical visit reports;
m) ethnographies;
n) continuous QFD and collaborative QFD;
o) design thinking;
p) conference papers, reports, and journals;
q) market research;
r) big data;
s) gender mainstreaming analysis.
4 © ISO 2017 – All rights reserved

9.1.3 Information contained in VOC and VOS
9.1.3.1 General
VOC and VOS is raw, unprocessed information from the customer or stakeholder. It often includes
complaints, needs, functional requirements, performance specifications and targets, solutions,
components, materials, activities, information, and other customer or stakeholder statements. The
following are examples of different statements or narratives in VOC and VOS. These vary according to
the product, service, information technology, or process, but the following are common.
NOTE To be most useful, these can be sorted, analysed, structured, quantified, and prioritized by key
customers.
9.1.3.2 Customer or stakeholder use
Information related to customer or stakeholder segment or attributes, modes or environment of use or
use case.
EXAMPLE Customer is certified or chartered public accountant working on end-of-year financial statements.
Some tax law changes have not been published.
9.1.3.3 Customer needs
The benefit to a customer from having their problem solved, their opportunity enabled, their image (to
oneself or to others) enhanced, or being advanced to a more desirable state. Customer needs should be
positively stated if possible, and independent of the product.
NOTE A customers need explains why a customer wants something, not what a product does.
EXAMPLE I must ensure my client follows all applicable tax codes. I must ensure all applicable tax forms are
filed on time.
9.1.3.4 Functional requirements
Inherent performance of the product or an action that the product must be able to accomplish. The
manner in which the product accomplishes the action is not part of the functional requirement.
NOTE 1 Can be expressed as a capability.
NOTE 2 Some QFD texts call this a quality element or substitute quality characteristic.
EXAMPLE Tax reporting software must be up-to-date within 24 h of changes. Tax reporting software must
flag for tax preparer all applicable changes in tax code since last filing for client.
9.1.3.5 Function
Specific statement of what needs to be done, expressed as a verb plus noun (English), without specifying
how to accomplish it. Can be mechanical, human, or software.
EXAMPLE Support weight.
9.1.3.6 Technology
A specific way to enable a function.
EXAMPLE For the function transfer data, technologies include Ethernet, Bluetooth, Wi-Fi, 4G.
9.1.3.7 Reliability or failure mode
Function or performance expected life, or inability to meet that expected life.
EXAMPLE Product shall have mean time between failures (MTBF) of 1 000 h.
9.1.3.8 Subsystem or component
A part of the product.
EXAMPLE Product filter is replaceable.
9.1.3.9 Material
What the product is made from.
EXAMPLE Stainless steel.
9.1.3.10 Test or regulation
Must meet or pass a test or regulatory requirement.
EXAMPLE 1 Must meet TG-53 and TG-101 regulations.
EXAMPLE 2 Perform routine regulatory analysis and reporting.
9.1.3.11 Process
Steps, jobs, and tasks the product engages.
EXAMPLE 1 Exposed areas shall be treated with corrosion resistant coating.
EXAMPLE 2 Provide management with consistent, yearly, performance trending benchmarks both internally
and externally against available industry peer groups across key operating metrics.
9.1.3.12 Cost
Monies associated with selling price, indirect expenses such as facilities, administration, and equipment,
and direct expenses associated with labour, components (purchased or internally sourced), energy,
disposal.
EXAMPLE Target price = € 17.
9.1.3.13 Manufacturing or build methods
Equipment, facilities, methodologies, and techniques concerning how the product is to be made.
EXAMPLE Sonic welding instead of adhesive.
9.1.3.14 Measurement methods
Methods, equipment, gauges, templates, and their maintenance.
EXAMPLE Must use coordinate measuring machine (CMM) on 1 m concrete base.
9.1.3.15 Quality
Quality assurance, quality control, inspection, and problem solving methods and skills.
EXAMPLE Must follow APQP (advanced product quality planning) phases.
6 © ISO 2017 – All rights reserved

9.1.3.16 Schedule
Time associated with development, build, or launch durations, milestones, and deadlines.
EXAMPLE Start of production by second quarter of 2020.
9.1.3.17 Support
Post-purchase on-site or off-site advice or supplies related to installation, troubleshooting, upgrades,
supplies, and related activities.
EXAMPLE Telephone support 24/7 in local language.
9.2 Translating VOC and VOS into customer needs
9.2.1 General
QFD project teams constrained by resources, budget, and time should focus their efforts where they
matter most to the customer. The customer, not the QFD team, should determine these priorities
whenever possible. To get accurate priorities, VOC should be translated into an information set about
which the customer has greater domain knowledge – customer needs. To derive true customer needs,
identify and separate customer from product related from the customer or stakeholder.
NOTE 1 Clear separation of needs and product can lead to more flexibility and innovation in finding
appropriate solutions for the customers and stakeholders.
NOTE 2 Some VOC and VOS are already customer needs. They do not need to be translated, but they can be
simplified to single issues, which improves the accuracy of the prioritization.
NOTE 3 Some QFD studies interchange the terms customer needs and customer benefits.
NOTE 4 Some QFD studies interchange the terms product and features.
9.2.2 Verbal translation
When the VOC or VOS is about the product, verbally translate back to the underlying need that explains
why the customer made that statement.
EXAMPLE In a visit to a supplier of brake components, a customer mentions that the assembly area is
extremely hot and humid. This VOC can be examined as follows.
a) Convert negative statement of too hot and humid into air conditioned clean room (process conditions).
b) Air conditioned room reduces perspiration contamination from workers (process failure).
c) Perspiration damages the stainless steel surface (material).
d) Of the brake cylinder (component).
e) An undamaged surface improves its corrosion resistance (durability).
f) Corrosion resistance improves the service life (reliability).
g) Reliability ensures required compressing of brake fluid (function).
h) In an emergency (customer use case), reliable compressing makes the vehicle stop smoothly (customer need).
9.2.3 Cause-to-effect diagram
Early QFD studies used a cause-to-effect diagram to show the relationship between product and needs.
[10]
Product features cause a need to be fulfilled. So, if the VOC or VOS statement is about product,
service, software, or process characteristics, then the statement is a causal factor. The diagram can
help the QFD team determine what effects result if the cause is fulfilled. Essentially, the process is a
positive cause-and-effect diagram, where proper product design produces a positive effect: a satisfied
customer need. This is the fundamental concept to translate VOC and VOS into customer needs.
NOTE 1 The traditional cause-and-effect diagram (also known as Ishikawa diagram or fishbone diagram) is
adapted in QFD to uncover the root causes of success rather than failure. It has two formats: cause-to-effect and
effect-to-cause, which is explained later in ISO 16355-5. Note that the arrows point from the causal factor to the
effects.
NOTE 2 The causal factors can also relate with each other. Understanding these relationships can improve the
translation into customer needs.
EXAMPLE In this example, a customer enters a café requesting a hot cup of coffee. Parsing the VOC into each
phrase, Figure 2 illustrates the translation of the word hot. The word hot describes the product coffee so it is a
causal factor. Then, ask the customer why they want hot coffee. The responses are the desirable effects of I am
cold and want to feel warm, I am tense and want to feel relaxed, I feel dehydrated and want to feel steamy, and I
feel rushed and want to sip slowly for a long time.
NOTE 1 It is possible to meet the customer VOC with a cup of coffee that is 99 °C. However, it would be too hot
to drink so the above benefits would be delayed. The product meets the stated VOC but fail to provide the sought-
after benefits.
NOTE 2 If the customer need is to feel warm, there are other technical solutions besides temperature,
such as alcohol (Irish coffee), spice (capsicum, curry), a squeezable cup that provides exercise, and others. By
understanding the true customer need, there are more options for the design team to consider.
NOTE 3 Additional diagrams can be made for “cup” and “coffee.”
Figure 2 — VOC/VOS translation for a café using cause-to-effect diagram
8 © ISO 2017 – All rights reserved

9.2.4 Customer voice table
Either the verbal translation or the cause-to-effect diagram can be displayed in a spreadsheet or
customer voice table. The translation process is the same; take the VOC or VOS and uncover the
underlying customer needs.
EXAMPLE 1 Table 1 is an example of a simple customer voice table for a breakfast service kiosk in an airport.
[8]
The left portion of the table captures VOC narratives from a business traveller market segment trying to decide
what to eat for breakfast and if they have enough time. First the QFD team determines if the VOC narrative is a
customer need or a product requirement. The first VOC narrative of “do you have anything more interesting than
plain bagels” (a type of bread) is a product requirement so the broken line indicates that his should be copied
to the product side of the table on the right. Variety is not a specific design requirement but rather a broader
functional requirement, it is entered into that column. Following the solid lines, the functional requirement is
translated back into the underlying benefits in the customer needs column. The logic here is that if there are
more varieties, the customer can get a taste they like, make a healthy choice, and get an appealing choice.
Table 1 — Customer voice table for airport food kiosk
EXAMPLE 2 In Table 2 from the development of a financial services customer relationship management (CRM)
system, the section of the customer voice table (CVT) for the end customer segment of interest is used to structure
the translation of VOC and VOS statements that are characteristics and capabilities, supporting functional and
[13]
non-functional, and process and organizational change requirements into customer needs. This is a critical
capability for the QFD team as it establishes a coherent solution-wide view of which key stakeholder needs are
implied by solution functions and the way the solution should deliver those functions.
Table 2 — Customer voice table for CRM information system
NOTE 1 Later in the QFD process, customers are asked to prioritize their needs. If a VOC or VOS is mistranslated,
it probably receives a low priority and is not acted upon. Should it receive a high priority, then the QFD team has
uncovered an unspoken, latent requirement with a potential for competitive differentiation.
NOTE 2 If useful, more detailed columns can be added to the right portion of the table to classify narratives
relating to components, materials, processes, and similar information categories shown in 9.2.2.
10 Structuring information sets
10.1 General
To obtain accurate, unbiased, and unambiguous prioritization and quantification, and to reduce the
effort of both customers and team members to obtain this, information should be organized into a
logical structure. Structuring should be done by members of the group that own the information set
and have greater domain knowledge. Customer needs should be structured by the customer.
10.2 Affinity diagram
10.2.1 General
When there are many customer needs, an affinity diagram can be used to manage them. The affinity
diagram allows customers to group their needs in a way that makes sense to them. This diagram is
built bottom-up so that first, the cards are grouped according to a shared affinity determined by the
customers and then descriptive header cards are created to describe the each card group’s common
1)
theme. The customer needs affinity diagram is built using the KJ™ method developed by the Japanese
anthropologist Kawakita Jiro (hence the name KJ) following these steps.
10.2.2 Steps to make an affinity diagram
The steps to create the diagram are as follows.
a) Write each customer need on a separate card.
b) Have customers silently group the cards where they make most sense.

1) KJ™ is an example of a suitable product available commercially. This information is given for the convenience of
users of this document and does not constitute an endorsement by ISO of this product.
10 © ISO 2017 – All rights reserved

c) Label each group of cards with a description of their common theme.
EXAMPLE 1 Figure 3 shows a health insurance provider example. The customer is a company employer
[3]
offering health insurance plans to its employees . One group of customer needs, such as my employees,
appreciate the benefits I provide them and keep my employees and their families healthy are grouped with the
label employee satisfaction.
Employee satisfaction:
Healthcare knowledge:
· “My employees appreciate the beneits
· “I feel good about the plan I choose”
I provide for them”
· “My costs are predictable year over
· “Keep my employees and their
year”
families healthy
· “I understand how all the plans work”
· “My employees know what they are
· “I want my employees to understand
entitled to the value of the health coverage I am
· “My employees have peace of mind”
providing for them”
Relationship with the carrier:
Business eficiency:
· “The carrier acts as my partner”
· “Attract highly qualiied new
· "I feel valued by the carrier”
employees”
· “I know I am getting the right answer
· “Save me time and effort”
when I am talking to customer service”
· “Retain my best employees”
· “My boss knows I am diligent with the
company’s money”
· “Keep my employees productive”
Figure 3 — Affinity diagram for health insurance provider
NOTE In QFD studies on internal business processes, group labels can already be established.
EXAMPLE 2 An electrical power generation utility uses the following group labels for internal operations:
a) safety — safe to use, safe for employees;
b) quality — free of errors, defects, and mistakes;
c) cost — value equals or exceeds price;
d) delivery — output received when needed;
e) public responsibility — accountable to communities served;
f) other factors commonly used in Six Sigma projects such as critical-to-quality (CTQ) or some other category
of critical-to-x (CTX).
10.3 Hierarchy diagram
10.3.1 General
The customer needs hierarchy diagram is used to address any structural issues with the customer
needs affinity diagram. This is important for finding unspoken or missing customer needs, as well as
improving the accuracy and efficiency of the prioritization process. The hierarchy diagram is used to
display and organize customer needs from very vague needs on the left to more specific, measurable
needs on the right. Measurable needs can be confirmed during product development, as well as
routinely monitored after the product goes to the customer to determine how well the actual product is
performing against the customer needs.
Information set structuring should ensure that information groups are mutually exclusive and
collectively exhaustive (MECE) to ensure no overlapping or missing elements. Overlapping or missing
elements can reduce the accuracy of later analyses such as prioritization.
10.3.2 Steps to make a hierarchy diagram
The steps to create the diagram are as follows.
a) Rotate the affinity diagram counterclockwise 90°. This makes the following steps easier.
b) Starting from the left (called the primary level), confirm that the customer needs labels have the
same level of abstraction; adjust if necessary.
c) Determine if there are any missing needs at that level of abstraction that should be added.
d) Repeat at each level to the right for the secondary and tertiary levels.
e) Review with customer, especially in business-to-business products and internal business process
projects, to validate those customer needs are agreed upon by both customers and suppliers.
NOTE Needs can later deploy to contractual requirements formally detailing process output standards
agreed upon by both parties. These are also known as specification limits or service level agreements (SLA) and
usually include specific performance measures and targets
[13]
EXAMPLE Figure 4 is from the financial services company CRM development . The hierarchy diagram
of the customer and stakeholder needs shows three levels of the hierarchy: primary, secondary, and tertiary. A
missing need from the prior customer voice table and affinity diagram analyses has been added during discussion
with the customer.
12 © ISO 2017 – All rights reserved

Primary - Operations SecondaryTertiary
1.1.1 Customer taken quickly to appropriate new
services areas
1.1.2 Customer can ind easily area where they can
express complaints
1.1 Customer Understanding
1.1.3 Customer Contacted with Service Information
Added
Relevant to them
1. Customer Interactions
1.2.1 Customer Only Has to Input Their Information
Once
1.2.2 Existing Customers recognised immediately - not
required to re-register
1.2 Customer Input/ Output
1.2.3 Customer needs service information clearly in a
way they can compare with other Co's.
2.1.1 Nature of enquiry lagged up to operator at
beginning.
2.1.2 Service description easily reconigured to follow
customer questions
2.1 Appropriate Response to
Customer
2.1.3 Company Systems Point to Services Appropriate to
that Customer
2.1.4 New Service Campaigns Easily Targetted to the
right customers.
2. Front Ofice Operations
2.2.1 Customer questionnaire pre-populated with key
info., no need to re-enter
Figure 4 — Customer needs hierarchy diagram for CRM information system (partial)
11 Prioritization
11.1 General
In order to focus where maximum benefit to customers or stakeholders is provided with minimal effort
by the QFD team, prioritization of the information set should not be neglected. Priorities should be as
accurate, unbiased, and unambiguous as possible as they can serve later QFD activities related to cost
and resource allocation. Thus, the mathematical limitations of different numerical scales should not be
ignored.
NOTE 1 Prioritization is done by the group that “owns” the information. For example, customer needs are
prioritized by the customer.
NOTE 2 The analytic hierarchy process (AHP) enhances the precision of the statistical methods of QFD by
employing absolute relative scale values with meaningful ratios that can be added, subtracted, multiplied, and
divided. AHP also gives customers a forced-choice, paired comparison model that yields more accurate results
because they cannot say “everything is important.” Finally, when applied to a hierarchy as explained below, the
prioritization process is broken into smaller groups which is less fatiguing than presenting customers with a
single, long list of needs to rate on an ordinal scale.
NOTE 3 Other statistical methods can be applied to prioritize customer needs, such as multiple correspondence
analysis.
EXAMPLE 1 An example of an absolute ratio scale is distance. 2 km is twice the distance of 1 km. Thus, ratio
scales values can be multiplied, as well as other mathematical functions.
NOTE 4 Ordinal scale values do not contain sufficient information to perform these mathematical functions
properly. There are several problems: 1) the ratios between the levels are not equal; the effort to go from 1 to 2 is
100 %, while the effort to go from 4 to 5 is only 25 % (in ratio scale, the ratios between the scale values are closer
to equal as shown in Figure 5), 2) because of the inequality or ratios, ordinal scales tend to bias towards the
higher values. Thus, ordinal scale values cannot be divided, nor can most other mathematical functions. Ordinal
numbers do support mode and median, which is why early QFD studies recommended using response mode
(most frequent count) rather than mean (average) response.
Figure 5 — Equality of ratio: ratio scale vs ordinal scale
EXAMPLE 2 An example
...