Why Do Six Sigma DMAIC Projects Fail to Proceed? —— A Case Study of a Manufacturing Company's Project Revival

By: QTank Published: 8/13/2026 Views: 53
Current rating: ★★★☆☆ Rate this Equivalent to 8 ratings

1. Introduction: A Project Stuck in the Measure Phase for Four Months

A manufacturing company initiated a Six Sigma project last year to reduce the welding defect rate of hydraulic valve bodies. The project had clear goals: to lower the defect rate from 3.5% to 0.8%, with an estimated annual benefit of 1.2 million yuan. The company even hired a Black Belt for guidance. Everything seemed to be in place, but four months after the project's launch, the team had not even completed the Measure phase. They had collected a large amount of data, but the analysis was not progressing. At the monthly review meeting, the project leader could only repeatedly say, "The data is still being organized." As the project was on the verge of being downgraded and closed, the Quality Director personally intervened and spent two weeks conducting a "project health check," which finally brought the project back from the brink.

This case is very representative. Many companies' DMAIC projects fail not because of the methodology, but because they simply "cannot proceed": they start with great fanfare, fall silent after three months, and are closed after six months due to "objective reasons." According to industry statistics, the proportion of Six Sigma projects that truly complete the entire DMAIC process and generate measurable benefits is not high, with a large number of projects failing midway. Why do projects fail to proceed? Based on observations from this company and several other projects, the problems almost always lie in the following five areas.

2. The Five Most Common "Failures" of DMAIC Projects

First, Failure in Define: The Topic is Too Broad, and the Scope is Out of Control. Some companies set project goals like "improving the overall quality level of the company" or "reducing the complaint rate of all products." These sound ambitious but are impractical. DMAIC projects require that the problem be measurable, clearly defined, and that one project addresses one core issue. The broader the topic, the more variables, the more complex the data, and the more uncertain the team is about where to start. For example, an appliance company once initiated a project to "reduce customer complaints across all product categories." After six meetings in the Define phase, they still couldn't clearly define Y, and the project was abandoned after two months. A well-defined Y should be specific, such as "reducing the porosity defect rate in welding of Model A valve bodies."

Second, Failure in Measure: The Data Foundation Cannot Support Analysis. DMAIC is data-driven, but many companies rely on manual data recording at the production site, leading to omissions, errors, and inconsistent standards. They can't even clearly state what the current level is. The equipment manufacturing company mentioned earlier was in this situation: in the welding process parameter records, the current and voltage were only noted as "normal," and nonconforming products were not classified by defect type. The 3.5% defect rate was estimated through sampling. A more common issue is rushing to collect data without conducting a measurement system analysis (MSA) first—tools with poor repeatability and reproducibility produce garbage data, no matter how much is collected. The Measure phase, which seems simple, is actually the first critical checkpoint of the project.

Third, Failure in Analyze: Tools Piled Up, No Conclusions. Some teams use a variety of tools such as fishbone diagrams, FMEA, hypothesis testing, and regression analysis, producing dozens of pages of PPTs but failing to identify the "key factors." Tools are means, not ends. The output of the Analyze phase must be a few validated key factors (X), not a tool exhibition. For instance, an electronics company worked on improving solder paste printing defects. The team spent three months on correlation analysis but found that the data sample was insufficient and the grouping was incorrect, leading to the invalidation of all conclusions and a forced return to the Measure phase to collect new data.

Fourth, Failure After Improve: No Institutionalization of Results. This is the most regrettable type of failure. The project clearly achieved results, reducing the defect rate from 3.5% to 0.8%, but the corrective actions remained temporary solutions within the project team: work instructions were not updated, control plans were not revised, poka-yoke devices were not included in inspections, and new parameters were not written into procedure documents. After the project closed, the defect rate quietly rebounded to over 3% within three months. Without institutionalizing the results, the project is as good as never having been done.

Fifth, Failure in Mechanism: People, Time, and Reviews Not Properly Implemented. Project members are all part-time, busy with production during the day and working on the project at night; Black Belt guidance is provided only once a month; stage gate reviews are superficial, focusing on PPTs rather than data; and project benefits are not calculated, making the completion of the project irrelevant. For example, an automotive parts company initiated 15 DMAIC projects in a year, but only 2 were completed, with the rest abandoned. When new projects were initiated the following year, frontline engineers collectively resisted, saying, "It's all just a formality anyway."

3. Case Review: How This Company Revived the Project

Returning to the initial case, the Quality Director's "project health check" identified four issues: first, Y was defined too broadly, covering three types of valve bodies, two production lines, and five failure modes, making the data alignment impossible; second, the measurement system was not validated, with the visual inspection for welding defects having extremely poor repeatability; third, all five team members were part-time and none had a strong background in statistics; fourth, no formal stage gate review had been held in four months.

To address these four issues, the company took four actions. First, they redefined the project and narrowed the scope: the project was changed to "reducing the porosity defect rate in welding of Model A valve bodies," focusing on one production line and one defect mode, with Y defined as "porosity defect rate (PPM)" and the target set to reduce from 4200 PPM to 900 PPM. Second, they strengthened the data foundation: they conducted an MSA, changed the visual inspection to a standard sample card-based judgment, and validated it. They also installed automatic parameter collection on the welding equipment, changing data recording from manual to system-based, and collected 2400 samples over six weeks. Third, they reorganized the team: a process engineer certified as a Green Belt was assigned to take charge full-time, dedicating 60% to 70% of their weekly hours to the project, and Black Belt guidance was increased from once a month to once every two weeks on-site. Fourth, they reinstated the stage gate reviews: the Quality Director personally led the reviews for the Define, Measure, Analyze, Improve, and Control phases, requiring each gate to answer three questions with data—what is the current level, what are the key factors, and has the improvement been validated.

After the project was restarted, it took 5 months to complete the entire process: the Analyze phase used fishbone diagrams and regression analysis to identify three key factors—fluctuations in protective gas flow, unstable wire feeding speed, and excessive oil contamination in incoming bevels. The Improve phase implemented automatic monitoring and alarms for gas flow, replaced the wire feeding mechanism and revised parameter standards, and added a cleaning process for incoming bevels. The Control phase updated the control plan and work instructions, incorporating the three key factors into daily inspections and setting up control charts for continuous monitoring. The porosity defect rate stabilized at around 800 PPM, below the target value, and the financial calculation showed an annual benefit of 960,000 yuan. The project was rated as an excellent improvement project for the year. More importantly, this "stage gate + data-driven" approach was replicated in six subsequent projects, increasing the completion rate from less than 20% to over 80%.

4. Four Mechanisms to Ensure DMAIC Projects Can Proceed

Reviewing this case, we can distill four replicable mechanisms.

First, Rigorous Project Approval. During the project approval phase, the following questions must be answered clearly: what is Y, where does the baseline data come from, what is the target value, which production line and defect is the scope, and who will be dedicated to the project and for how many hours. If these five questions cannot be answered clearly, the project should not be approved. It is better to cut the number of projects in half to ensure that each one can be completed.

Second, Data-Driven Stage Gate Reviews. Each stage gate review should only accept three types of evidence: measurement data of the current level, validation data of key factors, and comparison data of improvement effects. Any storytelling, tool displays, or page padding will be rejected. Stage gate reviews are not just reporting sessions; they are quality checkpoints.

Third, Adequate Resource Allocation. The project leader must have a clear time commitment, and Black Belt guidance must have a fixed frequency. Hardware investments for measurement and data collection should be approved in advance. Many projects fail because of the adage "you can't have the horse run without feeding it"—no matter how good the method, without resource support, it is just a castle in the air.

Fourth, Clear Calculation of Benefits. Before closing the project, a financial calculation must be completed. Three months after the Control phase, a "look back" should be conducted to confirm that the improvements have not rebounded. Clear calculation of benefits provides the motivation for continuous project initiation and helps to foster a culture of continuous improvement.

5. Conclusion

The root cause of DMAIC projects failing to proceed is never in the methodology but in the four fundamental areas: topic selection, data, resources, and review mechanisms. Addressing these basics ensures that projects can proceed smoothly—this is more effective than learning ten more statistical tools.


The root cause of DMAIC project failures is not in the methodology but in the four fundamental areas: topic selection, data, resources, and review mechanisms.

Knowledge code: 6.1.1

Version: v20260813

Author: Quality Think Tank Quality Think Tank is dedicated to providing systematic professional knowledge, methodologies, and practical tools for quality management practitioners, helping companies continuously improve their quality capabilities.