|
|
Quality Function Deployment (QFD) is
a systematic process for motivating a business to focus on its customers.
It is used by cross-functional teams to identify and resolve issues
involved in providing products, processes, services and strategies which
will more than satisfy their customers. A prerequisite to QFD is Market
Research. This is the process of understanding what the customer wants,
how important these benefits are, and how well different providers of
products that address these benefits are perceived to perform. This is a
prerequisite to QFD because it is impossible to consistently provide
products which will attract customers unless you have a very good
understanding of what they want.
Why use QFD?
Once a team has identified the customers'
wants, QFD is used for two fundamental reasons:
What are some approaches to
QFD?
There are
many different approaches to QFD:
There are many other approaches. In fact, the flavor of QFD is often what differentiates one consultant from another. However, almost everyone agrees that for QFD to be successfully implemented within an organization, it must be adapted to the particular situation surrounding its use. QFD/CAPTURE was designed to support all of these approaches and more.
The basic tools of QFD are Project
Roadmaps, Documents, Lists and Matrices. A Project Roadmap defines the
flow of data through a QFD project. Documents record background
information for a project. A Matrix is simply a format for showing the
relationships between two or more Lists. Lists form the input rows and
output columns of the Matrices. Examples of Lists include: User Benefits,
Measures, Basic Expectations, Functions, and Alternative Concepts. Lists
generally have other Related Data associated with them. For example, the
priorities and perceived performance ratings resulting from Market
Research would be associated with the List of Benefits. Importance values
would also be associated with Measures and Functions. Matrices are used to
relate two or more Lists to each other, thus deploying or transferring the
importance from the input lists to the output lists. For example, a common
Matrix relates Measures to User Benefits. Another Matrix could be used to
relate Measures to both User Benefits and Basic Expectations. Matrices are
a flexible tool which can be configured to the particular needs of each
project.
Capturing Market
Data
There are many different ways to identify the Customers of a product or service. A commonly used approach is to ask the team "Who must be satisfied with the product in order for the product to be considered successful?" Typically, a team will identify the following customer groups:
A fundamental principle of QFD is to determine directly from the customer what they would like a particular product or service to do. There are many different approaches to achieve this goal. They include:
Interviews are useful because they
allow you to effectively probe for detail. Focus groups are productive
because they allow you to develop a lot of creative ideas by having the
participants build upon one another's comments. In-context customer visits
allow team members to actually observe how customers use existing products
or perform existing functions and can lead to a dramatically improved
understanding of what the customer really needs. All of these approaches
will yield the basis for a list of what the customer is seeking. This list
can then be entered into QFD/CAPTURE in the form of a Requirements
List.
QFD, as a process, yields the most effective results when the team focuses on the requirements which are most critical to the success of the product they are developing. Customers can help this process by telling the team which requirements are the most important to them when they are considering the purchase of a product in which several competing products exist. Importance to the Customer is often gathered through "forced choice" surveys, which requires the person being surveyed to identify the relative importance of each of the requirements. There are many different methods which yield varied quality of results. Teams are encouraged to investigate Conjoint Analysis, The Analytical Hierarchy Process, and Forced Choice Prioritization methods. It is recommended that a reputable Market Research firm with experience in doing quantitative research for QFD be consulted. Importance values are captured within QFD/CAPTURE by defining a column of Related Data in the List Window.
A QFD team can learn a lot by asking customers, "How well do existing products satisfy these requirements?" Ideally, a customer would be familiar with multiple providers of competitive products. The team could then look at these Perceived Performance Ratings and try to determine why certain products were perceived to do well while other products were perceived to perform poorly. This information leads to an increased understanding of what would attract customers to the product currently being designed. Teams are encouraged to consult with a reputable Market Research firm which is familiar with the unique needs of the QFD process in order to gather this information. Perceived Performance values are captured within QFD/CAPTURE by defining a column of Related Data to contain the performance ratings for each product being examined. This is done within the appropriate List Window.
Customer Satisfaction Data is often
used in place of Perceived Performance Data and is captured within
QFD/CAPTURE in the same way. You should be aware of a common trap. If you
are using existing customer satisfaction data, be sure that the
requirements used to generate the Customer Satisfaction Data are good
requirements from the QFD perspective and that the ratings indicate buying
preference. Otherwise, the data may not produce useful results for the QFD
project.
Prioritizing
Requirements
Requirements are not always prioritized strictly based upon the importance which the Customers attach to each requirement. Often, the team wants to adjust the priorities of the requirements to account for the amount of work required to improve the customers' perceptions. Other teams will incorporate a factor to indicate where the company thinks the market is headed. Still other teams want to perform Gap Analysis and add additional importance to those requirements where there is a large gap between the importance that a customer attaches to a requirement and the level of satisfaction which most customers experience relative to that requirement. All of these different methods of Prioritization involve defining calculations in the Related Data associated with a List of Requirements. The following examples will illustrate these prioritization methods. If the team wants to incorporate an indication of the amount of effort required to improve a product's performance in the eyes of the customer, they might set up Related Data columns as follows:
The Importance to the Customer column would contain the importance ratings as given by the customers. The data in the Our Current Product, Competitor One, and Competitor Two columns would contain Perceived Performance Ratings given by the customers which indicate how well they think the named products perform against the listed requirements. The data in the Our Future Product column is set by the team to indicate their positioning strategy. The change from Our Current Product to Our Future Product is an indication of the amount of work required to change the level of Perceived Performance and is generally calculated and stored as the Improvement Factor. Two approaches to this calculation are supported in QFD/CAPTURE.
The Overall Importance column contains the product of the Importance to the Customer and the Improvement Factor. Its values indicate where the team should focus attention in order to address what is important to the customer and where they have to do a lot of work. The Percent Importance column simply contains the Overall Importance values translated into percentage values.
If the team wanted to include its
guess as to what would be more important in the future, it could
incorporate an Importance Growth Factor into the Related Data
described above. The values in the Importance Growth Factor would
be the percent change in the importance which is anticipated in the time
frame of the project. For example, an Importance Growth Factor of
1.3 would indicate that the team expects the importance of that
requirement to increase 30 percent in the time frame of the project. The
Overall Importance column would now be set up to be the product
of Importance to the Customer, Improvement Factor, and
the Importance Growth Factor.
If the team wanted to use Gap Analysis as a means of prioritizing
the requirements, they might set up the Related Data columns as
follows:
Product Positioning Strategy is generally defined after considering the importance of each requirement relative to the others on the list. It also accounts for the perceived performance ratings given by the customer. The strategy ratings are generally captured in a Related Data column called Future Product. The rationale for setting strategy generally follows these guidelines:
When prioritizing the requirements, some teams want to include a factor to indicate that additional importance should be given to particular requirements. In a way, the importance of these requirements is underestimated by Customers because they do not understand the benefit which would be provided if the requirement were satisfied. The factor used to indicate this additional importance is known as the Sales Factor. Sales Factors or Sales Points are defined in a column of Related Data associated with a list and act as multipliers in calculating the overall importance of each requirement. The traditional ratings are:
The information used to prioritize the Requirements is some of the most interesting and important information collected during the QFD process. The results of the QFD project start to become apparent once the team begins sorting the data to look at it from many different perspectives. The following are just some of the issues which can be answered by closely examining the prioritization data:
Measuring the Design
Often, Customer Requirements are very subjective statements of the benefits which a Customer is seeking from a product. Though the team members may think they are in near total agreement about the meaning of a particular statement, the individuals on a team are often interpreting the statements in very different ways. This difference of interpretation often does not become evident until the team attempts to define ways to satisfy the Requirements. The process of translating Customer Requirements into Design Measures is a way to force the team to define, using measurable and actionable statements, exactly what each Requirement means in the language of the organization. For example, let's say that a Customer Requirement for a software package is "Is easy to use". The programmers would be left to their own interpretation as to whether their software would really satisfy their Customers. On the other hand, through the QFD process, a team might define the following Measures for "Is easy to use":
There are two main approaches to defining Measures. The most common approach is to brainstorm all of the possible Measures while reviewing the list of Requirements. This comprehensive list is then captured in a QFD/CAPTURE List Window. Relationships between the Measures and the Requirements are then defined using a Spreadsheet view in the Matrix Window Another approach, which is starting to be widely used, is to make use of a Tree analogy. A Requirement is treated as the trunk of a tree. The team then Brainstorms the Measures needed to address that particular Requirement. The Measures are recorded as Branches of the tree. For easier reading, the Tree is generally drawn sideways. QFD/CAPTURE supports this method of definition via the Tree view in the Matrix Window.
It should be noted that Measures are only one type of information which can be related to Customer Requirements. Other types of information can also be recorded within Lists and be effectively related to Requirements. Some examples include:
In general, a Matrix can be thought of as the set of relationships between an Input List and an Output List. Customer Requirements are just one of many types of Input Lists. Any set of data for which the team would like to understand the relationship with Customer Requirements would be a valid Output List.
Defining Relationships
Relationships between Lists indicate how the two lists are related to each other. They are generally used to prioritize one List based upon the priorities of another list. Relationships can be defined by answering a particular question for each cell in a Matrix. For example, the Relationships between Customer Requirements and Design Measures might be defined by asking "To what degree does this Measure predict the Customer's Satisfaction with this Requirement?" By asking this same question consistently for each Measure and Requirement combination, a set of Relationships will be defined in the Matrix which will help to determine which Measures are most important to control in order to achieve a desired level of Customer Satisfaction. Another question which can be asked in order to define Relationships is "What percent of this Requirement is handled by this Design Measure? The Relationships defined using this question would result in the highest priority being assigned to the Measures which control most of the functionality. These may not be the same as the Measures defined in order to predict Customer Satisfaction. Given these examples, you can see that it is critical that a team understand what question they are trying to answer before they start defining Relationships. It is also critical that they use the same question consistently. By doing so, the team will be able to prioritize the Output List accurately.
Relationships are defined within the Matrix Window of QFD/CAPTURE. There are two different methods of defining the Relationships. The Spreadsheet View provides a familiar format for entering the relationship values. The Tree View provides a snapshot of the Relationship values for each Input row, and makes it easier to assess each Relationship's value relative to the other Relationships. The Spreadsheet View presents the Lists being related in a Spreadsheet format. The entries in the Input Lists form the row headings and the entries in the Output Lists form the column headings. The cells within the spreadsheet contain the relationships between the Input and Output entries. The Tree View presents all of the Output List Entries which are related to the currently selected Input List Entry using a Tree structure. This allows the team to consider the relative strength of the Relationships. It is equivalent to defining an entire row of relationships across a Matrix.
The scales used to define the
relationships can have a significant impact on the Prioritization of the
Output List Entries. The main consideration is the tradeoff between the
number of levels in a scale, the speed of relationship definition, and the
relative accuracy of the resulting Prioritization. In general, the more
levels in the scale, the more accurate the relative prioritization. The
different values of the scale allow the team to indicate the levels of
relationships that the Output List Entries have with the Input List
Entries. For example, the team may choose to use relationships with values
of 1 through 10. Using this scale a value of 6 would indicate that one
Output List Entry is twice as important to the satisfaction of an Input
List Entry as an Output List Entry with a value of 3. Relationship
definition usually goes much faster if the team limits their choices of
Relationship values to just a few. Standard QFD practice usually supports
the values 1, 3, and 9. This Standard QFD Scale accentuates the Strong
Relationships (value of 9). Output List Entries with several Strong
Relationships to Input List Entries will tend to be given a higher level
of priority than Output List Entries related to many Input List Entries
with either moderate or weak values. Other common scales include 1, 2, 3
and 1, 3, 5. With greater frequency, teams are defining relationships
using advanced methods such as the Analytic Hierarchy Process to establish
scales with an infinite number of levels. The resulting relationship
values usually represent the percent contribution of each Output List
Entry to the selected Input List Entry. QFD/CAPTURE supports all of these
different scales. Each time a new matrix is created, the user is given the
opportunity to specify which of the standard scales will be used for the
relationships. You may define your own unique scales as well. The software
will also allow the team to define relationship values as real numbers
that represent percentages.
Identifying Tradeoffs
The tradeoffs, located in the "Roof" of the House of Quality, indicate the synergistic or detrimental impacts of changes in the Design Measures. They are used to identify critical compromises in the design. Since these compromises are likely to be encountered sooner or later, they may as well be examined as part of the QFD effort so that any required design changes are as inexpensive as possible.
As with other matrices, the team should agree upon the question that they will ask in order to define the Relationships of this Matrix. A common question used is "If we improve our performance against this Measure, what is the impact on this other Measure? The team will determine if improving performance of one Measure helps or hurts the product's performance against another Measure. Generally, positive and negative values are used to indicate the positive or negative impact. The Tradeoffs Scale provided by QFD/CAPTURE can be used as a scale for Relationships defined within this Matrix. QFD/CAPTURE allows a team to capture the tradeoffs it identifies. A matrix is created to capture the tradeoff information. One list forms both the input and the output of the matrix.
If a tradeoff is identified, there is
usually some Action which is required in order to reduce the impact or
work around the potential compromise. These Actions can be documented in
several ways. One approach is to create a document within QFD/CAPTURE and
record each action as a paragraph within the document. Another approach
would be to define a List of Actions. This would give the team the
opportunity to relate Actions with the Customer Requirements, Design
Measures, or any other List defined in the project. This approach would
support prioritization of the Actions based upon their affect on the
satisfaction of the related Input List.
Benchmarking
One of the prime reasons for using QFD is to develop a product or service which will excite the customer and get him/her to purchase your product. When a team captures the customer's perceptions of how well different products perform in the marketplace, the team can better understand what is driving the purchase decision. They are able to determine what the market likes and dislikes. However, they are really still dealing with Customer Perceptions and not actual performance. They have not necessarily learned what they, as a team, have to do to create the desired level of Perceived Performance. Benchmarking your own, and others', products against the Design Measures which the team has established helps to define the level of Real Performance required to produce the desired level of Perceived Performance. It also helps you to answer the following questions:
Benchmarking is a relatively
expensiveand time consuming process in most industries. Therefore, it is
recommended practice to Benchmark only against the critical Design
Measures. Criticality is defined by how important a particular Measure is
to the success of the product and whether there are special circumstances
impacting a particular Measure. A special circumstance might include
whether a particular Measure is new or complex. Typically, a team might
only Benchmark 50 percent of the Design Measures. Sorting the List of
Design Measures based upon their importance values is a good way to
identify which Measures to Benchmark.
Generally, teams Benchmark the same products or services for which they captured performance perceptions. In this way, they can try to correlate Actual Performance with the Perceived Performance. A good policy is to Benchmark products across the whole spectrum of performance. In this way, it becomes much clearer what level of performance is perceived to be inadequate, what level is acceptable, and what level of performance currently gets customers excited about a product. Benchmarking all of the competitive products is not required; just check representative products.
There are two schools of thought
relative to capturing Benchmark Results. The first suggests that the team
capture the raw Benchmark data directly and associate that data with the
appropriate Measure. The other suggests that the team translate the raw
Benchmark data into the same scale as was used to capture the perceived
performance ratings. Capturing the raw data and using it directly through
the process tends to make it easier to understand exactly how well a
product has to perform in order to achieve a desired level of customer
satisfaction. However, the raw data sometimes implies too much precision
for the process. For example, if the team were Benchmarking "Number of
Commands Required to Perform the Desired Functions" as a way of predicting
whether a software package would be perceived to be "Is easy to use", they
could easily get caught up in counting precise numbers when, in reality,
"Less than 10", "10 to 20", and "More than 20" might be sufficiently
accurate for the purposes of the team. On the other hand, translating the
raw Benchmark data into the same rating scale as was used to capture
perceived performances forces the team to repeatedly translate those
ratings back into their original values. This tends to make nuances in the
data disappear and be lost from consideration. However, since only numeric
rating data is captured with this approach, QFD/CAPTURE could graph this
data. QFD/CAPTURE supports both of these approaches. The general process
is to define Related Data columns for the list whose entries are to be
Benchmarked. Each column would represent a particular product. If the raw
data is to be captured, the team would configure the Related Data columns
to contain text so that they could enter any type of data and units which
are appropriate. If they instead want to capture the ratings, they would
configure the columns to contain numbers only.
Setting Target Values
The final goal of many QFD projects is to set the Target Values for the Design Measures. This step occurs when the data gathered throughout the process is brought together and final decisions are made to answer the question "What are we really going to do (with respect to this product or service)?" Setting Target Values should be relatively easy because:
Taking into account all of this
information, the team decides upon the Targets which they will shoot for.
Normally at this point, the team would not decide how they are going to
achieve the Target Values. They are just stating, "we know that we have to
achieve this level of performance if we are going to be perceived the way
in which we want to be perceived." Deciding on the implementation approach
will generally occur during the Conceptualization process. QFD/CAPTURE
supports setting Targets for a List through the Related Data columns
associated with that List. Generally, a separate column is defined for
each release which is being planned. For example, if a new product were
going to be released in 1996 and followed up with enhancements in 1997 and
1998, the team would create a separate Related Data column for each year.
This would allow the team to show the progression of product performance
over the life of the Product. This implies a long term planning
perspective rather than just a short term, get-it-out-the-door,
perspective. Since Target data is generally textual, these columns would
be configured to display Text (as opposed to just numeric data).
Design Concepts
When a team is assigned to develop a product or service, there is a strong inclination to quickly lock onto a particular approach and not seriously consider any others. These approaches, or Design Concepts, define the ways the team could implement the product or service. As the team develops the detailed design of the product, much of the time is spent modifying and refining the concept. Not all concepts are equally good. Some concepts are extremely sensitive to the environment in which they have to operate and will only demonstrate the ability to perform as required when very specific conditions prevail. Other concepts exhibit a robustness that allows them to operate under a wide variety of conditions. A team should seek robust concepts as a way of ensuring adequate performance of the product under all conditions in which it will operate. If a product is implemented using a concept that is not robust, it is vulnerable to attack, in the marketing sense, from a product which is more robust and efficient. The key to eliminating this vulnerability is to evaluate alternative concepts against good, comprehensive Measures in order to determine which concept will be able to provide the desired Benefits with the minimum effort.
There are several different
approaches to identifying and defining Alternative Concepts. Each approach
should be considered to ensure that you have examined a wide enough set of
Alternatives. Competitors are a great source of ideas for Alternative
Concepts. Most products, which currently address the same set of benefits
as your product, have probably taken slightly different design approaches.
The team should examine each approach to determine whether the approach
merits emulation or can be improved upon. When the team asks its customers
what they want in a product or service, the customers often respond in
terms of solutions. While most of these solutions will be fairly obvious,
there will probably be a few that you never considered. These few acorns
can spawn some very good ideas. After all, the customers are working with
the product on a frequent basis in the environment where the product
really has to perform. Management's ideas also need honest consideration.
If management's ideas are not considered, in good faith, the team is
setting itself up for a difficult time in getting their chosen concept
approved. The team itself should also spend some time dedicated to
brainstorming some creative alternative approaches to providing the
Benefits. One proven method is to assign each team member to identify one
approach which they will champion during team discussions. In this way,
the team is motivated to understand the ideas which they have brainstormed
to a level of detail which makes it feasible to compare the alternatives.
The last approach to identifying and developing Alternative Concepts is
the detailed analysis of the Design Measures to be used as selection
criteria. The team evaluates how it could achieve the required Target
Value for each Measure. A table is created with different design Concepts
forming the columns and the approaches for each Measure forming the rows.
For example, if we were identifying Alternative Concepts for a new watch,
we might generate the following table:
| Selection Criterion | Target Value | Concept 1 | Concept 2 | Concept 3 |
| Number and Type of desired Alarms | 3 | Beep, Vibrate, Display Flash | Beep, Display Flash, Chime | Chime, Vibrate, Voice |
| Duration of Illumination | During all operations with two second decay | Slow decay LED Light | Backlight with wait circuit | Florescent watch face |
| Time to complete Standard Operations Suite | Maximum of 4 seconds | Single button menu | Dual button menu | Three button menu |
The Concept that provides the required level of performance, most reliably and at the lowest cost is, by definition, the Best Concept. The Best Concept is identified by evaluating the Alternative Concepts against the objective Measures. A widely accepted process for selecting the Best Concept, is a modification of the Selection Process developed by Stuart Pugh. This matrix oriented process uses the Measures as Selection Criteria against which the Alternative Concepts are evaluated. The team selects a Baseline Concept. A relative comparison is made between the Baseline and the other Concepts for each of the Selection Criteria. If the Alternative Concept rates better than the Baseline, a Plus sign is entered into the cell at the intersection of the Measure's row and the Concept's column. Whereas, a Minus sign is entered, for those Alternative Concepts that rate worse than the Baseline. A Star is entered to indicate the two concepts have equivalent performance. After the relative performance has been evaluated, the overall performance of the Alternative Concepts is calculated by using a weighted sum of the relationships. The relationships are weighted by the importance of the Selection Criteria. Often, multiple iterations of this process are performed using different Baseline Concepts. An alternative way to select a Baseline is to identify the strong points of two or more concepts and create a new Super Concept. This can be a very powerful process! QFD/CAPTURE supports the Concept Selection symbol set and calculations. Select this symbol set when you create a new concept selection Matrix.
Defining Actions
One of the most common problems
encountered by QFD teams is that they do not know what to do with the
results of a QFD study. This is largely because they did not know what
they wanted the study to do for them to begin with. To avoid this problem,
it is wise to define up-front exactly what the team wants to accomplish
with the QFD project. For example, a perfectly valid result is "to develop
a comprehensive Product Specification and to select the Product Concept
which would be most efficiently implemented." If this were the objective
of the team, then the appropriate Action is to develop a detailed design
using the Product Specification and Concept as a guide. A more rigorous
approach would be to answer the question "What actions do we need to take
to achieve the targets that we have set in order to satisfy our
customers?" In QFD terms, the Measures and their Targets can form the
Input List to an Actions Matrix with the List of Actions forming the
Output List. By defining the Relationships in this Matrix, the team is
likely to identify all of the Actions required. The names of the people
who are responsible to carry out each action can also be recorded. In
addition to the Actions needed to achieve Target Values, there is a whole
class of Actions which deal with gathering information to ensure good
decision-making during the QFD project. For example, if a team is working
with Design Tradeoffs, it is quite common to find negative relationships
between Measures. Since a Negative Relationship indicates compromise, an
Action should be defined immediately that involves someone from the team
investigating the relationship and how the team might get around it.
Similarly, when the team is involved in Benchmarking the competition,
someone on the team is usually assigned to gather the specific information
the team is interested in. This whole class of Actions can be captured as
an Actions Document within QFD/CAPTURE.