By 2014, GE’s stock had been roughly flat for a decade. The company that Jack Welch had built into a six sigma in project management flagship was struggling to grow its industrial businesses, losing ground in technology, and eventually facing write-downs in its financial division. Former executives and analysts pointed to a pattern that had been building for years: relentless process optimization had made GE very good at running existing businesses and less capable of creating new ones. The Six Sigma culture that produced documented, measurable improvements in the 1990s had, at some point, started punishing the kind of ambiguous, unmeasurable work that builds new markets.
Table of Contents
The GE arc is worth understanding before getting into methodology, because it shows something most six sigma in project management guides treat as a footnote: the tools work inside a specific envelope, and what breaks outside that envelope looks nothing like the problems they solve. The DMAIC framework is explained in detail below. But it means more if you already know where it runs out of road.
What Six Sigma in Project Management Actually Is
Bill Smith developed Six Sigma at Motorola in 1986 to reduce manufacturing defects. The name refers to a statistical target: a process running at six standard deviations from its mean produces roughly 3.4 defects per million opportunities. Motorola’s problem was specific — circuit boards with too many manufacturing defects — and Six Sigma was a specific solution to it.
Jack Welch adopted it at GE in 1995, trained roughly 100,000 employees, and tied executive compensation to Six Sigma certification. The methodology spread from manufacturing into finance, healthcare, logistics, and eventually into project management. It combines statistical process control with quality management discipline — the goal is measurable, quantifiable improvement rather than general “we’re doing better” claims.
Six Sigma implementations and projects aim to reach specific targets such as reducing direct and indirect costs, decreasing defect rates, and increasing process consistency. Each project has specifically defined steps and targets.
There are two primary methodologies — DMAIC for improving existing processes, DMADV for designing new ones. Both are covered below. But first, the GE case, because it’s the most documented example of six sigma in project management at scale, and it tells you things the training materials don’t.
Six Sigma in Project Management: The GE Case- Both Halves of the Story
GE’s Six Sigma program under Welch produced real results. By 1997, GE was reporting over $300 million in annual savings. The number was credible — GE Capital and GE’s manufacturing businesses used Six Sigma tools to reduce error rates, cut rework costs, and standardize processes that had been inconsistently executed across large organizations. Welch’s 1999 annual report stated:
GE Capital’s process improvement programs and manufacturing quality initiatives produced real, credible results. Repeating processes, measurable outputs, stable operational environments — that’s where DMAIC earned its reputation. The $300 million in savings Welch reported by 1997 wasn’t fiction.
The problems emerged under Jeff Immelt, who succeeded Welch in 2001. GE was trying to build new businesses — renewable energy, advanced manufacturing technology, healthcare technology — that required different capabilities than process optimization. A 2012 analysis in Bloomberg Businessweek reported that GE’s R&D investment had declined relative to technology-sector peers during the years of peak Six Sigma emphasis. Researchers and former GE executives noted that a culture built around measuring and optimizing existing processes tends to underinvest in the messy, unmeasurable early stages of building something new. When “what gets measured gets managed” becomes organizational doctrine, what doesn’t get measured — early-stage innovation, exploratory R&D, market intuition — tends to shrink.
GE’s problems were bigger than any methodology. But the Six Sigma experience there is still instructive for project management: the tools are excellent at extracting more performance from known processes. They’re a poor primary framework for navigating uncertainty, building new capabilities, or moving into unfamiliar markets. Project work sits closer to that second category than training materials tend to acknowledge — which is worth knowing before you commit to a full DMAIC structure on a project where the requirements are still shifting.
DMAIC: The Five Phases
DMAIC is the Six Sigma framework for improving existing processes. Five phases in sequence.
Define: Identify the problem, the project goals, and the customer requirements. In project management terms this maps to scope definition — what are we improving, for whom, and what does success look like. The Define phase is where most teams are comfortable; it resembles planning work they already know how to do.
Measure: Establish baseline process performance using data. This is where six sigma in project management most consistently struggles. Measuring a manufacturing line that runs thousands of cycles per day is straightforward. Measuring project management processes — approval cycle times, rework rates, scope change frequency — requires that reliable measurement systems already exist. Most don’t. The temptation, which I’ve given into more than once, is to declare the baseline “good enough” from a few weeks of observation and move to Analyze. That decision tends to haunt the rest of the project. The analysis is only as solid as the measurement underneath it, and a shaky Measure phase means you’re often fixing the wrong thing with high confidence.
Analyze: Identify root causes of defects and variation. With solid Measure data, this is where the real insight emerges. Fishbone diagrams, regression analysis, hypothesis testing — these tools separate signal from noise in process performance data. Without reliable Measure data, they produce sophisticated-looking outputs that aren’t grounded in reality.
Improve: Design and implement solutions. The phase most project teams find satisfying. The risk is arriving here before the analysis is actually solid — which happens more often than the methodology’s advocates acknowledge.
Control: Sustain the improvement after the project closes. More on this below — it deserves more space than the other phases, because it’s where most implementations quietly fail.
The Control Phase — Where Most Projects Quietly Collapse
Every Six Sigma training course covers the Control phase. It gets roughly the same amount of time as Define, Measure, Analyze, and Improve. In practice, this is the phase where six sigma in project management most consistently loses what it gained — not noisily, not at close, but over the months that follow.
The issue isn’t that people don’t understand the Control phase. Most project teams can explain what it’s supposed to do. The problem is that the things Control requires — a named operational owner, running measurement systems, documented procedures that someone actually uses — aren’t automatically produced by the project. They have to be deliberately built, which requires time and scope that typically get compressed in the final push to close.
The first time I watched this fail properly, it was a healthcare process improvement project — reducing medication reconciliation errors in a hospital admissions workflow. DMAIC was the right tool. The Improve phase worked. Error rates dropped measurably during the project. We closed on schedule and the numbers looked good. Eight months later, I got a call from the quality director. The error rate had crept back to within a few percentage points of where it started. The measurement system we’d put in place had stopped running two months after close — the nurse coordinator who was supposed to maintain it had left, nobody had backfilled that responsibility, and nobody had noticed the data stream had gone quiet. The improvement hadn’t failed. The handover had.
In manufacturing and healthcare operations — the sectors where DMAIC is most mature — post-project audits regularly find the same thing: a process was improved during the project, documented at close, and had reverted toward its original performance within six to twelve months. Not because the improvement was wrong. Because nobody was watching. The measurement system that was running during the project — tracking defect rates, cycle times, whatever the relevant metric was — stopped running when the project team moved on and the operational team didn’t pick it up. By the time the problem reappears on someone’s priority list, it often gets framed as a new problem rather than a relapse of a solved one.
The Improve phase produces something visible — a changed process, a new standard, a trained team. The Control phase is supposed to produce the conditions under which that improvement survives. But “conditions under which something survives” is harder to demonstrate at a project review than a documented process change, so Control tends to get compressed. Projects that are evaluated at close on deliverable quality have a built-in incentive to underinvest in post-close sustainability. You can show the sponsor a new process map. You can’t easily show them a monitoring system that will still be running in eight months.
DMADV: For New Processes
DMADV — also called DFSS, Design for Six Sigma — applies when you’re creating a process from scratch rather than improving an existing one. Five phases: Define, Measure, Analyze, Design, Verify.
Where DMADV fits project management more naturally than DMAIC: it’s explicitly about creating something new, which is what projects do. The Verify phase is the equivalent of DMAIC’s Control phase, and carries the same handover risk. A project that verifies the design works technically but hasn’t confirmed the operational team is equipped to sustain it independently has stopped before the methodology is complete.
The rough guide: if the process exists and is underperforming, DMAIC. If it doesn’t exist, or if the analysis phase keeps pointing at structural causes rather than operational ones, DMADV — even though redesign is more disruptive. The boundary between these isn’t always obvious. A process that’s been running badly for years might look like an improvement candidate but actually need a rebuild. The Analyze phase usually makes this clearer, which is another reason not to shortcut it.
| DMAIC | DMADV | |
|---|---|---|
| Use when | Process exists and needs improvement | New process, or existing one needs full redesign |
| Starting point | Baseline data from current process | Customer requirements and design targets |
| Common failure point | Control phase — improvement doesn’t survive project close | Verify phase — operational handover is incomplete |
The Belt System and What It Does to Team Dynamics
Six Sigma uses a hierarchy borrowed from martial arts: White Belt (basic awareness), Yellow Belt (project team participant), Green Belt (improvement project lead, part-time), Black Belt (full-time Six Sigma project lead, statistical expert), Master Black Belt (trains and coaches Black and Green Belts, shapes organizational quality strategy).
The hierarchy functions well as a signal of capability: these people know these tools, so involve them in quality decisions. It starts causing problems when it becomes a status structure that concentrates analytical authority in one or two people while the rest of the team becomes observers rather than participants.
The dynamics shift when a Black Belt joins an existing project team that has been working together for months. The Black Belt has genuine expertise in Six Sigma tools the team doesn’t have. But the team has context the Black Belt doesn’t have — the history of previous attempts to fix this problem, the organizational dynamics around why certain solutions have been resisted, the practical constraints that don’t appear in any process document. If the working pattern settles into “the Black Belt analyzes and the team implements,” the team’s contextual knowledge gets underused at exactly the moment it matters most.
The belt system works best when it defines who leads which conversations, not who gets to think. A Green Belt running a quality workstream within a larger project, with clear scope and decision authority within that stream, is a productive configuration. A Black Belt parachuted in to “do the Six Sigma work” while the project manager handles everything else creates two parallel tracks with unclear authority between them — and a team that feels supervised rather than engaged.
Six Sigma in Project Management vs Agile
The tension between Six Sigma and Agile approaches comes down to timing. Six Sigma says: measure the current state thoroughly before improving anything. Agile says: improve through iteration, measure the impact, adjust.
In a software team releasing every two weeks, full DMAIC would require establishing a defect baseline across multiple release cycles before making any process changes. By the time the baseline is statistically valid, three or four months have passed. The team has been watching metrics instead of improving the process. The defect rate hasn’t changed. This is analysis paralysis, and it’s a real failure mode when Six Sigma is applied rigidly to fast-moving project environments.
The resolution isn’t to abandon measurement. It’s to right-size it. Using control charts and Pareto analysis within sprint retrospectives — to identify patterns across iterations rather than requiring a separate DMAIC cycle before any change can be made — is more practical than treating the full methodology as mandatory for every quality problem. It requires judgment about what level of rigor the situation actually warrants, which is uncomfortable for organizations that adopted Six Sigma precisely to avoid judgment calls.
Lean Six Sigma
Lean and Six Sigma address different problems. Lean eliminates waste — steps that consume resources without adding value. Six Sigma reduces variation — ensures the process produces consistent output within specification. Lean makes processes faster. Six Sigma makes processes more reliable. Lean Six Sigma (LSS) combines both, which is why it’s become the dominant form in industries like healthcare and manufacturing where both waste and variation are significant problems.
The LSS toolset — value stream mapping, statistical process control, fishbone diagrams, control charts, Pareto analysis — is applicable in project quality management regardless of whether the project formally adopts the LSS label. Project managers who understand how to use these tools during project execution are applying Six Sigma thinking without necessarily running a formal DMAIC program.
When Six Sigma Fits and When It Doesn’t
Six sigma in project management works best when three conditions are present: a repeating process with enough cycles to generate meaningful data; sufficient organizational stability to let measurement cycles run; and genuine commitment to the Control phase, not as documentation but as a substantive scope item with a named owner and post-close review.
It fits poorly in three situations. One-time projects with unique deliverables — a building, a custom system integration — have no repeating process to measure. Small projects with short timelines can’t generate the data volume that makes statistical analysis valid. Innovation projects, as the GE experience illustrates, require building capabilities that don’t yet exist rather than optimizing ones that do — and Six Sigma’s measurement orientation creates pressure toward the measurable at the expense of the exploratory.
The most common misapplication in practice: organizations adopt Six Sigma vocabulary and belt certifications without building the measurement infrastructure the methodology actually requires. The result is DMAIC project structure applied to problems where the Measure phase is skipped or rushed, producing improvement claims that are hard to verify and don’t survive post-project scrutiny. Six Sigma adopted as a management signal — “we take quality seriously” — without the underlying data discipline produces exactly the kind of superficial improvement theater that the methodology was designed to replace.
See Also
Six sigma method and its applications conference paper
Over 20 years in portfolio management, streamlining business processes, and systems integration. Utilizing best practices: PMI, Scrum, Agile, Kanban, Lean/Six Sigma, CMMI, ITIL and MOF. Extensive experience in managing in cross functional environment, getting to the root of the problem, bringing stakeholders together to resolve them. Vice President at Force3M Training.
