WeChat account 弧光星云 — First published on the WeChat quality-engineering column 弧光星云; republished here with attribution. Reviewed and formatted by 8D.wiki before publication.
Reviewed & edited by: Alvin Jin — IATF 16949 expert · Certified Product Engineering (PE) coach · DRBFM expert
Published 2024-03-15 · Last reviewed 2026-10-25
Why quality and R&D fight at the release gate — and how to end the stalemate: quantify "can we accept it?" into "how much will it cost?" (5,000 units with on...
TL;DR: Quality and R&D clash at the release gate — "it might fail" vs. "the risk is small." The fix is not louder arguments but quantification: 5,000 units with one failure scales to 100 failures at 500,000 units. Convert "can we accept it?" into "how much will it cost?" then prepare a contingency plan for the quantified risk. With numbers and a plan on the table, a stalemate becomes rational collaboration.
In the corporate structure, the quality department and the R&D department are often a typical pair of "frenemies." When conquering technical challenges and delivering quality products to customers, they fight side by side. But at the moment of product release, they frequently face off across the table — even erupting into open conflict.
The essence of this contradiction is a contest between "risk aversion" and "delivery speed." The quality department is tasked with guarding the bottom line: when potential hazards exist, it must hold the line firmly. The R&D department carries the enormous pressure of market delivery: any delay caused by a "trivial defect" can trigger customer dissatisfaction. So at the decision gate of risk release, the quality people emphasize "it might cause an accident," while the R&D people argue the risk is "not significant." This vague, qualitative dispute often traps both sides in a stalemate where neither can convince the other.
A company planned to mass-produce a new product at 500,000 units. During certification testing, the quality department found that the durability index of one switch was slightly insufficient.
The project manager, representing R&D, insisted on launching to market as planned, for two reasons. First: the same switch had been used in an earlier, low-volume product of the company, and while it did not cause serious market complaints, it was therefore judged "acceptable." Second: switching to a new switch now would involve design changes and re-validation, raising development costs and delaying time to market.
The quality department firmly opposed the release. Their core logic was simple: the planned production volume of the new product is one hundred times that of the old one. With the same failure rate, the absolute number of potential failures grows geometrically, very likely triggering large-scale customer complaints.
Both sides held their ground, arguing heatedly over whether to release.
How do we break this endless dispute? The answer lies in digging to the essence of the problem — replacing vague perception with quantified data, converting the subjective judgment of "can we accept it" into the quantified decision of "how much will it cost."
In this case, if both sides stop arguing about "yes or no" and instead take one more step — quantitatively extrapolating the key durability indicator of the switch — the situation changes completely.
Suppose the old product sold 5,000 units in the North American market with only one switch failure, which was resolved immediately after maintenance and caused zero customer dissatisfaction. Scaling the same failure rate, the new 500,000-unit product is expected to produce about 100 failures.
At this point, the decision logic shifts from a "technical parameter debate" to a "trade-off of commercial cost and contingency feasibility": can the company bear the after-sales cost of these 100 potential failures?
The essence of the problem goes beyond numbers. Quantification is only the first step; the second is to prepare thorough contingency plans for the risks exposed after quantification.
If, before the new product hits the market, the team prepares a dedicated contingency plan for this switch failure in advance — stocking replacement parts, training frontline maintenance staff, ensuring that when a problem occurs they can rush to the site and resolve it perfectly, just like handling that one old-product failure — then the risk changes from "uncontrollable" to "controllable."
When the R&D department can present a quantified risk projection and a concrete response plan in front of the quality department, the dispute is no longer a hopeless game of "do you dare to take the risk?" but a rational collaboration of "let us look together at whether this risk is worth taking and whether the plan is sufficient." The quality department transforms from a "blocker" into a "gatekeeper" — not preventing passage, but ensuring every step that passes is backed by data and covered by a contingency plan.
Many interdepartmental conflicts do not originate from opposing positions, but from a shallow understanding of the problem. When the debate stays at the level of "there might be a problem" versus "it should be fine," neither side holds any solid evidence, and emotion becomes the only weapon.
Once we take two more steps forward — first calculate the numbers, then prepare the plan — the situation becomes clear. The vague "might" becomes a concrete "100 failures," the abstract "taking risk" becomes a specific "having a plan," opposition becomes collaboration, and conflict dissolves.
This is the meaning of digging to the essence of a problem: it is not an either-or choice between "release" and "don't release," but a way to turn a binary choice into an engineering problem with data, contingency plans, and consensus.
Turn this method into a submittable 8D report
Generate a D0–D8 report skeleton with a 5-Why chain and containment actions.
8D.wiki — Quality Engineering Knowledge Base