Lean Six Sigma: the discipline, and what it takes to do properly

Lean Six Sigma is a method for improving work that repeats. It is made of two disciplines that spent twenty years apart before anyone joined them. Lean, out of Toyota, goes after waste and delay: the queues between steps, the batching that suits the department rather than the customer, the rework, and the approvals nobody can justify. Six Sigma, out of Motorola in the mid 1980s, goes after variation: why the same process gives a different answer on a different day, and which inputs are actually responsible.

The combination exists because organisations rarely have only one of those problems. A process can be fast and wrong, or correct and glacial, and the people inside it experience both as the same complaint. Lean alone speeds up a process that still produces the wrong answer. Six Sigma alone perfects a step that should have been deleted. Together they are the minimum honest response to a real operation.

Everything that follows is the practice rather than the theory: what it fixes, how it runs, what it costs you in time and attention, and the situations where it is the wrong tool and should be refused.

The spine is DMAIC: Define, Measure, Analyse, Improve, Control. Define states the problem, the customer and the boundary, and it is where most projects are lost, because a problem defined as "the department is underperforming" can be neither measured nor finished. Measure establishes the baseline before anything changes, which is the rule that stops a project from later reconstructing its own starting point from memory.

Analyse finds the causes and tests them, and it is the phase people want to skip, because by then everyone in the room believes they already know the answer. Improve designs the change, pilots it, and measures it against that baseline. Control is the phase that separates this from a workshop: the new way is documented, the measurement continues, and somebody owns the chart that will show if it slips.

In practice the five phases arrive on the site as five stages, Dream It, Evaluate It, Learn It, Build It and Scale It, because that is the language clients actually use in the room. The sequence underneath is unchanged. What changes is who is doing the work: by Scale It the improvement is being run by your people, and the consultant has become the least important person in the process.

There is a second sequence, DMADV, for when the process does not exist yet or is beyond repair. The test for choosing is simple. If the current process could meet the requirement on a good day, improve it. If it could not meet the requirement even at its best, design a new one.

Time first. A tightly scoped kaizen runs in a week. A normal improvement project runs three to six months, and the binding constraint is data rather than effort, because the measure phase has to wait for enough real observations to say anything honest. A project crossing several departments takes longer, and most of the additional time goes on agreement rather than analysis.

People next, and this is where programmes usually fail. A project needs somebody inside the organisation with real time allocated to it, not an extra duty added to a full week. It needs a sponsor senior enough to change something outside their own department. It needs the people who do the work in the room when the process is mapped, because the procedure manual is not the process and they are the only ones who know the difference.

Money depends entirely on scope, and anyone quoting a figure before seeing the process is guessing. The honest frame is comparison: price one week of delay in the process, then compare that with the cost of removing it. That number is usually decisive, and it is also the number almost nobody has to hand at the first meeting. Getting it is often the first useful output of a discovery call, which is free and takes half an hour.

A method is only trustworthy when the people selling it will name its limits, so here are four.

Novelty. DMAIC improves a process that already runs. If the thing does not exist yet, if the market is unknown, or if the answer is a genuine invention, the measure phase has nothing to measure and the rigour becomes theatre.

Emergency. If the building is on fire, stabilise it first. A structured project running alongside the recovery is sensible. A structured project instead of the fire extinguisher is negligence.

Variation worth keeping. Not every difference in how people work is waste. Judgement at a bedside, care in a difficult conversation, craft in a piece of design: script those and you get compliant, hollow work. The test is never whether a thing can be standardised, but whether the variation in it harms the customer or serves them.

A problem that is really about power. Some processes are slow because two directors disagree, and no amount of mapping fixes that. It is better to say so at the start than to spend three months proving it with charts.