Modular Function Deployment® Concepts: QFD

The Generation of Modular Product Architecture Deploys a Pragmatic Version of Quality Function Deployment

by Fredrik Börjesson and Scott Jiran

Download pdf

Discuss article on LinkedIn

Quality Function Deployment is a broadly used technique

Quality Function Deployment (QFD) originated in Japan. In 1988, John R. Hauser and Don Clausing published an article on QFD in Harvard Business Review that created great interest outside of Japan. The article, titled “House of Quality”, presented QFD using the example of a car door. Since then, there has been tremendous research interest in QFD. A literature review (Chan and Wu) published in 2002 lists more than 650 references to QFD-related studies. QFD continues to be the focus of research, and it is being deployed to guide the development of products around the world.

In all the applications of QFD, the primary objective is to link measurable properties of a product to the specific experiences of customers when using the product. Modular Function Deployment (MFD®), Modular Managements process to generate Modular Product Architecture, is no exception. There are, however, several differences between the QFD used in MFD and the QFD used in House of Quality (HOQ). The purpose of this article is to highlight those differences and explain the reason behind them.

Observable differences between HOQ and MFD

Figure 1 shows both the HOQ from the Hauser and Clausing article and QFD as it is deployed in MFD. HOQ is in the upper half of the graphic and the lower half is how it appears in MFD. Right away, we make three major observations:

  • The benchmarking data is mostly gone.
  • The checkboxes and crosses have been replaced with circles.
  • The triangular “roof” is missing.

In addition to these three major points, there are some minor differences. The term Customer Attribute in HOQ has been replaced with Customer Value in MFD. Hauser and Clausing describe Customer Attributes as “phrases customers use to describe products and product characteristics.” The term Customer Value within MFD narrows this definition to focus on statements that describe the customer’s desired experience.

The term “Engineering Characteristics” has also been replaced with “Product Properties,” but they have similar meaning in both applications. Also, the scale used to gauge the relative importance is different. The example HOQ has numbers from 2 to 7 whereas MFD uses numbers from 1 to 5.

Practical and theory-based differences between HOQ and MFD

Lack of Benchmarking Data

This is a practical difference between HOQ and MFD. The activity of data gathering for HOQ can be time-consuming. Although benchmarking customer perceptions and objective product performance most certainly is a useful activity, it can be separated from the initial work of generating Modular Product Architecture. This, in turn, allows the team to make progress more quickly.

As concurrent benchmarking activities generate new insights, the team can always go back and integrate these into the QFD. MFD is inherently iterative, so going back and making adjustments to previously scored matrices is not a failure – it is a natural consequence of team learnings.

Checkboxes or Circles

This is another practical difference. The use of circles that have been filled in accordance with the strength of the relation allows the user to quickly spot groupings of strong relations. That is more difficult with checkmarks, crosses, or other symbols frequently used in HOQ.

Unlike HOQ, MFD does not have standard symbols for negative relations in the QFD. There are two ways you can think about this.

  • Your Product Properties are not ideal. If a single Product Property has both positive and negative relations to (at least two different) Customer Values, perhaps you can replace this single Property with two or more Properties that do not display this characteristic. Often, that is hard and you need to work through the details in the selection of the technical concepts that will be used in the product.
  • Allow the relation to be negative for the time being, and only use the QFD to describe the absolute magnitude of the relation between Product Properties and Customer Values. This implies that during module formation, the direction of change is ignored, so any performance trade-offs have to be addressed during the phase when module variants are designed or final products are configured. Returning to the car door example, this could imply you need two door designs, a standard hinged door and a motorized sliding door.

Roof Is Missing

The absence of a roof is for theoretical and practical reasons. The theoretical reasons are related to the way MFD deals with conflicting requirements in the subsequent stages of the process. The practical reasons are related to workload and the focus of developing Modular Product Architecture.

First, let us recapitulate why HOQ has a roof. The roof is used to relate pairs of Engineering Characteristics (ECs) by saying whether they are mutually reinforcing or in conflict with one another. For each EC, the House of Quality indicates the desired direction of change. The first EC in Figure 1 is called Energy to close door. To make it easy to close the door, we want that energy to be as low as possible, so the desired direction is negative. Consequently, Energy to close door has a medium negative with Door seal resistance, the first EC in the group concerned with Sealing-Insulation. The desired direction is positive. More resistance is better, because it helps keep rain out of the car.

When there is a conflict, there are at least two ways to go about solving it. The first option is to find a sweet spot. In this case, the sweet spot would be an amount of energy that is low enough that most people manage to close the door, yet high enough not to cause issues rain leaking through the door seal. However, this assumes those two ranges overlap and that there is a sweet spot between them. But, what if there isn’t a sweet spot? HOQ does not really offer a solution.

MFD addresses this conflict outside of the QFD when technical concepts are being selected to fit within the framework of the Modular Product Architecture. For car doors, there could be multiple gasket designs and motorized doors that resolve the engineering conflict. The selection of the final concept is based on the disaggregation and analysis of the function and the role it will play within the system of modules.

On the practical side of HOQ, scoring a large QFD involves hours and hours of work, often in the form of a series of team sessions. When the QFD is finally done, imagine the (unhappy) surprise when the team members learn there is another matrix that needs to be scored, called the roof. To make things worse, the size of the roof grows with the square of the number of ECs. There also needs to be a constructive and creative dialogue about ways of breaking the most important trade-offs. But who is creative after hours and hours of cumbersome scoring? Often, the work just tapers off, and the roof is never completed.

MFD offers an approach to QFD that quickly leads to product decisions  

As we have seen, there are many differences between how QFD is deployed within HOQ and MFD. By removing many of the non-core features of QFD from the HOQ and incorporating them elsewhere in the product planning process, MFD streamlines the effort and generates more useful results.  Project resources and time is limited, so the effort has to be concentrated on the key elements, which is the complete list of Customer Values, the list of Product Properties and the relation between these two sets of information.

The cumbersome trade-offs described in the roof of HOQ are addressed in MFD by disaggregating the constituent Technical Solutions used within the product and using concept selection tools to explore other solutions where these trade-offs can be broken. Ultimately, it groups Technical Solutions into modules that concentrate related functions into building-blocks with standardized interfaces.

References and Further Reading

Hauser, J. R. , Clausing, D. (1988) The House of Quality. The Harvard Business Review, May-June, No. 3, pp. 63-73
This HBR article sparked great interest in QFD. The upper portion of Figure 1 is taken from this article.

Chan, L.-K. , Wu, M.-L. (2002) Quality function deployment: A literature review. European Journal of Operational Research 143:463–497
The authors have collected and categorized over 650 references.

Carnevalli, J. A. , Miguel, P. A. C. (2008) Review, analysis and classification of the literature on QFD - Types of research, difficulties and benefits. Int. J. Production Economics 114:737-754, DOI 10.1016/j.ijpe.2008.03.006
A more recent review of QFD literature can be found in this paper with 150 references.

Cohen, L.  (1995) Quality function deployment : how to make QFD work for you. Addison-Wesley Publishing Company, Reading, Massachusetts, ISBN 0-201-63330-2
A great tutorial on the use of QFD with tons of practical advice to help you get “unstuck”.

About the Authors

Fredrik Börjesson is Vice President of Technology at Modular Management where he directs the research into new techniques for developing Modular Product Architecture.  He has worked in design and engineering at detail, system and conceptual levels. He has worked in telecommunications and as a consultant with the Boston Consulting Group. Fredrik has a Master of Science and Licentiate in Mechanical Engineering from the Royal Institute of Technology, Stockholm, Sweden and a Master of Business from the Stockholm School of Economic.

Scott Jiran is a Senior Consultant at Modular Management specializing in market and product strategy. He has worked in vehicle systems engineering, product management and market management. Scott develops voice-of-customer and customer segmentation methodology, and he helps clients to develop market-based product strategies based on Modular Product Architecture. Scott has a Master of Science in Mechanical Engineering from the University of Washington-Seattle and an M.B.A. from the University of Wisconsin-Madison.

Download pdf

Discuss article on LinkedIn