Methodology
This guide walks you through the CTQ Tree tool in the Define phase of RDMAICS, using one fictional case loaded in Ci Flow. You will see how a broad customer need becomes drivers, metrics, units, specification types and targets, and where the tool stops being useful.
A CTQ Tree translates customer needs into measurable, specific quality requirements with targets and specification limits. It takes something a customer said and turns it into something you can count, time or test.
You use it in the Define phase of RDMAICS, after you have gathered voice of the customer material and before you design any measurement plan. Recognise tells you a problem exists. Define has to pin down what good looks like from the customer side. Without that, the Measure phase collects whatever data happens to be available rather than the data that matters.
The structure is simple and deliberate. One customer need at the top. A small number of quality drivers underneath it. Then one or more requirement rows under each driver, each carrying a metric, a unit, a specification type, a target, a source of evidence and a named owner. The discipline is in the columns, not the diagram.
Everything below is built on one case. It is fictional. It is the sample data that loads with the tool in Ci Flow, so you can open the tool and follow along against the same rows.
The customer need at the top of the tree is: fast, accurate and predictable service. That sentence is typical of what you hear in interviews. It is honest, it is directionally useful, and it is impossible to manage against. Nobody can tell you whether the organisation hit fast last month.
Two quality drivers sit under that need in the sample. Speed and accuracy. Speed carries two requirement rows. Accuracy carries one. That is the whole tree. It is small on purpose, because a CTQ Tree earns its value from precision rather than coverage.
Start at the top. Enter the customer need exactly as the customer expressed it. Do not clean it up or make it sound more measurable at this stage. The gap between the raw need and the final requirement row is the work the tool is doing, and you want that gap visible.
Then add drivers. A driver is a dimension of the need. Speed and accuracy are the two in the sample. A driver is still not measurable. It is a category that groups requirements. If you find yourself writing a number in the driver field, you have skipped a level.
Under each driver, add requirement rows. Each row in the sample completes six fields. The requirement itself, the metric, the unit, the specification type, the target or acceptance criteria, the voice of the customer evidence source, and the measure owner. The row is only finished when all of them are filled.
The tool offers three specification types: lower is better, higher is better, and target is best. All three rows in the sample case use lower is better, which is common for cycle time, response time and defect rates.
The choice matters more than it looks. Lower is better means you only have an upper bound. Twenty three hours is acceptable and so is one hour. Higher is better reverses that. Target is best means both a low value and a high value are failures, which changes how you will later judge capability and variation.
Get this wrong and the Measure phase will chase the wrong direction. If you set a requirement as lower is better when the customer actually wants consistency, you will reward early delivery that the customer did not ask for and may not want.
The tool produces a result from the rows you enter and offers an AI review that explains it in plain language. Read the result as a completeness check on your Define work, not as a verdict on performance. No performance data has been collected yet at this point in RDMAICS.
What you are looking for in the output is whether the tree holds together. Does each driver connect clearly to the stated need. Does each requirement row give you a number you could audit. Does every target have a named owner who can actually see that number.
In the sample case, the three rows produce three measurable commitments. Cycle time in hours with a ceiling of 24. Response time in hours with a ceiling of 2. Defect rate in percent with a ceiling of 1. That is what fast, accurate and predictable service means for this fictional case, stated in a way that can be measured and disputed.
The first decision is scope. Once the tree is built, you can see which requirement is worth a project. Three measurable CTQs do not all need improvement at once. The tree gives you a short list to prioritise against.
The second decision is the measurement plan. Each row names a metric and a unit, so the Measure phase inherits a specification rather than inventing one. Cycle time in hours is collected differently to defect rate in percent, and the tree has already told you which you need.
The third decision is accountability. The owner column assigns each target to a role. In the sample, the Order Fulfilment Manager owns cycle time, the Customer Service Lead owns response time, and the Quality Manager owns defect rate. That makes the Control and Sustain phases possible, because there is someone to hand the chart to.
The fourth decision is evidence. Each row records where the requirement came from: customer interviews, complaint analysis, or a VOC survey. When a target is challenged, and targets always are, you can point to the source rather than to an opinion.
The most frequent error is writing drivers that are actually requirements. If your driver reads like a sentence with a number in it, the tree has collapsed into two levels and you have lost the grouping that makes it readable.
The second error is a metric without a unit. Cycle time means nothing until you say hours. The sample case states hours twice and percent once, which is why its targets can be stated as 24 hours or less, 2 hours or less, and 1 percent or less.
The third error is a target with no owner. An unowned target is a wish. The fourth is inventing evidence. If you cannot name where a requirement came from, leave the evidence field honest and go and collect it before you commit to a number.
The CTQ Tree will not tell you whether you are meeting the targets. It holds no performance data. In the sample case it states that cycle time should be 24 hours or less. It says nothing about what cycle time actually is. That answer comes from the Measure phase, and it may be uncomfortable.
It will not validate your voice of the customer work. The tool records that evidence came from customer interviews, complaint analysis or a VOC survey. It cannot tell you whether those interviews reached the right customers, whether the complaint set was representative, or whether the survey asked leading questions. Weak input produces a tidy tree built on sand.
It will not tell you whether a target is achievable or commercially sensible. A 2 hour response time may be reasonable or it may require staffing the organisation cannot fund. The tool records the number. It does not cost it, benchmark it, or test it against capacity.
It will not prioritise for you. Three requirements with three owners do not come with a ranking. It will not identify root causes, because that is Analyse work. It will not design a solution, because that is Improve work. And it will not keep itself current. If customer expectations shift, the tree stays exactly as you left it until someone opens it and changes it.
Used honestly, the CTQ Tree does one job well. It converts a sentence like fast, accurate and predictable service into numbers somebody owns. Everything after that is still yours to do.
RDMAICS, A3, Just Do It and Kaizen projects with the full Lean Six Sigma toolset, AI interpretation and tollgate presentations built from your real evidence.
5S Workplace Design converts a confirmed root cause into five concrete future-state actions with owners and dates. This guide walks through the tool's built-in sample case and shows how to size the gain before you commit to the change.
Read the article
Batch-Size Optimisation takes a diagnosed cause and turns it into a change you can pilot with a number attached. This guide walks through the tool's built-in sample data, from four candidate batch sizes to a single recommended answer.
Read the article
Setup Reduction / SMED takes a diagnosed cause and turns it into a change you can test. This guide walks through the tool's built-in sample data, task by task, and shows how to read the result before you spend anything.
Read the article