Lean Six Sigma becomes unhelpful when the acronym leads and the operational problem follows. We have seen teams begin with a DMAIC template, fill every phase with activity and only later discover that the existing process could never meet the new requirement.
The better starting point is diagnostic: is this a capable process performing poorly, or is the process itself no longer fit for purpose?
Lean and Six Sigma solve related, not identical, problems
Lean examines the flow of value. It draws attention to waiting, rework, excess movement, duplicated handling and other effort that does not improve the outcome for the customer or control the risk.
Six Sigma examines performance and variation. It asks whether the process produces a consistent result, whether the measurement can be trusted and which factors are associated with defects or delay.
Combined well, the disciplines help a team improve flow without losing control and reduce variation without optimising an unnecessary step.
DMAIC vs DMADV: the decision test
| Question | DMAIC is more likely | DMADV is more likely |
|---|---|---|
| Does the process exist? | Yes, and it produces an observable output | No, or a fundamentally new service is required |
| Can the current design meet the requirement? | Probably, if causes of poor performance are removed | Not without changing the underlying design |
| What is the core task? | Find and control causes of waste, defects or variation | Translate requirements into a new operating design |
| What validates success? | Sustained movement from the measured baseline | Verified performance against design requirements |
There is no shame in changing course. If analysis shows the current structure cannot deliver the required outcome, stop treating the issue as an incremental improvement project. Equally, do not redesign a stable process simply because a new platform has arrived.
DMAIC in practice
Define the problem and boundary
Write the problem as an observable gap, not a proposed solution. Name the customer or stakeholder affected, the process boundary and the business consequence. A project framed as “implement automation” has skipped the problem.
Measure what is happening now
Agree operational definitions before collecting data. Decide when a case starts, when it ends, what counts as a defect and how exceptions are classified. Check whether timestamps and categories are reliable enough for the decision.
Analyse causes, not just correlations
Combine the process view with the available evidence. A queue may explain elapsed time; incomplete information may explain the queue. Use 5 Whys, cause-and-effect analysis, data segmentation or formal statistical methods according to the problem and evidence—not because a phase checklist expects them.
Improve with a testable change
Design changes against the verified causes. Pilot when the risk or uncertainty warrants it. Define in advance which measures would indicate improvement and which side effects need watching.
Control through ownership and response
A dashboard is not a control plan. The team also needs an owner, review cadence, decision threshold and response when performance moves outside the agreed range.
DMADV in practice
DMADV starts from requirements rather than inherited steps. It is appropriate for a new operating process, a materially changed service or a current design that cannot meet its critical requirements.
- Define the purpose, customer, scope and design authority.
- Measure needs, constraints and critical-to-quality requirements.
- Analyse alternative designs and the risks each creates.
- Design roles, workflow, information, controls, systems and exception paths as one operating model.
- Verify the design through scenarios, pilots, tests and agreed acceptance measures.
This is especially relevant when a technology migration changes the shape of the work. In our view, a new Microsoft Fabric environment should not simply reproduce every legacy hand-off and reporting habit. The Fabric migration and optimisation case study shows why platform work and operating decisions need to be considered together.
Measurement before improvement claims
The first useful number is often not the result. It is the baseline definition. A percentage improvement is meaningless if the before and after periods use different process boundaries, populations or defect definitions.
Before changing the process, record:
- the unit of work being measured;
- the start and end events;
- the population and exclusions;
- the period and operating conditions;
- the measurement source and known limitations; and
- the person who will interpret and act on the result.
Evidence first: do not borrow a benchmark from another organisation and call it a target. Establish the current performance, understand the required outcome and agree what the process can influence.
Lean Six Sigma and automation
Automation belongs in the Improve or Design work only after unnecessary activity has been challenged. It can remove repeated entry, route work, apply stable rules and create better event evidence. It can also make poor logic run faster and at greater scale.
We use three checks before recommending automation:
- Is the step necessary?
- Is the rule clear enough to execute consistently?
- Can exceptions, ownership and monitoring be designed safely?
Our Power Automate and workflow service therefore starts with the work, not the tool.
Regulated and high-consequence processes
In regulated environments, process improvement must preserve evidence, segregation of duties and decision accountability. Lean Six Sigma can help structure the analysis and control plan, but the method itself does not establish legal or regulatory compliance.
Bring risk, compliance, information security and operational owners into the design when their decisions are needed. A faster process is not an improvement if it weakens a required control or makes an important judgement opaque.
Frequently asked questions
What is the difference between DMAIC and DMADV?
DMAIC improves an existing process with a measurable performance gap. DMADV designs a new process, or replaces one whose structure cannot meet the required outcome. Both begin by defining the problem and measuring requirements; they diverge at improvement versus design.
Do you need statistical tools for every Lean Six Sigma project?
No. Use statistical methods when the decision and the available data justify them. Every project still needs operational definitions, a credible baseline and a measurement method capable of detecting the change being claimed.
Should automation happen during a Lean Six Sigma project?
Automation can be part of the improved or redesigned process, but only after unnecessary work and unclear rules have been challenged. The automated flow should retain ownership, exception handling and measures that show whether the change is working.
Choose the method after framing the problem
If a team cannot yet tell whether it needs DMAIC or DMADV, that is useful information. Begin with a bounded discovery: define the outcome, map the current state, review the available evidence and decide whether the process is capable of improvement.
Explore our Lean Six Sigma service, see the wider continuous improvement approach, or bring us a process problem to examine.
