Quality Function Deployment is taught to an estimated 150,000 design students every year. Its taught principles have contributed to success in many thousands, possibly millions, of design projects – although also to some that failed. Of all the design projects that have applied the QFD principles, only a fraction have used an established QFD model approach in its entirety – i.e. performing its every method from start to finish. The Evolved 4-phase model that I presented in part 2 of this series has attempted to address some of the issues, but I doubt this is enough to make any real difference.
Basically, the QFD principles are widely applied, but the currently established model approaches are not! The models are recognised, but they are not formally practised in mainstream design and development. Here are some suggestions why this might be:
Although the QFD principles make good sense, the current models do not visually reflect the workflow of a practical design and development project. They depict a series of cascading step-by-step activities, where product design appears as an isolated activity coming before process design. In a more natural workflow, product and process design is a concurrent activity, with parallel thinking and iterative linking back and forth between the stages – e.g. when choosing a material then we immediately think about how it will be processes; and when developing the process then we may ask for parts layout changes to facilitate better access for assembly. Robust Engineering Design (RED), for example, fundamentally spans the product and process development and cannot be separated into two isolated activities.
The user has to overcome the confusing distinction between ‘approach’ and ‘process’. QFD cannot simply be picked up and put to use – it is too abstract. As per requirements in ISO 9001, a QFD-based design process should first be defined with its interfaces to other local organisational processes. None of the established QFD model approaches, nor the high-level flow chart defined in the ‘young’ ISO 16355 standard, do yet picture or describe where and how the QFD approach fits within a wider process-based management system. ISO 16355 expressly does not specify a design process or management system – just the guiding principles, to be implemented within a user’s own defined processes.
Established QFD approaches infer their use in time discrete projects. The role of QFD in the post-launch design review is unclear. The wider Design Management System commonly features a PDCA loop, periodically referring products and processes back to the designers for corrective actions over the full life-cycle. The Comprehensive QFD model [Akao] has a flow from post-launch defects back into reliability design; but this is not the whole scenario of reasons for reviewing a product. Reviews frequently result from an accumulation of small drifts in the naturally advancing customer preferences and/or an evolution in the operations technology. In yet other scenarios, the first new product design has to prioritise time-to-market over absolute optimisation; with a deliberate view to take the product back into design for further optimisation, if and when it reaches a sizeable market penetration.
Mismatch to ‘designer culture’. The systematically guided QFD approach, often including an algorithmic House of Quality element, can appear objectively dispassionate.
I am not clear what it will take to get a QFD approach to the next level of mainstream use. Simply promoting more of the same will probably not do it. There is a call for fresh thinkers to develop and test new model approaches. A suggested, non-validated belief, here, is that such new approach should define or depict the following:
- The ISO 16355-1 high-level process stages (while ignoring its current ‘discussive’ techniques and Annex);
- Generic in nature – i.e. non-prescriptive and universally applicable to any type of product, service and organisation. The model may helpfully, but optionally, suggest associated tools for different types of developments.
- Reserve organised space for playing around with and allowing a naturally motivated exploring of the design problem. Dependence on artistic freedom is of course a myth; but the designer must not feel artistically constrained either. The QFD approach and tools must remain subordinate to the development team and never feel the other way around.
- Concurrent design of the product and its production processes, in the concept and layout design stages – e.g. we think about the production/delivery process when selecting materials and when arranging mechanical layout;
- Sequential design of the product and its production processes, in the detailing stage – i.e. the product design must be fixed, before the final process details can become fixed, and so on;
- Interfacing or integrating the QFD ‘process’ into a PDCA-based Design Management System and/or wider system.
What could QFD 2.0 look like?
Possibly, the scope of QFD could be widened, for it to become the Design Management System – as the founders of the original model had intended it. QFD is nearly there. It does link vertically to strategic planning, and it links-up the organisational functions horizontally. It just does not clearly define a complete process or system.
The header image at the top of this post suggests a draft model depicting QFD as a design and development process, ready to be integrated into a wider PDCA-based management system.
How does QFD integrate with the Design Management System PDCA cycle?
How do processes that contain elements of the QFD approach interface within the Organisation’s wider management system processes? Note how Management Review has a leadership function in driving the PDCA.
In post-launch design review, the original deployment charts – e.g. HoQ – can facilitate the ‘Plan’ element in the PDCA cycle. Simply reviewing the prior input customer requirements and the what/how contexts, in light of the new situation, will fast produce a prioritised plan for the re-design activity.
The alternative draft model here is a suggested design management system reflecting PDCA, concurrent and sequential process elements in a development project.