Picture a world where customers LOVE your products and rave about your service.
In the relentless pursuit of delivering products that meet and exceed customer expectations, it is necessary to understand Critical to Quality (CTQ) measurements.
Think about every product you’ve ever loved. Think about companies you willingly follow on social media and tell all your friends and relatives about. Think about those brands where their customers get tattoos of their logos!
These are not aspirations. They are tangible manifestations of CTQ requirements. CTQ requirements are the linchpin. They ensure your output aligns seamlessly with what customers demand. You must understand Critical to Quality measures if you want a fanatical customer base.
Critical to Quality requirements relate to customer expectations and needs around the quality of your output.
Some examples of CTQ requirements are:
- Mobile phone screens do not break when dropped from three feet onto concrete.
- Engine part size variance of less than 0.5%.
- The tensile strength of a steel girder must be at least 1000 MPa.
Critical To Quality Requirements vs. Drivers
Drivers, or Critical to Client requirements, are what your clients want, expect, or need.
Critical to Quality requirements are the conditions your output must meet to answer the drivers. You’ll often have more than one CTQ requirement per driver.
Occasionally–especially in the construction industry–you might find that the drivers are specific enough to translate directly into CTQ requirements. Generally, though, the two will be different, but the CTQ will flow from the drivers.
Examples of drivers and CTQ requirements
| Driver | CTQ Requirement(s) |
|---|---|
| My online accounting software will be available 24/7. | Downtime of fewer than 10 minutes per week. Protection from denial-of-service attacks. Distributed servers. |
| My mobile phone will be durable and stand up to occasional minor drops. | Break-resistant screen to a height of 1m. Reinforced edges with internal padding. |
How to Develop Critical to Quality Requirements
A CTQ tree is a common tool used to put together CTQs.
It consists of three primary sections:
- Customer requirement: This is what the customer might express to you as a concern. For example, “I like my coffee really hot and milky!”
- Drivers: The customer requirement is broken down into action points. For example, “High temperature” and “High percentage of dairy milk.”
- CTQ requirements: These are your manufacturing guidelines to meet the drivers. For example, “Full-cream pasteurized dairy milk” and “Milk frother heats to at least 203°F”.
The end result for the above example would look something like this:
1. Customer requirements
Start with your customer’s requirements. What do your customers want in regard to quality? You’ll typically come up with more than one of these. Use each in a different CTQ tree.
2. Drivers
Break down your customer requirements from the previous step into drivers. Think about what exactly your customer is really expecting. Or, to put it another way, what traits of your end product must be in evidence for the customer to decide that it has met their requirement?
3. CTQ requirements
From the drivers, decide on what internal requirements you need. These will help you to produce a product that meets the driver’s conditions. They are also benchmarks that you would use to perform QA tests.
Elements of Good Critical-to-Quality Requirements
Good CTQ requirements are like SMART goals:
- Specific: They need to be clear and easily understood.
- Measurable: Unlike customer requirements, which can be highly subjective, CTQ requirements must be objective. If you can’t measure it, it’s not a good CTQ.
- Applicable: They must directly relate to your customer requirements. Remember, CTX requirements are customer-focused.
- Testable: Your staff must be able to check that your product meets CTQ requirements.
CTQ Videos
When you’re ready, there are a few ways I can help:
First, join 30,000+ other Six Sigma professionals by subscribing to my email newsletter. A short read every Monday to start your work week off correctly. Always free.
—
If you’re looking to pass your Six Sigma Green Belt or Black Belt exams, I’d recommend starting with my affordable study guide:
1)→ 🟢Pass Your Six Sigma Green Belt
2)→ ⚫Pass Your Six Sigma Black Belt
You’ve spent so much effort learning Lean Six Sigma. Why leave passing your certification exam up to chance? This comprehensive study guide offers 1,000+ exam-like questions for Green Belts (2,000+ for Black Belts) with full answer walkthroughs, access to instructors, detailed study material, and more.
Comments (10)
Very good information. What is basic difference in cp & cpk.
Ve_deepak@hoymail.com
Deepak, you came to the right place. Check out this article on Cp & Cpk.
I want to learn mor about that
What exactly would you like to know?
Hi Ted,
I was just looking at you site, regarding CtQs, and have a question for you. I hope I got your email address correct, since you didn’t write it in the traditional sense.
If you did receive this, will you please tell me the difference between CtQs and non-CtQs? In other words, the product management team provide a list of VoC reports, and from those, CtQs are generated, and technical requirements will be created from the CtQs for engineering to go off and design and produce a product. However, are ALL technical requirements derived from CtQs? Can there be more technical requirements than CtQs? I am rather new to CtQ, DFMEA, etc., and an trying to learn as much as I can so I can do my job. Or is there a list of CtQs and other general requirements from the product management team, and both get translated to either technical CtQs or technical general specification? I hope I am clear.
Thanks for your consideration.
Respectfully,
John
Hi Jon,
Sorry for the delay answering here. Yes, there can be several other kinds of requirements. Please see Critical to X, here.
Best, Ted.
Hi Ted,
Thanks for your reply and resources to read regarding CtQ. Please allow me to clarify my original question further. Now that I understand there are multiple Critical to “X” requirements (from your article), I need to ask my original question again, i.e. are all requirements critical? Must all engineering requirements stem from VoC and the drivers?
A DFMEA uncovers potential failure modes, which then helps one focus on resolving problems before the product hits the market. I consider the high RPN and SEV numbers CtQs, which are mostly safety and performance-related. So, it appears to me that CtQs come from two directions, i.e. the VoC and the DFMEA, and these two lists of CtQs should be managed by quality.
I do not think all technical specifications are critical to quality, e.g. height of box, weight of box, shape of PCBA, etc., and yet all requirements should find their origin from the VoC. So, are there VoC requirements that are not critical, and how does one determine whether they are critical? (VoC tends to imply critical to me.)
I hope this clarifies my question. It appears to me that the CtQs uncovered during the DFMEA and those form the VoC can have overlap, (Venn diagram-like), but yet they are different lists. And if VoC requirements do not drive every technical specification, then how can engineering create requirements that do not have their origin in the VoC? I sure hope this clarifies my original question.
Respectfully,
John
Hi John,
I’m thinking a Venn diagram where VOC is one circle, risk is another, and strategic imperatives is a 3rd might be helpful here. There will be an area of overlap – do those first. Then evaluate the other items with the most overlap.
In short, just be cause you can (or you’ve been asked to), doesn’t mean you should.
Here are some other thoughts:
VOC or VOX and risk items (like those resulting from a FMEA) be weighted independently. After all, no business has infinite resources to attack items.
One school of thought is that ROI should drive prioritization. And that can be true in a sense. But you can also go broke chasing all items.
Personally, I favor filtering all demands and requirements as follows:
First, find the non-discretionary items. These are often risk items that will kill you or shut you down or are simply ‘table stakes’ (like security, regulatory, legislation, health) and add them to the list.
Then, take the VOC items and perhaps interpret through something along a Kano model to see what would really move the needle for your business.
From there you can marry the necessary and possible initiatives to the vision of the executive team through an exercise like Hoshin Kanri.
Now that you have a translation take all of the actual, practical projects and prioritize them in a sequence using Weighted Shortest Job First method.
can you please give an example of the CTQ requirement – Testable: Your staff must be able to check that your product meets CTQ requirements?
Hi Rajanikant,
Can you give me more details to your question? I may be over simplifying this in my head but I think of this in the same way that I think of Measurable in SMART goals.
Here’s a quote from another site that I like: