A Quality Function Deployment exercise run by twelve engineers in one room produces a tight, defensible House of Quality. The same exercise run across three sites, two languages, and four engineering disciplines produces a political document. Across two decades in automotive and aerospace, I have seen co-located teams produce excellent QFD outputs, then watched those outputs collapse when the programme scales to a multi-site supply chain.
The failure is mechanical. The House of Quality depends on consensus: a group of engineers arguing about whether seal compression force has a strong (9) or moderate (3) relationship to 'quiet cabin.' When those engineers sit in different buildings, the argument does not happen. The matrix gets filled in silos, emailed around, and approved without genuine debate. The correlation matrix — the roof where trade-offs are exposed — is skipped entirely because nobody wants to own the conflict remotely.
Scaling QFD is not a software problem. It is a governance problem. The methodology is unchanged; the social architecture that makes it work has to be rebuilt for a distributed organisation.
Decomposition Strategy for Multi-Programme Portfolios
At volume, a single House of Quality cannot absorb the customer requirements of five vehicle variants or three aircraft programmes. A 25-requirement matrix swells to 120 requirements, and the 9,600-cell analysis-paralysis threshold is crossed. The solution is hierarchical decomposition: a programme-level House of Quality that fixes the top ten non-negotiable customer needs, feeding subsystem-level houses owned by individual sites or tier-1 suppliers.
The programme-level house sets the strategic priorities. The subsystem houses translate those priorities into local engineering characteristics. A door panel team in one plant receives 'easy to close' and 'quiet cabin' as weighted inputs, not as vague wishes. Their local house determines the seal compression force, panel thickness, and latch tolerance. The cascade is deliberate: each site argues about its own trade-offs within boundaries set by the programme.
The handoff between levels is where traceability lives or dies. Every engineering characteristic in a subsystem house must map to a customer requirement in the programme house through a documented linkage. When a site engineer changes a tolerance, that change must propagate upward to the programme house. Without this linkage, subsystem optimisation silently undermines programme-level priorities. I have audited plants where local teams hit every internal target and still failed customer satisfaction audits because the connection between levels was severed.
Single-Site vs Multi-Site QFD Governance
Single-site QFD
- Consensus built face-to-face in real time
- One House of Quality covers the full product
- Trade-offs resolved through direct argument
- Requirements managed by a single cross-functional team
Multi-site QFD
- Consensus requires structured governance forums
- Hierarchical decomposition: programme to subsystem
- Trade-offs negotiated across sites with documented decisions
- Requirements cascaded through tiered houses with traceability rules
Governance cadence matters as much as structure. In a multi-site deployment, the programme house must be reviewed at every major design gate — concept, design freeze, and pre-production — with all subsystem owners present. This is not a status update. It is a structured argument about whether the subsystem houses still support the programme-level priorities. If the review becomes a presentation, QFD has failed.
Controlling Correlation Conflicts Across Distributed Teams
The correlation matrix is the most valuable section of the House of Quality. It is also the first section abandoned when teams are distributed. Filling the roof requires engineers to admit that their preferred characteristic conflicts with someone else's. In a co-located team, that admission happens in a meeting. In a distributed team, it requires a formal conflict-resolution protocol.
The protocol is straightforward. Every negative correlation flagged in a subsystem house is logged as a design conflict with an owner, a target resolution date, and a documented decision. Conflicts that cannot be resolved at subsystem level are escalated to the programme house. The programme team arbitrates using the weighted importance ratings: which customer need carries more strategic weight? The decision is recorded, not in meeting minutes, but in the house itself as a resolved trade-off with justification.
This protocol sounds bureaucratic until you measure its absence. The cost of an unresolved trade-off discovered during pre-production builds is orders of magnitude higher than the cost of a structured argument during concept design. Unresolved conflicts surface as warranty claims, field complaints, and late-stage engineering changes that disrupt the entire supply chain. The roof is not optional decoration; it is the section that prevents the most expensive class of quality failure.
Cascading Requirements Through Tier-1 and Tier-2 Suppliers
When QFD cascades beyond the OEM into tier-1 and tier-2 suppliers, the methodology meets its hardest test. Suppliers receive engineering specifications through PPAP and control plan requirements, but they rarely receive the customer-priority context behind those specifications. A supplier knows that a tolerance is 0.8 μm Ra. They do not know that it traces to a customer need rated 9 out of 9 for importance, or that it conflicts with a weight-reduction target.
Without context, suppliers optimise for compliance, not for customer satisfaction. They hit the tolerance because the control plan demands it, but they have no reason to flag a conflict between that tolerance and a process capability issue that would require a design change. The four-phase cascade — product planning, part deployment, process planning, production planning — was designed to carry this context through every layer.
Four-Phase QFD Cascade in a Multi-Tier Supply Chain
- 01Phase 1: Programme houseOEM-owned. Customer requirements translated to engineering characteristics with weighted priorities.
- 02Phase 2: Subsystem housesSite or tier-1 owned. Engineering characteristics translated to part specifications and tolerances.
- 03Phase 3: Process housesSupplier owned. Part specifications translated to process parameters, machine settings, and tool selections.
- 04Phase 4: Production housesShop-floor owned. Process parameters establish inspection frequencies, control limits, and standard work.
The cascade breaks at organisational boundaries. The output of Phase 2 arrives at a tier-1 supplier as a drawing and a PPAP package, stripped of the priority weighting that makes QFD effective. The supplier builds their own internal house, but without the programme-level context, they cannot distinguish a critical characteristic from a routine one. The solution is to pass the weighted importance ratings alongside the technical specifications — not as a courtesy, but as a contractual requirement in the supplier quality manual.
Suppliers who understand which characteristics carry the highest customer-impact weight make better process decisions. They allocate their MSA resources to the measurements that matter. They design their control plans around the parameters that trace back to a 9-rated customer need, not the parameters that are easiest to measure.
Maintaining Traceability When Mix and Volume Grow
Product mix destroys QFD integrity faster than volume. A plant running three variants of a door panel has three sets of customer requirements, three sets of engineering characteristics, and three correlation matrices. When the team tries to manage all three in a single house, the matrix becomes unreadable. When they split into three independent houses, the common characteristics — shared latches, common seal designs, identical glass runs — lose their programme-level coordination.
The solution is a platform house that manages shared characteristics, flanked by variant houses that manage differences. The platform house owns the engineering characteristics common to all variants. The variant houses own only the delta: characteristics unique to a specific trim level, market, or powertrain. This structure scales cleanly because adding a variant does not require rebuilding the platform house — it requires building one new variant house and checking it against the existing platform.
Volume growth introduces a different pressure. As production rates climb, process capability data becomes available in quantities that the original house could not access. Cpk values, OEE trends, and scrap rates reveal which engineering characteristics are genuinely controllable and which are sitting on the edge of process capability. This data must flow back into the house as a reality check on the engineering targets. A target that the process cannot hold is not a target; it is a warranty claim waiting to happen.
Integrating QFD Outputs Into Scaled Quality Systems
The House of Quality is not a standalone deliverable. Its outputs feed the quality system tools that govern production: DFMEA, PFMEA, control plans, MSA scope, and APQP documentation. In a multi-site operation, this integration must be systematised, not left to individual engineers' initiative.
The engineering characteristics with the highest weighted importance from the programme house must automatically become the highest-priority failure modes in the DFMEA. The subsystem characteristics cascaded to tier-1 suppliers must define the control plan entries that PPAP validates. The measurement systems for those characteristics must receive formal MSA studies — not because of an arbitrary policy, but because a customer need rated 9 out of 9 depends on that measurement being reliable.
The matrix does not protect the customer. The argument the team has while building it does.
When QFD outputs are integrated into these systems, the entire quality apparatus — from design review to shop-floor inspection — aligns around the same prioritised set of customer needs. When they are not, each tool optimises independently. The DFMEA chases engineering risks the customer does not care about. The control plan monitors characteristics unrelated to field complaints. MSA resources are spent on measurement systems that guard against irrelevant variation.
The integration point that matters most in a scaled operation is the engineering change request process. Every proposed change must be evaluated against the programme house: does it improve, degrade, or leave unchanged the weighted customer requirements? This is where QFD earns its keep at scale. It gives the change board a structured basis for decisions that would otherwise be made by the loudest voice on the call.
Governance and Cadence for Distributed QFD Programmes
A multi-site QFD programme needs an owner — not a facilitator, an owner. This person is accountable for the integrity of the programme house, the consistency of the subsystem houses, and the traceability between them. They chair the design-gate reviews where the houses are challenged. They arbitrate cross-site conflicts that cannot be resolved at subsystem level. Without this role, the houses drift apart and the cascade becomes a series of disconnected exercises.
The cadence of QFD reviews must match the programme cadence, not the calendar. At concept design, the programme house is reviewed for completeness: are all critical customer needs captured, weighted, and benchmarked? At design freeze, the subsystem houses are reviewed for consistency: do their outputs trace to the programme house, and are all negative correlations resolved? At pre-production, the production houses are reviewed for feasibility: can the process hold the targets the cascade demands?
The final governance element is training. Not training on the methodology — that is assumed — but training on the governance protocols: how to log a conflict, how to escalate a cross-site trade-off, how to document a decision in the house itself. Engineers who know QFD but do not know the governance protocols will default to filling in matrices in isolation. The methodology will be followed. The argument will not happen. And the house will be a form, not a tool.