Quality Function Deployment (House of Quality): Size the Gain Before You Commit to a Pilot

Quality Function Deployment maps customer requirements to technical solution features and prioritises those features by relationship strength and correlation. In plainer terms, it answers one question: of all the things you could build or change, which ones actually move what the customer cares about.

You reach for it in the Improve phase of RDMAICS. By then you have already recognised the problem, defined the scope, measured the baseline and analysed the causes. You have candidate solutions on the table. What you do not yet have is a defensible order for them.

That ordering matters because the Improve phase is where money starts moving. A pilot costs time, attention and goodwill. Quality Function Deployment forces you to show your working before you spend any of it. Each solution feature earns its place through a visible calculation rather than a show of hands.

Use it when you have two or more competing solution options, when stakeholders disagree about sequence, or when a sponsor asks you to justify why one feature goes first.

The worked example in this guide is fictional. It is the sample data that ships with the tool, and it is there so you can see the mechanics without needing your own dataset first.

The scenario is an accounts payable process. Analysis has pointed at manual data entry and manual routing as causes of slow, error-prone invoice handling. Four technical features are on the table: OCR auto-capture, auto-routing, 3-way match rules and a vendor portal.

Four customer requirements are in play. Fast processing carries an importance of 9. Accuracy also carries 9. Low cost carries 7. Transparency carries 6. Those numbers come from the customer side of the conversation, not from the delivery team.

This is the moment the tool is built for. The cause is diagnosed. The options are known. Nobody can agree on which one to pilot first.

The worksheet has one row per relationship, not one row per requirement. That is the key habit to learn. A single requirement can connect to several features, and each connection gets its own line.

For each row you capture four things. The customer requirement, or What. The importance of that requirement on a 1 to 10 scale. The technical feature, or How. And the relationship strength, scored 1, 3 or 9.

The 1, 3, 9 scale is deliberate. It is not linear. A 9 means the feature directly and strongly delivers the requirement. A 3 means it helps in a moderate way. A 1 means the link is weak. The gap between 3 and 9 is wide on purpose, so weak links cannot quietly accumulate into a false priority.

In the sample data, six rows capture the full picture:

The tool recalculates technical priorities as customer importance multiplied by relationship strength. Each row produces a weighted score. Scores for the same feature are then summed, and the totals are plotted on a bar chart.

Auto-routing collects two rows. It scores 81 against fast processing and 63 against low cost. OCR auto-capture also collects two rows. It scores 81 against fast processing and 27 against accuracy. 3-way match rules carry a single 81. The vendor portal carries a single 54.

Read the chart from the top down and the order is clear. Auto-routing leads. OCR auto-capture follows. 3-way match rules sit next. The vendor portal sits last on this matrix.

What makes the ranking useful is not the ranking itself. It is the fact that every position traces back to a requirement, an importance score and a relationship judgement that someone put their name to. The tool also offers an AI review that explains the result in context.

The first decision is sequence. Auto-routing earns the first pilot slot because it serves two requirements, and one of them, low cost at importance 7, is served by nothing else in the matrix. Drop auto-routing and low cost has no technical answer at all.

The second decision is scope. OCR auto-capture carries a strong 9 relationship to fast processing but only a 3 to accuracy. That tells you how to frame the pilot. Measure it on speed. Do not promise accuracy gains that the matrix does not support.

The third decision is what to defer without losing it. The vendor portal is the only feature serving transparency, and transparency carries an importance of 6. A low rank here is not a verdict on value. It is a statement about relative weight against this set of requirements.

The fourth decision is about sizing the gain before you commit. The weights tell you how much customer-relevant value sits behind each option. They do not tell you the dollar value. You still have to pair the ranking with your Measure phase baseline to estimate what a pilot could deliver.

The most frequent error is scoring importance from the delivery team's point of view. Importance belongs to the customer. If you set it yourself, the whole matrix simply reflects what you already wanted to build.

The second error is overusing 9. If every relationship scores 9, the ranking collapses into a count of how many rows each feature has. The sample data avoids this by scoring OCR auto-capture against accuracy at 3, which is why that row contributes 27 rather than 81.

Other recurring traps are worth naming directly:

Quality Function Deployment ranks on value to the customer. It says nothing about cost to build, time to deliver, technical risk or dependency order. Auto-routing leads this matrix, but if auto-routing requires six months of integration work and OCR auto-capture takes three weeks, the ranking alone will not tell you what to pilot first.

It also says nothing about feasibility. A feature can score well and still be impossible within your constraints. The matrix is honest about customer pull and silent about delivery push.

So treat the output as one of several inputs. Lay the ranking next to an effort estimate and a risk view. Where a high-ranking feature is also cheap and low risk, you have a clear pilot candidate. Where a high-ranking feature is expensive, you have a conversation to hold rather than a decision to make.

Be clear about what Quality Function Deployment will not do. It will not validate your importance scores. If the customer voice behind that 9 for fast processing came from two people in a corridor, the matrix will carry that weakness all the way to the chart without flagging it.

It will not predict an outcome. Nothing in the sample data forecasts a cycle time reduction, a cost saving or an error rate. The weighted scores are relative measures of customer-relevant value, not estimates of benefit. Any gain you quote has to come from your own baseline and your own pilot measurement.

It will not handle interactions between features well. The classic House of Quality roof captures correlations between technical features, where one feature helps or hinders another. In a simple relationship worksheet those effects are easy to lose. OCR auto-capture and auto-routing may well depend on each other in practice, and the summed scores will not show that.

It will not survive a stale matrix. Requirements move. Importance scores shift as the business changes. A matrix built once and never revisited becomes a record of an old opinion. Rebuild it when the requirements change, and rebuild it before the Control phase hardens your choices into standard work.