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 first post I will explain why I believe the established QFD models are good, but not yet perfect.
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.
Generic product design and development flow, within which the QFD approach is used (adapted from ISO 16355-1, Clause 5.2.2).
Example QFD models and their suggested areas of application, in respect of project complexity (deducted from ISO 16355-1, Annex A). The 4-phase approach covers the majority centre range.
It is important to underline that although the common QFD models 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 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, compared to an unplanned approach.
- 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[1]. Don Clausing et al presented a truncated 4-phase approach in the 1980’s[2]. 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 represent the transfer of requirements information, but the arrows do not necessarily infer a design process flow. 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 therefore more about defining and refining the details, including any process equipment, while maintaining 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 in the traditional model. I will explain this more in part 3 of this series.
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 context weightings effectively enables us matching our development plan to our ‘difficulty budget’ – i.e. our project can target as radically new or as conservatively static as is appropriate for the situation (context). For example, there clearly is a difference in the amount of difficulty that can be accepted into a project that has a budget of 1 month and $30k, compared to a budget of 6 months and $300k. In case of the former, we would need to realistically moderate the amount of ambition that we set ourselves and focus our efforts wisely. The HoQ helps us achieve just that.
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 that we give to the design requirement for a “Strong carrying member”. You will note the development importance is downgraded to 4%, which we should consider to be sufficient to achieve the 10% technical target importance.
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 4-phase Clausing model is not always helpful. Firstly, it can infer that QFD is solely about building a HoQ, which is untrue. We do not develop the product toward a HoQ, but instead the HoQ establishes the prioritised plan for the development works that are to follow. The team-based approach promises to eliminate an organisations ‘functional over-the-wall’ working, or silo mentality, to product development. However, 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 flow. Lastly, the models and the international 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.
In the next post, we will look at an enhanced 4-phase model that overcomes some of the issues above.
[1] Akao, Y., “Quality Function Deployment – Integrating customer requirements into product design”, Productivity Press, 1990.
[2] Clausing, D.P., Pugh, S., “Enhanced quality function deployment”, Design and Productivity Conference, Honolulu, 6-8 February, 1991.