Implementing Six Sigma: Smarter Solutions Using Statistical Methods

By Forrest W. Breyfogle III

13 min read

Why does it matter? Because your dashboards are probably making things worse, not better.

Here's the uncomfortable question nobody in your last strategy meeting asked: what if measuring more carefully and launching more improvement projects is precisely what's keeping your organization stuck? Not because the data is wrong or the teams are lazy — but because the entire act of reacting to your numbers is the problem. Every time a metric turns red and someone scrambles to fix it, you're treating a predictable process like an emergency. You're fighting fires that your system guaranteed would start. Forrest Breyfogle's argument isn't that you need better tools — it's that you've been handed a fundamentally broken philosophy about what management is for. Stop managing outputs. Start managing the system that produces them. Everything else is just expensive noise.

You're Managing the Scoreboard, Not the Game

Hank is three holes into a round of golf, already carding an eight, and somewhere in the back of his mind he's running the same calculation he runs every week at work: if he just tries harder, hits harder, focuses more, the numbers will improve. The ball keeps ending up in the sand. The quarterly report keeps showing a gap between target and actual. The response to both is identical — bear down, set a more aggressive goal, watch the same thing happen again.

Breyfogle calls this Y-Management, and it's more common than any executive wants to admit. The Y is the output: the score on the card, the KPI on the dashboard, the delivery rate in the weekly review deck. The X is everything that actually produces that output — the swing mechanics, the supplier process, the handoff between departments. Most management systems watch the Y obsessively and leave the Xs alone. When the Y looks bad, a goal gets set. When the goal gets missed, a more aggressive goal gets set. The underlying process runs on, unchanged, producing exactly what it was always going to produce.

Breyfogle points to Circuit City, Sears, and Wells Fargo — companies with skilled people, serious intentions, and sophisticated scorecards that still couldn't see their own reality clearly enough to act before the damage was done. Wells Fargo is the sharpest example: the metrics showed account growth, the targets were being hit, and the process producing those numbers was employees opening fake accounts to survive their quotas. The scoreboard looked fine. The game was broken. Manage the Y hard enough and people find ways to make the Y move without touching the process — and you've built an organization optimized for the appearance of performance.

Jorge puts it plainly: a kaizen event that saves ten thousand dollars in one cell while creating a bottleneck in the next one hasn't improved the enterprise. It's just moved the damage.

The alternative isn't softer goals. A Y only changes when an X changes. Every output metric has a process behind it. Until you identify which inputs are driving the result and redesign how the work actually flows, you're not managing a business — you're watching a scoreboard and calling it strategy.

Every Red on Your Dashboard Is Probably a False Alarm

Which means most of what you're reacting to isn't a problem at all.

Most of the red on your dashboard is the process behaving exactly as it always has. Not a signal. Noise. And the moment you call a meeting to address it, you've started firefighting a fire that doesn't exist.

Breyfogle reaches back to a demonstration W. Edwards Deming ran in the 1980s. Deming would bring a volunteer to the front of the room and have them draw colored beads from a paddle — mostly white, some red. The volunteer's job was to draw as few red beads as possible. They couldn't. The proportion of red beads was fixed by the paddle. But Deming would praise them when the count came in low and scold them when it ran high, then ask the audience what exactly the manager had accomplished. Nothing. The process determined the outcome. The manager's behavior was theater.

That experiment is your monthly scorecard. When a metric dips below target in October, the color flips to red. A review gets scheduled. Someone is asked to explain the variance. The explanation is assembled, the corrective action is documented, and by December the metric has drifted back above the line — not because anything changed, but because variation in a stable process oscillates. The number moved. The process didn't. Next quarter, you'll do it again.

Jorge explains the distinction on the golf course using Hank's driving game. Hank averages around 250 yards off the tee with a standard deviation of roughly 15 yards — a consistent, stable process. When a shot lands at 237 yards, that's not a crisis. That's the process. But when Hank snap-hooks a ball into the trees — an outcome so far outside his normal pattern that something genuinely different must have happened — that's worth examining. Common-cause variation is the 237-yard drive: it's in the process, and no amount of post-shot analysis will change the distribution. Special-cause variation is the hook into the trees: it has an assignable reason, and finding it might actually help.

The mistake organizations make, consistently, is treating October's dip exactly like the hook into the trees. Same urgency, same investigation, same pressure to explain — applied to an event that needs none of those things. The corrective action costs real time and real credibility, and it teaches everyone in the organization that the goal isn't to improve the process; it's to have a good story ready when the color goes red.

The Hidden Factory Inside Your 98% Yield

Think of your production line as a restaurant kitchen. The health inspector checks plates leaving the pass, finds 98% spotless, gives you a great score — and never sees the line cooks quietly re-plating dishes before they can be counted.

That's Hank's situation at Hi-Tech Computers. He just doesn't know it until Jorge runs the numbers on a napkin over lunch.

Hank's printed circuit board line runs at 98% yield. He's proud of this. Jorge asks him to think more carefully. Each board has roughly 1,000 solder joints and components, and the facility makes about 5,000 boards a week — five million opportunities for a defect. When Hank's team once ran a thorough engineering study counting every touchup and quiet rework alongside the formal failures, they found 1,250 defects in a single week. Divide by five million opportunities: 250 defects per million, which puts Hank near a five-sigma quality level. He brightens. "With just a little effort, I could be at six sigma."

Jorge's response: not so fast. The 250 DPMO figure sounds impressive, but look at the same data differently. Twelve hundred fifty defects spread across 5,000 boards means one in four boards required some kind of rework before it left the line. A 25% rework rate. That's a second production operation running silently inside the first, consuming labor, machine time, and materials, with none of it visible to anyone watching the yield number.

Breyfogle calls this the hidden factory. It lives in the gap between what the official metric counts and what the process actually does. Yield only captures units that failed final inspection. Everything fixed before that point — the hand-soldered joint, the re-seated component, the board pulled aside for a touchup and quietly returned to the line — never appears. The metric was built to make failures visible, but its construction systematically hides the cost of preventing them.

The practical consequence is that Hank's team has been congratulating itself for a number that says nothing about efficiency, waste, or true process capability. The right measure is what Breyfogle calls Cost of Doing Nothing Differently: a dollar translation of what it costs to keep running the process exactly as it is. In Hank's case, that means pricing out every hour of rework labor, every component touched twice, every machine cycle spent on a board that should have been right the first time — a number that, at his volumes, almost certainly runs into six figures per week. Put that figure in front of leadership and the 98% yield stops looking like an achievement. It starts looking like a baseline for what's being silently accepted.

Local Wins Don't Add Up to Enterprise Results

The setup time on the sheet metal punching press drops from two hours to fifteen minutes. The kaizen team celebrates. Their manager reports the win upward. The savings look real on paper, and the process improvement is genuinely documented. A few weeks later, Hank notices something uncomfortable: the press is now running faster than the downstream assembly station can absorb parts. Work-in-progress inventory is stacking up on the floor between stations. The overall cycle time — the number his customers actually care about, how long from order to delivery — has gotten longer, not shorter. The metric the team improved and the metric the business needed to move turned out to be two different things, attached to two different parts of the system, with no one watching the connection between them.

That's the structural trap beneath most improvement programs. Projects get selected because they're visible, bounded, and winnable. A team improves what they can see and control. They succeed by any reasonable local definition. But the process they improved isn't the whole system — it's one cell in a chain, and making one link faster doesn't shorten the chain if the constraint lives somewhere else. Jorge's read on it: a kaizen event that saves ten thousand dollars in one cell while creating a bottleneck in the next one hasn't improved the enterprise. It's just moved the damage.

What the IEE framework insists on, and what Hank's early Lean deployment skipped entirely, is that projects have to be pulled from the enterprise value chain — selected because improving a specific 30,000-foot-level metric will move a satellite-level financial outcome — rather than pushed by whoever has the budget and enthusiasm to run a kaizen event this quarter. Without that connection, local wins accumulate into a report full of successes that the bottom line never sees.

The Hospital Floor That Changed One Executive's Mind About Systems

Jorge is in the middle of dinner with his wife when his phone rings. A labeling change on saline bags at Harris Hospital — the kind of administrative update that gets approved in a committee meeting and implemented without fanfare — has led to a floor of patients receiving incorrect dosages. By the time he gets to the hospital, the crisis is already in motion: nurses following procedure, equipment functioning as designed, a ward full of patients over-medicated anyway.

His first instinct is what any executive's first instinct would be: find the person who made the error and correct the process around them. But sitting with the facts, Jorge can't make that framing stick. The nurse followed the protocol. The labels were approved. Everyone did what the system told them to do. He finds himself sorting it the way accident investigators sort a crash: was it the pilot? The equipment? Or the system that put them both in that situation? The saline incident isn't the first two. The nurse isn't a pilot who flew into a mountain. The labels aren't a malfunctioning altimeter. The system — the chain of handoffs, approvals, and assumptions connecting a committee decision to a bedside dosage — allowed the failure to travel all the way to the patient without a single checkpoint catching it.

What shifts Jorge's thinking is the arithmetic. A hospital isn't a simple process with one failure mode. It's thousands of procedures, medications, transfers, and decisions happening every day, each one a link in a chain where a break at any point can reach a patient. Given enough links operating long enough, some will fail. Not because the people are careless, not because the equipment is defective, but because that's what probability does inside a complex system that hasn't been designed to contain failures.

The conclusion Jorge can't escape is that replacing the nurse changes nothing. The system that let the error travel all the way to the patient is still intact. The only durable response is designing the process so that errors — which will occur — get caught before they reach the patient. Not optimism. Arithmetic.

A Better Metric Tells You What Will Happen, Not Just What Did

What would a metric look like if it told you what's going to happen next month, instead of demanding an explanation for what happened last month?

Hank's finance team tracks monthly expenses against a $100,000 target. October comes in at $103,000 — the color goes red, a meeting gets scheduled, someone builds a slide explaining the variance, and the action item is to do better in November. November comes in at $98,500 — the color goes green, nobody meets, and nothing in how the work gets done has changed. The scorecard registered two different conditions. The process produced one: stable variation around a mean of roughly $100,400, doing precisely what it was designed to do.

A 30,000-foot-level report on the same data looks different in structure and completely different in what it asks of you. The left side is a time-series chart of monthly expenses. If no point breaks outside the statistically calculated control limits — and no pattern suggests a shift — the process is declared stable. The right side then uses all the data from that stable period to generate a prediction: the expected mean is $100,411, with most months landing between two bands that represent normal variation. No investigation required. The process isn't misbehaving in October; October is just October. The only question the report asks is whether you're satisfied with that prediction. If you're not — if $100,411 is genuinely too high for the business to sustain — then you need to change the process that produces it. Not this month's result. The process.

That shift in framing is the entire game. A red-yellow-green scorecard trains managers to respond to the number. A 30,000-foot-level report trains them to respond to the system. One produces a culture of monthly explanations; the other produces a question with actual leverage: what would have to change in how this work gets done for the prediction to move?

The lead time report makes the distinction sharper. A stable view showing 16.4% of orders missing the 192-hour target means: systemic problem, redesign the process. A sudden shift in the individuals chart — a cluster of points breaking outside the control limits — means something changed, and root-cause analysis of that specific event is the right response. The metric tells you which tool to pick up. A stoplight scorecard just tells you to be unhappy.

Projects Should Be Pulled by What the Business Needs, Not Pushed by the Training Calendar

The mechanism of project selection determines whether a deployment produces lasting enterprise value or a folder full of completed projects that moved nothing. Run enough improvement cycles the wrong way, and the program doesn't fail dramatically — it just quietly stops mattering.

The failure mode Jorge names is precise: a steering committee needs to find projects for next week's Black Belt class. They survey the organization, identify what's visible and bounded, and pick the low-hanging fruit. The first cycle produces real wins. The second cycle produces smaller ones. By the third or fourth cycle, the fruit is gone, the team is reaching, and the projects being approved are technically defensible but strategically irrelevant — saving $10,000 in one cell while a bottleneck builds quietly in the next. Eventually the LSS function gets cut in a downsizing, and what survives is a methodology library no one opens.

The alternative is letting the business pull the projects rather than pushing them from the training calendar. In the IEE framework, the value chain carries 30,000-foot-level metrics for every significant process output. When one of those metrics produces an undesirable prediction — not a bad month, but a stable process trending in the wrong direction — that prediction is the case for a project. The improvement gets pulled by a visible business need, documented in an Enterprise Improvement Plan that shows exactly how the project metric connects to a satellite-level financial outcome. Every Black Belt working on an EIP project knows which number on the executive dashboard their work is expected to move. If the connection isn't there, the project doesn't belong in the plan.

Jorge makes the same move with his golf game before he ever opens a spreadsheet. He doesn't run a statistical analysis — he uses accumulated experience to identify his biggest drag on the scorecard: erratic tee shots. So he leaves the driver in the bag. The driver stays in the bag until the tee shot is worth trusting. Projects work the same way.

The North Wing and South Wing Never Talk — And That's Why Your Scorecards and Your Improvement Programs Both Fail

Project selection is half the problem. The other half is organizational architecture.

Picture a hospital with a performance management team on the north side of the building and a process improvement team on the south side. The scorecard people meet weekly to review metrics. The improvement people run projects and kaizen events. Both functions are busy, both produce outputs — and they almost never speak to each other. Ron, the IEE consultant working with Jorge's team at Harris Hospital, observes that this is not an edge case. It is the standard organizational architecture.

The consequence is structural, not motivational. The scorecard team tracks metrics against targets and reports red, yellow, or green. When something turns red, they escalate. The improvement team, meanwhile, selects projects from whatever the steering committee thinks is important this quarter. There is no mechanism connecting these two activities. Metrics that look bad don't reliably generate projects. Projects that complete don't reliably move the metrics leadership is watching. Both systems run, both produce paperwork, and the financials sit exactly where they were.

The IEE value chain is the fix, and its logic fits in one sentence: every function in the organization is mapped to the metric that measures it, and when that metric produces an undesirable prediction, it pulls a project into existence. The link between measurement and improvement is no longer coincidental — it's load-bearing. A 30,000-foot-level report showing a stable but unacceptable lead time doesn't just inform the scorecard team; it generates a case for an EIP project that the process owner is accountable for closing. The north wing and south wing share a spine.

At Harris, this stops being theoretical the moment CEO Janice Davis bans traditional stoplight scorecards and requires every manager to translate their data into 30,000-foot-level metrics using EPRS software. That's not a training initiative. It's a structural mandate that forces measurement and improvement to speak the same language. None of this happens by accident. Janice Davis made it mandatory. That's the move.

The Only Language That Gets a CEO to Yes Is Money and Pain

Zack spent months assembling balanced scorecard presentations, running steering committee meetings, and building the infrastructure for a structured improvement program. Nothing moved. His CEO nodded politely and kept asking whether the quarterly numbers would recover. Then Zack did one thing differently: he sat down with his finance team and calculated what it actually cost the company to keep running exactly as it was. The answer was 20% of gross income — evaporating every year through rework, lost customers, excess inventory, and slow collections. One number. One meeting. The CEO bought in immediately, and Zack walked out with a promotion to lead the entire corporation's IEE deployment.

Hank, watching this, put it plainly: the universal language of business executives has always been money. Not methodology. Not training proposals. Not the elegance of a roadmap. Money — and the specific pain of watching it drain out of the business while nothing changes.

IEE has a name for this number: the cost of doing nothing differently, or CODND. It's more powerful than traditional quality cost calculations because it doesn't require a specification to be violated. You don't need a defect rate to justify action. The carrying cost of excess work-in-progress is waste whether or not any tolerance has been breached. The revenue lost to slow problem resolution is real whether or not anyone has defined a service-level target. CODND converts the status quo into a monthly invoice, and once a CEO sees that invoice, the conversation stops being about whether to invest in change and starts being about how fast to move.

The practical implication is a sequencing rule: before you explain IEE to an executive, calculate what the current process is costing. Not what the improvement might save — what inaction is already spending. That reframe turns a pitch about a better system into a conversation about a problem they already own. And that conversation is the one that actually ends with a yes.

The Question Worth Carrying Forward

The real indictment buried in Breyfogle's work isn't about statistics — it's about architecture. Somewhere in your organization right now, a group of people is reacting to last month's red lights while a separate group runs improvement projects neither of them selected because the value chain demanded it. Zack's moment — sitting across from a CEO who suddenly couldn't look away from a number representing 20% of gross income quietly leaving the building every year — worked because it stopped being a conversation about a better system and became a conversation about an existing wound. Are you managing the process that generates the scoreboard, or just the scoreboard itself? Until those two activities share a spine, effort is just effort.