There’s a lot of jargon in this field, and most of it exists to make straightforward ideas sound complicated.
The Lean vs Six Sigma question comes up in almost every first conversation we have about improvement work, and it is usually framed as a choice of philosophy. It isn’t. Underneath the belts, the acronyms and the certification industry, Lean and Six Sigma are two methodologies that solve two genuinely different problems. Knowing which problem you have tells you which one you need.
Lean attacks waste. Six Sigma attacks variation. If you pick the wrong one, you spend months fixing something that wasn’t broken.
Lean: the problem is that things take too long
Lean came out of Toyota’s production system and it has one central question. Of everything happening in this process, how much of it does the customer actually value?
The answer, almost always, is: less than you’d think. Lean categorises the rest as waste and sets about removing it – waiting, unnecessary movement, over-processing, excess inventory, defects, overproduction, and unused talent.
Choose Lean when the symptoms are about time and flow. Jobs sitting in queues. Long lead times that can’t be explained by the actual work involved. People busy but output low. Bottlenecks that move around the business. Too many approval steps.
Lean tends to deliver visible results quickly, because removing a delay is usually simpler than eliminating a defect. It’s also more intuitive for teams, since most people can point straight at the parts of their job that feel pointless.
Six Sigma: the problem is that results are inconsistent
Six Sigma came out of Motorola and later General Electric, and its central question is different. Why does this process produce a different result each time it runs?
It is fundamentally statistical. It measures variation, identifies the causes, and reduces them until output becomes predictable. The structure most people encounter is DMAIC — Define, Measure, Analyse, Improve, Control.
Choose Six Sigma when the symptoms are about quality and predictability. The same job takes four hours one week and eleven the next. Defect rates that nobody can explain. Customer complaints clustering around one output. Estimates that are reliably wrong. Rework as a routine cost of doing business.
Six Sigma is slower and more data-hungry than Lean. It needs enough historical data to establish what normal actually looks like, which is why it works better in higher-volume, repeatable operations than in bespoke, one-off work.
Lean Six Sigma: when you have both problems
Most businesses do have both. Lean Six Sigma combines the two — using Lean to strip out waste and speed up flow, and Six Sigma to make what remains consistent.
The combination works because the two methods cover each other’s blind spots. Lean can make a process fast and still unreliable. Six Sigma can make a process beautifully consistent at doing something unnecessary.
A fast process that produces the wrong answer is not an improvement. Neither is a perfectly consistent process nobody needed.
Used together, the sequence usually runs Lean first, then Six Sigma. Remove the waste, because there’s no point statistically optimising steps you’re about to delete. Then reduce variation in the steps that remain.
Which to use – a quick diagnostic
| If your main complaint is | Start with | Because |
|---|---|---|
| “Everything takes too long” | Lean | The problem is flow, not quality |
| “We never know what we’ll get” | Six Sigma | The problem is variation, not speed |
| “Both, honestly” | Lean Six Sigma | Sequence Lean first, then Six Sigma |
| “We don’t have the data” | Lean | Lean needs observation; Six Sigma needs history |
| “It’s a one-off, bespoke process” | Lean | Six Sigma struggles with low-volume, high-variation work |
What a first project looks like in practice
For a business that has never done structured improvement work, the shape of a sensible first project is fairly consistent.
Scope it small. One process, ideally one that crosses no more than two departments. Ambitious first projects tend to stall because they require agreement from too many people who were not involved in the diagnosis.
Give it a baseline. Two to three weeks of measurement before anything changes. This feels like delay. It is the thing that later allows anyone to prove the project worked.
Involve the operators. The people who run the process daily should be in the room for the analysis, not briefed on the outcome. This is the single strongest predictor of whether the change survives.
Set a review date. Not a completion date – a review date, three months after implementation, when someone checks whether the improvement is still in place.
A first project run this way typically takes eight to twelve weeks end to end and delivers a modest, provable result. That is exactly what you want, because the purpose of the first project is not the saving. It is establishing that the method works here, so the second one gets support.
What actually matters more than the methodology
Now the uncomfortable part.
In our experience, the choice of methodology is nowhere near the biggest determinant of whether improvement work succeeds. We have seen well-run Lean projects deliver lasting change and textbook-perfect Six Sigma projects deliver a folder nobody opened again.
What separates them is almost always the same three things.
Measurement before you start. Without a baseline you cannot prove improvement, which means you cannot defend the investment or repeat the success. The RICS Construction Productivity Report 2026 found 22% of UK construction firms never measure productivity at all – and that pattern is not unique to construction.
Ownership after you finish. Every improved process needs a named person responsible for it staying improved. Processes drift back by default.
Involvement of the people doing the work. Improvement designed in a meeting room and handed down gets quietly ignored. The people running a process already know where it fails; they’ve usually never been asked.
Get those three right and either methodology will work. Get them wrong and neither will.
A note on where these methods struggle
Both approaches came out of manufacturing, and it shows.
In high-volume, repeatable operations, they work extremely well. In professional services, bespoke construction, or any environment where every job is genuinely different, the tools need adapting rather than applying wholesale. Statistical process control is not much use on a sample of eleven.
That does not mean the thinking doesn’t transfer — the core questions about waste, flow and variation are universal. It means being sceptical of anybody who arrives with a fixed toolkit and no interest in whether your work is repeatable enough to justify it.
Do you need people certified?
Belts – yellow, green, black – are a training framework, not a qualification to practise. They’re genuinely useful for building internal capability, and if you intend to run continuous improvement as an ongoing discipline rather than a one-off project, training your own people is the sensible route.
But certification isn’t a prerequisite for getting started. Plenty of valuable improvement work happens with nobody in the room holding a belt of any colour.
If you want the fuller picture on how the methodology works in practice, our Lean Six Sigma beginners guide → /lean-six-sigma-a-beginners-guide covers the fundamentals in more detail.
Starting sensibly
Pick one process. Preferably one that irritates everybody and matters commercially. Measure how it currently performs — how long it takes, how often it goes wrong, what that costs.
Then ask which of the two questions above describes your problem. Is it slow, or is it unpredictable?
You’ll usually know within a day, and that answer is worth more than any amount of methodology selection in the abstract.
Explore our business process improvement → /business-improvement service, or talk to us → /contact about which approach fits your operation.