DMAIC vs RDMAICS: why the Recognize phase changes everything

Almost every Lean Six Sigma practitioner learns DMAIC first: Define, Measure, Analyze, Improve, Control. It is a superb problem-solving engine, and decades of deployment across manufacturing, healthcare, financial services and shared-service operations have proven that the discipline works. But DMAIC quietly assumes something enormous. It assumes somebody, somewhere, has already chosen the right problem. Define begins with a charter. It does not tell you how the charter came to exist, who validated the business case, or whether the organisation had a better opportunity sitting untouched two processes upstream.

In practice this is where most improvement programmes lose their credibility. A Black Belt is handed a project because a manager is annoyed about a symptom. Four months later the team has beautifully executed statistical work on a problem worth $40,000 a year, while a $2.4m variation problem in the same value stream remains invisible. The analysis was flawless. The selection was not. Executives do not remember the rigour of the hypothesis test; they remember that the programme produced small numbers.

The second structural gap sits at the other end. Control, as most teams practise it, means a control plan document, a chart and a handover meeting. Six months later the improvement has decayed because nobody owned the standard, the training was never refreshed, and the replication opportunity in three sister sites was never taken. The gain existed. The system to keep and multiply the gain did not.

RDMAICS extends DMAIC at both ends: Recognize, Define, Measure, Analyze, Improve, Control, Sustain. The additions are not cosmetic. Recognize formalises opportunity identification as a phase with its own tools, evidence and tollgate. Sustain formalises the transfer of the improvement into the business as normal work, plus the deliberate replication of the result elsewhere.

Recognize asks a disciplined set of questions before a charter is written. What does the business actually need this year? Which processes carry the largest cost of poor quality? Where do customer pain points and strategic priorities intersect? What is the preliminary benefit range, and is it worth a Black Belt's time versus a Just Do It? Tools such as Voice of Business capture, pain-point registers, cost-of-poor-quality analysis, effort/impact matrices and project prioritisation matrices belong here, not in Define, where they are usually rushed.

Sustain then closes the loop with training-needs analysis, standard-work handover, audit routines, a recognition step for the team, a lessons-learned record and an explicit replication plan. The question changes from 'did the process improve?' to 'is the organisation permanently better at this, and where else does this apply?'

In Ci Flow, RDMAICS is not a label on a folder. Each of the seven phases is a workspace that holds the tools you selected, the evidence you produced, the readiness checks for that phase and the tollgate decision that closed it. When a phase is approved, its evidence carries forward, so the Measure baseline that Analyze depends on is the same number leadership saw at the Define gate.

Because Recognize is a real phase with real tools, the business case you present at the Define tollgate is traceable. You can show the pain-point register, the cost-of-poor-quality calculation and the prioritisation matrix that put this project ahead of eleven others. That single change does more for programme credibility than any amount of downstream statistical elegance.

A seven-phase method is not a badge of seriousness. It is a cost. If the cause is known, the fix is cheap and the risk is low, running RDMAICS is waste dressed as rigour. That work belongs in a Just Do It: five light stages, enough evidence to prove the change worked, and no tollgate theatre.

If the problem is genuinely unclear but the organisation needs learning and alignment more than statistics, A3 is usually better. If the constraint is speed and cross-functional focus, run a Kaizen event. The discipline of a mature programme is not 'always DMAIC'. It is choosing the smallest method that will hold the decision you need to make.

This is exactly why Ci Flow supports four methodologies rather than one. The prioritisation work you do in Recognize should end with a recommendation about method as well as about value. A portfolio where every initiative is a full RDMAICS project is a portfolio that will deliver three projects a year and lose executive patience by month five.

If you are moving an existing DMAIC programme to RDMAICS, do not retrain everyone at once. Start by adding a Recognize gate to your project pipeline: nothing gets a charter until a pain-point register, a benefit estimate and a prioritisation score exist. That single gate typically reallocates 20 to 40 per cent of the pipeline within one quarter, because the ranked list rarely matches the list managers arrived with.

Next, make Sustain a condition of project closure rather than a courtesy. Define what evidence closure requires: a standard operating procedure, an audit frequency, a named process owner, a control chart with reaction rules, and a replication assessment. Only then let the project leave the portfolio as Completed.

Finally, measure the programme on sustained benefit at twelve months, not on benefit claimed at Control. Programmes that make that switch see their reported numbers drop in the first cycle and then become defensible. That is the only state in which finance will keep funding you.