Six Sigma Foundations — Part 5 of 5
We’ve reached the end of the series. If you’ve followed along from Part 1 through Part 4, you now have a solid foundation in Six Sigma as a discipline: what it is, how DMAIC structures the improvement process, how control charts help you read your data, and how root cause analysis tools help you find what’s actually broken.
This final post is about what happens after you fix something — and why that matters just as much as the fix itself. We’ll cover the Control phase of DMAIC in depth, look at the tools I use to ensure improvements are sustained in support environments, and close with a practical guide to Six Sigma certifications if you want to formalize your knowledge.
Why the Control Phase Is the Most Important Phase Nobody Talks About
Every major DMAIC project I’ve run follows the same pattern through the first four phases: there’s energy in the Define phase, insight in the Analyze phase, and genuine excitement in the Improve phase when the data confirms the improvement is real. And then the project winds down. The team disperses. Everyone moves on to the next thing.
Six to nine months later, someone runs the numbers and the metric is quietly back where it started.
This is the single most common failure mode in process improvement — in any industry, not just support. Improvements are real but not sustained. And the reason is almost always the same: the Control phase was treated as a formality rather than a foundational component.
The Control phase answers one question: how do we ensure this process continues to perform at its improved level after the project team is gone?
The answer requires deliberate design, not good intentions.
The Control Plan
The primary deliverable of the Control phase is the control plan — a living document that specifies:
- What to monitor: The key output metrics established during the Measure phase (FCR rate, SLA compliance, handle time, etc.)
- How to monitor it: The specific measurement method, data source, and frequency
- Control limits: The UCL and LCL from your post-improvement control charts (covered in Part 3)
- Response plan: The specific action to take if a metric crosses a control limit or exhibits a non-random pattern
- Responsible owner: The named individual accountable for monitoring each metric and executing the response plan
That last element is more important than it sounds. One of the most common Control phase gaps I’ve seen is a control plan that specifies what to monitor but not who is accountable for acting on it. If accountability is diffuse, the monitoring will be inconsistent and the response plan will never be triggered.
A control plan doesn’t need to be complicated. I’ve run effective control plans on a single spreadsheet tab that a team lead reviews in 15 minutes each Monday morning. What matters is that it’s structured, documented, and owned.
Ongoing Control Charts: The Early Warning System
The most important operational tool in the Control phase is the ongoing control chart — the same tool we covered in depth in Part 3, now reconfigured with post-improvement control limits and maintained as a routine monitoring instrument rather than a project-phase deliverable.
When I implement ongoing control charts in a support environment, I make a point of training the people who will be reading them — not just the leaders, but the team leads and senior agents who interact with the metrics daily. The goal is to build a shared language around process stability so that the question “is this a signal or noise?” becomes a natural part of how the team talks about performance.
This is a cultural shift as much as a technical one. Teams that have internalized the signal/noise distinction stop overreacting to every metric fluctuation and start investigating the ones that actually warrant investigation. That’s a more effective team — and a less anxious one. It also changes how KPIs function as management tools — they stop being scorecards that prompt reactive explanations and start being instruments that guide deliberate action.
In practice, I typically review control charts weekly with team leads and monthly with broader stakeholders. The weekly review is operational: are we in control? Did anything trigger the response plan this week? The monthly review is strategic: is there a pattern emerging that suggests the process is drifting?
Standard Operating Procedures: Locking In the New Normal
An improvement that isn’t documented in an updated SOP doesn’t exist in six months. People leave. Processes drift toward informal norms. New team members are onboarded to the old way because that’s what they were taught.
Part of every Control phase I run involves updating or creating the SOPs that govern the improved process. This isn’t glamorous work. But it’s the difference between an improvement that outlasts the project and one that doesn’t.
A few principles I apply to SOP updates in the Control phase:
Keep them actionable, not aspirational. An SOP that says “agents should strive to provide high-quality responses” is not an SOP — it’s a value statement. An SOP that says “agents must confirm the issue is fully resolved before moving a ticket to Resolved status by following these three verification steps” is something people can actually follow.
Build the SOP into the workflow, not alongside it. Wherever possible, encode the correct behavior into the system itself so that doing the right thing is the path of least resistance. Which brings us to the next tool.
Integrate your SOPs with your training program. When I rebuilt the training curriculum at AudienceView — creating what we called AudienceView University, a structured L1→L3 certification track — updated SOPs were the content that training was built around. The datadrivenops.co case study on that transformation covers how the training design and process changes were deliberately aligned. It’s also covered in depth on the training and enablement pillar of that site if you want to go deeper on how to structure support training for capability retention.
Poka-Yoke: Designing Error Out of the Process
Poka-yoke is a Japanese term — roughly translated as “mistake-proofing” — developed by industrial engineer Shigeo Shingo as part of the Toyota Production System. The idea is to design processes so that errors are either impossible or immediately detectable.
In support operations, poka-yoke doesn’t mean building factory safety guards. It means designing your systems, workflows, and interfaces so that the correct behavior is enforced rather than assumed.
Examples I’ve implemented or overseen:
- Mandatory fields at ticket closure that require agents to categorize the root cause before a ticket can be resolved — eliminating the “uncategorized” bucket that makes analysis impossible and ensuring clean data for future Pareto analysis.
- Automated escalation triggers that fire when a ticket exceeds a time threshold without a required touchpoint — so SLA breaches from inaction are caught before they happen.
- Required confirmation macros in chat tools that prompt agents to verify resolution before ending a session — reducing premature closures and improving FCR data accuracy.
- Workflow gates in onboarding processes that require sign-off from a knowledge check before agents are released to handle certain ticket categories independently — a version of the tiered certification model I’ve built at multiple organizations.
None of these are technically complex. All of them eliminate a category of human error by making the error structurally difficult rather than relying on memory, vigilance, or good intentions. The best poka-yoke solutions are invisible in normal operation — they only become apparent when someone tries to do the wrong thing.
Visual Management and Dashboards
The Control phase also benefits significantly from visual management — making process health visible to the people who influence it, in real time, without requiring them to seek out the information.
In a support environment, this typically means:
- A team-facing dashboard showing key metrics (FCR, SLA compliance, CSAT, handle time) updated in real time or near-real time
- A clearly marked “target zone” on the dashboard so every agent and team lead knows at a glance whether performance is within the expected range
- Escalation signals (color changes, alerts) when metrics cross defined thresholds
The work of building dashboards that actually get used and trusted — rather than dashboards that get filed away — is something I cover in detail on the BI & Dashboards pillar at datadrivenops.co, including the customer journey dashboard case study that walks through a multi-source ETL build across CRM, PSA, and SharePoint into Snowflake. The principles are the same whether you’re building Tableau dashboards or a simple Excel report: the chart needs to drive a decision, or it’s just decoration.
Transitioning the Process to Its Owner
One final element of the Control phase that’s often overlooked: the formal handoff from the project team to the process owner.
In a DMAIC project, there’s a moment when the project team is done — and someone else takes on permanent ownership of monitoring and maintaining the improved process. That transition should be explicit and documented. The handoff should include:
- A briefing on what was changed and why
- A copy of the control plan with all response procedures documented
- Access to the ongoing control charts and the baseline data
- Clear understanding of their accountability going forward
If this handoff isn’t structured and documented, accountability tends to evaporate. The control plan exists but nobody checks it. The control chart is set up but never reviewed. The improvement decays — not because it failed, but because no one was watching.
Six Sigma Certifications: A Plain-English Guide
If you’ve read through this series and you want to build a more formal foundation in Six Sigma, certification is the most structured path. Here’s an honest overview of how the belt system works and what each level represents in practice.
White Belt The entry point. White Belt training provides a high-level overview of Six Sigma concepts — enough to understand the language and participate in improvement projects, but not to lead them. Typically one to two days of training. Good for: team members who will participate in Six Sigma projects, managers who want foundational awareness.
Yellow Belt A step up from White Belt, with more depth in the core tools. Yellow Belt holders can support project teams and lead small-scope improvement efforts. Typically three to five days of training plus an exam. Good for: team leads, senior agents, support managers leading localized process improvements.
Green Belt The first level at which practitioners can independently lead DMAIC projects. Green Belt training covers the full DMAIC methodology, core statistical tools (including control charts and basic hypothesis testing), and root cause analysis tools. Requires demonstrated project work in most certification bodies. Typically 80–120 hours of study plus exam plus project. Good for: operations managers, QA leads, support directors leading multi-function improvement initiatives. This is the level I earned, and the one I’d recommend as the target for most support leaders who want to apply Six Sigma rigorously.
Black Belt The advanced practitioner level. Black Belts lead complex, cross-functional DMAIC projects and typically coach Green Belts. Deep statistical knowledge required — design of experiments, regression analysis, advanced hypothesis testing. Requires significant project experience and a formal exam. Good for: dedicated improvement leads, operations excellence directors, anyone in a formal continuous improvement function.
Master Black Belt The highest level. Master Black Belts design Six Sigma programs, train and certify Belts, and lead enterprise-wide improvement strategy. Not a certification most support leaders need unless CI is your full-time role.
Where to get certified:
The two most recognized certification bodies are:
- ASQ (American Society for Quality) — The gold standard for quality certifications globally. Exams are rigorous and the credentials are widely recognized in enterprise environments.
- IASSC (International Association for Six Sigma Certification) — Body-of-knowledge based, vendor-neutral, no project requirement. More accessible but slightly less recognized than ASQ in some industries.
Many training providers (Villanova University, the Six Sigma Institute, iSixSigma, and others) offer prep courses for both. Lean Six Sigma hybrid certifications (which combine Six Sigma with Lean waste-reduction principles) are increasingly common and often more relevant for service environments.
My recommendation for support operations leaders: start with the Green Belt, target the ASQ certification, and plan to run at least one real project during your training rather than waiting until after. The project is where the learning actually happens.
Closing: The Mindset Behind the Methodology
Looking back over nearly two decades of leading support and CX operations, Six Sigma is one of a small number of frameworks that I’d call genuinely career-changing. Not because of any single technique, but because of the underlying discipline it instills: define precisely before you act, measure before you judge, analyze before you solve, improve based on evidence, and then control to make the improvement last.
Most of us come to support leadership through experience and instinct. Those things matter enormously. But instinct without structure has limits. The combination — experience and data, instinct and method — is where the real leverage is.
The tools in this series aren’t complicated. They’re disciplined. And in an environment that rewards urgency and action, that discipline is hard to maintain. But the leaders and organizations that maintain it consistently are the ones that show up differently in every performance review, every QBR, and every conversation about what support actually delivers to the business.
If you want the broader career context for how I’ve applied all of this — not just Six Sigma, but the full arc of what 19 years in this function actually teaches you — that’s in What 19 Years of Support Leadership Actually Taught Me.
And if you’re curious about the data and operations side of this work — the BI infrastructure, AI implementation, and shared services leadership that underpins the measurement capability Six Sigma depends on — I cover all of that in detail at datadrivenops.co.
The full Six Sigma Foundations series:
- Part 1: Six Sigma for Support Leaders — What It Is and Why It Works
- Part 2: DMAIC — The Framework Behind Every Process Improvement I’ve Made
- Part 3: Control Charts and Statistical Process Control for Support Leaders
- Part 4: Root Cause Analysis — 5 Whys, Fishbone Diagrams, and the 7 Quality Tools
- Part 5: The Control Phase and Six Sigma Certifications (you’re here)
Working within an ITIL framework? Six Sigma’s Control phase maps directly onto the Continual Service Improvement (CSI) stage of ITIL 4. The two methodologies are complementary: ITIL defines the architecture of your service delivery; Six Sigma tells you how well that architecture is performing and what to do when it isn’t. If you haven’t read the piece on ITIL 4’s new way of thinking, it’s a good companion to this series.
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.
