Six Sigma Foundations — Part 1 of 5
I’ve spent close to two decades leading support and customer experience operations — global teams, multi-timezone environments, high-volume contact centres, enterprise SaaS, fintech, everything in between. I’ve inherited broken processes, built new ones from scratch, and spent a lot of time putting out fires that never should have started.
For a long time, I approached process improvement the way most support leaders do: instinctively. Something breaks, you fix it. A metric drops, you dig into the queue. You have a bad week with CSAT and you run a coaching session. There’s nothing wrong with that approach — experience and instinct matter — but it has a ceiling. And I hit it more than once.
Six Sigma changed that. Not overnight, and not without effort, but it gave me a systematic language and methodology for improvement that I’d been improvising around for years without realizing it.
If you’ve heard the term and always assumed it was a manufacturing thing — something for factory floors and automotive plants — I get it. That’s where it came from. But I’m here to tell you that it’s one of the most transferable frameworks in existence, and it fits support operations almost perfectly once you know where to look.
This post is the first in a five-part series. We’ll cover the full Six Sigma toolkit: the DMAIC framework, control charts, root cause analysis tools like the 5 Whys and fishbone diagrams, the PDCA cycle, and finally the control phase and how certifications work if you want to go deeper. I’ll share how I’ve applied each of these across my career and what actually changed because of it.
But first — what is Six Sigma, and where did it come from?
A Brief History (the 90-Second Version)
Six Sigma was developed at Motorola in the mid-1980s by engineer Bill Smith. The core idea was to dramatically reduce manufacturing defects by measuring and controlling process variation. “Six Sigma” refers to a statistical target: achieving no more than 3.4 defects per million opportunities (DPMO). Six standard deviations (sigma) between the process mean and the nearest specification limit. In practical terms, it means getting very, very close to perfect.
Jack Welch made it famous when he mandated Six Sigma across all of GE in 1995. By the early 2000s it had become one of the most widely adopted quality management systems in the world, across manufacturing, healthcare, finance, logistics, and yes — eventually — service and technology operations.
The American Society for Quality (ASQ) defines Six Sigma as “a disciplined, data-driven approach and methodology for eliminating defects in any process.” That word “any” is doing a lot of work. Any process. Including yours.
I’ve written about Six Sigma before in some of the older posts in this archive — including a foundational piece on the basics and a follow-up on how the methodology sustains improvement over time. This series goes deeper and is written squarely from my experience applying it in support and CX environments.
What Does “Six Sigma” Mean in a Support Context?
When I first started applying Six Sigma thinking to support operations, the translation exercise was important. In manufacturing, a “defect” is a product that doesn’t meet spec. In a contact centre or support environment, defects are everywhere once you start looking:
- A ticket that requires more than one touch to resolve (failed first contact resolution)
- A customer who waited longer than your SLA committed
- A chat interaction that ended without the issue being logged
- An escalation that happened because a frontline agent didn’t have the right knowledge
- A report that was produced manually because the data wasn’t in the right place
The DPMO framework applies just as cleanly. If you handle 50,000 tickets a month and 2,400 of them breach your SLA, your DPMO is 48,000 — nowhere near Six Sigma. That’s not a failure; it’s a starting point. Measurement is where everything begins.
The point isn’t to achieve 3.4 defects per million from day one. The point is to establish a rigorous, data-driven method for understanding where your defects come from and systematically reducing them. Even moving from 3 Sigma (66,807 DPMO) to 4 Sigma (6,210 DPMO) is a transformational improvement in a support environment.
How I First Encountered Six Sigma
I came to Six Sigma the way most practitioners do in service environments: sideways. I wasn’t in a formal program. I wasn’t studying for a belt. I was leading a support team that had a chronic first contact resolution problem — we knew the number was bad, we kept talking about it in leadership meetings, and we kept making changes that didn’t stick.
A colleague suggested I look at DMAIC — the core Six Sigma problem-solving framework — as a way to structure the analysis. I read enough to understand the basics, ran the team through a Define/Measure/Analyze cycle, and the root causes we surfaced were completely different from what we’d been assuming. We’d been solving the wrong problem. The fix we implemented based on the actual data lasted.
That was the moment. I went back and formalized my knowledge, eventually earning my Six Sigma Green Belt certification, and I’ve applied the methodology — formally and informally — to almost every significant process improvement initiative I’ve led since. You can read more about the broader career context in What 19 Years of Support Leadership Actually Taught Me.
The Core Concepts You Need to Know
Before we dive into specific tools in the posts that follow, here are the five foundational ideas that underpin everything in Six Sigma:
1. Variation is the enemy. Every process has variation. Some of it is natural and expected (common cause variation). Some of it is caused by specific, identifiable factors (special cause variation). Six Sigma is fundamentally about distinguishing between the two and eliminating special cause variation while reducing common cause variation over time. We’ll go deep on this when we cover control charts in Part 3.
2. Decisions require data. Opinion and experience have a place at the table, but they don’t get the final vote. The discipline of Six Sigma insists on measurement before action. As I’ve written before, choosing what to measure is itself a strategic decision — and one most organizations make too casually. You need to know your baseline before you can know whether you’ve improved.
3. Processes, not people. One of the most important cultural shifts Six Sigma drives is moving from blaming individuals to examining systems. When a metric is consistently off-target, the process is almost always the culprit — not the people running it. This is liberating for teams and more accurate in practice.
4. Customer-defined quality. Everything traces back to what the customer actually needs. Six Sigma borrows the concept of “Critical to Quality” (CTQ) characteristics from manufacturing — the attributes of your output that matter most to the customer. In support, those are things like resolution time, issue accuracy, and ease of contact. A robust Voice of the Customer program is an important input to this thinking.
5. Sustained improvement requires control. Improvements decay without deliberate maintenance. Six Sigma builds the control phase directly into its methodology — we’ll cover this in Part 5 of this series.
What This Series Covers
Here’s where we’re going over the next four posts:
- Part 2: DMAIC — The Framework Behind Every Process Improvement I’ve Made — A deep dive into the Define, Measure, Analyze, Improve, Control framework with real support operations examples.
- Part 3: Reading the Data — Control Charts and Statistical Process Control for Support Leaders — How to build and interpret control charts, understand process stability, and use data to separate noise from signal.
- Part 4: Finding the Root Cause — 5 Whys, Fishbone Diagrams, and the 7 Quality Tools — The diagnostic toolkit: how to stop solving symptoms and start solving causes.
- Part 5: The Control Phase, Sustaining Improvements, and Your Six Sigma Journey — How to make sure your improvements actually stick, plus an overview of Six Sigma certifications if you want to go further.
If you’ve been working in support operations for any length of time, you already do some version of this thinking. Six Sigma gives you the scaffolding to do it more consistently, more rigorously, and with results that last.
Already working with ITIL and using SLA management as a core discipline? You’ll find Six Sigma slots in naturally alongside those tools — it answers a different question. ITIL tells you what your processes should look like; Six Sigma tells you how well they’re actually working. They’re complementary, not competing. The Continual Service Improvement stage of ITIL and Six Sigma’s continuous improvement mandate are essentially two descriptions of the same mandate — one framework gives you the structure, the other gives you the measurement engine.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.