CTQ: Turning “Make It Good” into a Measurable Criterion

Most project kick-off meetings produce the same sentences:

“The system should be fast.” “Stock should add up.” “We shouldn’t have to wait for reports.” “Month-end should close smoothly.”

None of these sentences is wrong. None of them is a requirement either. When the project ends, two people can give two different answers to “did it get fast?” — and both can be right.

CTQ — Critical to Quality — is the step that closes this gap. Its job: to turn what the customer or user says into a criterion that can’t be argued over.

From VOC to CTQ

The starting point is the VOC (Voice of the Customer): the users’ own sentences. We don’t try to correct the VOC; we record it as it is. The translation comes afterwards.

The path in between has three levels:

Need                 Driver                      CTQ (criterion)
(what is asked)      (what it affects)           (how it is measured)
──────────────────────────────────────────────────────────────────────
"Orders should      → confirmation time      → Confirmation ≤ 4 hours,
 be approved        → stock visibility          for 95% of orders
 quickly"           → approval chain         → Approval ≤ 2 levels

"Stock should       → count accuracy         → Count variance ≤ 2% (monthly)
 add up"            → transaction timeliness → Transaction entered in
                                               the system ≤ 15 minutes

"Month-end should   → closing steps          → Close ≤ 5 working days
 close smoothly"    → reconciliation time    → Pending reconciliations = 0

The middle column is the one skipped most often — and the most useful. Behind “orders should be approved quickly” there are three separate drivers; if you write a criterion without knowing which one you’re touching, you measure the wrong thing.

The five parts of a CTQ

A practical way to tell whether what you’ve written really is a CTQ: are all five parts there?

If any of the five is missing, the CTQ isn’t complete. The two most often missing are the measurement point and the frequency — and precisely because those two are missing, the measurement never happens.

In an ERP, the measurement point is already there

In quality management, measuring a CTQ often means setting up a new data collection routine. In a company running an ERP it’s different: the data is already recorded; what hasn’t been written down is which field to read it from.

The practical benefit of this table: when writing a CTQ, the question “how will we measure this?” usually turns into “is this information already in the system?”. If the answer is no, the first job is not measuring the CTQ but making sure that timestamp gets recorded.

Good CTQ, bad CTQ

The last row deserves its own heading. Zero defects is not a CTQ, it is a wish. A criterion must be able to warn you when the process deteriorates; if you set the target at zero, every deviation sets off the alarm and soon nobody looks at the alarm any more.

How many CTQs?

Few. The number we see working well in the field is 3–5 per process chain.

Long CTQ lists share a common fate: in the first month all of them are checked, in the second month half, in the third none. Three criteria, on the other hand, can be tracked for months.

When shortening the list we use Pareto logic: which criteria represent the bulk of the problem? We don’t delete the rest; we move them from the “tracked” list to the “checked if needed” list.

Then there is the question of ownership: a CTQ without an owner doesn’t get measured. Every criterion should have a name next to it — it should be clear who looks at it when that number gets worse.

Embedding the CTQ in the system

A CTQ that stays in an Excel file stops being a criterion. In a company running an ERP you can keep the criterion alive in three places:

• Mandatory fields and validation. If the data feeding the criterion can’t be skipped, the measurement is reliable too. A field that can be left empty is a field that doesn’t exist.
• Threshold alerts. The system warning you when the limit is exceeded is faster than waiting for someone to open the report.
• A permanent indicator. If the criterion sits on a dashboard all the time, discussions revolve around the number. We build this on ErpwareBI.

These three are also the Control step of DMAIC. Embedding the CTQ in the system is what prevents an improvement from slipping back to its old state a few months later.

Where we use it

CTQs show up in two different places, with a different function in each:

• DMADV — in a process built from scratch. There is no performance to measure; the CTQ is the referee for design choices. The answer to “should this field be mandatory?” comes from looking at which CTQ that field feeds.
• DMAIC — when an existing process is being improved. The CTQ provides the baseline and the yardstick for the sentence “we improved”. In an improvement without a criterion, everyone thinks things got better and nobody can say by how much.

Where do teams stumble?

1. CTQs are never written. Project success is reduced to “did we go live?”. The calendar is measured, not quality.
2. The measurement point stays vague. The criterion is written, but not where it is read from; the work stalls at the first measurement attempt.
3. No limit is set. A target of “better” is a target that is never reached.
4. The list is kept long. Fifteen criteria give the same result as zero.
5. There is no owner. The number gets worse, nobody takes it on, and at the next meeting the subject changes.

How we run it

We produce the CTQ list as an output of process analysis — as part of Process Consulting, starting from the users’ own sentences and working down to the criterion. If the measurement point doesn’t exist in the system, we add the necessary timestamp or screen through custom application development, and connect the criteria to a permanent indicator on ErpwareBI.

The one-sentence summary: an expectation whose measure isn’t written down becomes a dispute at the end of the project; one that is written down becomes an acceptance criterion.