Quality Function Deployment (QFD) is a design approach that maintains in focus what is most important to customers and stakeholders, thereby assuring quality and reducing project time. We can apply QFD to the development of products, parts, materials, services, events, software and websites – effectively any type of development that has a definable customer.
In this post I will explain why I believe the established QFD models are good, but not yet perfect. In later parts of the post, I will suggest ideas for QFD 2.0.
Standard ISO 16355-1:2015 on “General principles and perspectives of Quality Function Deployment” does not provide any ready-made model for implementing QFD. It defines a generic design and development process flow and describes how the elements of QFD fits within the stages of this generic flow. Annex A to the standard informs of example tools and summarily discusses a few recognised QFD model approaches.
Product design and development flow, within which the QFD approach is used. (adapted from ISO 16355-1, Clause 5.2.2)
It is important to underline that although the common QFD approaches are often depicted to resemble a design and development process, they are not.
The QFD approach is a model for the thinking and the collaboration that goes into identifying, prioritising and resolving design problems. The QFD approach therefore integrates into all different kinds of design and development processes.
QFD doesn’t do anything that cannot be done in a skilled, objective mental process. So why use it?
- Mental process skills are improved by learning and using QFD.
- QFD supports objectivity and cohesion, within a collaborating team of mixed minds.
- Systemised working is proven to yield better results (where dependence on artistic freedom is merely a myth).
- QFD generates and preserves factual decision information.
I advocate QFD as an essential learning tool, for all fields of products and services development. Design students should experience walking through a design process using QFD. They will automatically use and benefit from its principles in future works, even if they don’t use a standard model.
The original 4-phase model
The first reported use of QFD, by Yoji Akao with others in Japan, dates to the 1970’s and describes a ‘comprehensive’ matrix of matrices model applied to a large ship design. Don Clausing et al presented a truncated 4-phase approach in the 1980’s. Originally tailored for the automotive parts industry, Clausing’s 4-phase model has since evolved into the most widely applied approach to QFD. Judging by an internet image search, the 4-phase model is used in about 95% of all QFD projects today.
The 4-phase QFD model [Clausing] is a truncated variant of the
original ‘comprehensive’ approach [Akao].
Clausing’s 4-phase ‘flow diagram’ shown here should be read as a generalised approach. It is not a strictly delimited, sequential, process. The dotted arrows between the 4 phases infers a transfer of requirements information. The model demonstrates how the final phase output ‘plan’ traces all the way back to the original customer input requirements.
When designing a part feature, we must of course give thought to how a chosen solution can be reliably produced. We will apply Design For Manufacturing (DFM) principles and judge its fit within our existing production systems. By time the parts design phase is complete, we will already know how to produce the design. The process planning phase is more about defining and refining the details, including any process equipment, while keeping in focus the importance that tracks back to the original Voice of Customer. Both the process planning and the quality control phases may well find design optimisation potential, which will benefit from an iteration back to the initial part design specification for adjustment. The whole design process thereby has elements of both concurrency and iterations, which are not well illustrated by the model.
The House of Quality (HoQ)
The HoQ is simultaneously a requirements transfer tool and a container for the phase specific planning activities. The HoQ does two things:
First, it records the translation of a set of input requirements into a corresponding set of derived output requirements, helping us to visualise if anything in the translation is missing or off-balance. Note, the translation itself is performed outside the HoQ.
Second, it then procedurally transfers the importance of characteristics in the input requirements into the characteristics in the output requirements, establishing a prioritised development plan. The plan is effectively a specification for what to do next.
The House of Quality
The ‘what context’ defines the direction the organisation wants and needs to take, with regards to meeting the customer requirements.
The ‘how context’ defines the degree of ambition, or necessary trade-offs, in term of workload and technical creation to be achieved.
The business case, sponsoring the QFD project with time and money, will normally have predefined the required degree of ambition, in terms of the minimum value creation that is required and maximum available resources. In case of any doubt, it would normally be a good idea to test the contexts assessment with the project sponsor, to ensure that it meets the original business case.
The context weightings effectively enables us matching our development plan to our ‘difficulty budget’ – i.e. be as radically new or as conservatively static as it has to be. There clearly is a difference in the amount of difficulty that can be accepted by a budget of 1 month and $30k, compared to a budget of 6 months and $300k for example. In case of the former, we would need to realistically moderate the amount of ambition we set ourselves and focus our efforts wisely.
In the highlighted column in the above example HoQ, the design of a “Strong carrying member” attracts 10% of the total technical importance, from a customer perspective. The development should target a solution that matches this technical importance rating. Because of the influencing contexts, however, which identifies that we are already competitively strong in both our commercial and technical solutions that pre-exist, we can downgrade the amount of focus we give to the design requirement for a “Strong carrying member”. You will note the development importance is downgraded to 4%, which we must consider to be sufficient to achieve the technical target.
On the other hand, under the design requirement for an “Ergonomic shape” we identify that a competitor has a far superior solution and there is also potential for a design bottleneck. The context weighting has had the effect of defining a development importance of 26%, as necessary to assure that we can meet the 7% technical target importance. The HoQ with context weightings thereby helps us getting the development priorities right.
You can download QFD and HoQ resources here.
Current QFD models are not perfect
The depiction of the Clausing model is not always helpful. Firstly, it can infer that QFD is solely about building a HoQ, which is not true. We do not develop the product toward a HoQ, but instead the HoQ establishes the prioritised plan for the development works to follow. The team-based approach promises to eliminate an organisations ‘functional over-the-wall’, or silo mentality to product development. The 4-phase model risks instead creating a ‘process over-the-wall’, because the model is depicted to resemble distinct process steps – one where the parts design is completed and fixed, before we start thinking about the process design. This is of course not how real projects work. Lastly, the models and standard for QFD lack clarity about its interface to the wider design management system.
Remember: QFD is still evolving; practitioners are still learners; experts should be doubted.
 Akao, Y., “Quality Function Deployment – Integrating customer requirements into product design”, Productivity Press, 1990.
 Clausing, D.P., Pugh, S., “Enhanced quality function deployment”, Design and Productivity Conference, Honolulu, 6-8 February, 1991.