How to Run a DMAIC Project End to End

DMAIC is the method to use when an existing process performs below requirement and the cause has not been proven. It structures the work into five phases: Define, Measure, Analyze, Improve, Control. Each phase produces specific deliverables, and each ends with a tollgate review before the next begins.

The structure matters because most improvement projects do not deliver what they promise. A global study of Lean Six Sigma project failures identified lack of management commitment, inconsistent monitoring, and poor communication as leading causes, and found that projects terminate most often in the Measure and Analyze phases. These are process failures, not analysis failures. A project that knows exactly what each phase requires, who reviews it, and what evidence the review needs is much harder to stall.

This guide walks through a complete DMAIC project in order, with the deliverables for each phase and how each step is handled in SixGrid. For background on the broader method family, see our continuous improvement resources.

Before you start: confirm this is a DMAIC project

DMAIC finds causes that repeated troubleshooting has not identified. If the cause is already known, write an action plan and skip the ceremony. Run three checks before chartering anything:

1. The cause is genuinely unknown or unproven. Opinions about the cause do not count as proof.
2. Process data exists, or can be collected within four to six weeks. The Measure phase runs on data, and projects without it stall there.
3. The problem connects to a metric leadership already tracks: cost, quality, cycle time, or customer satisfaction. Projects solving invisible problems struggle for sponsorship.

Plan on three to six months. A tightly scoped project with the data already in hand can finish in eight to ten weeks.

In SixGrid, candidate projects sit at Idea status with a COPQ figure attached: the annualized cost of the problem, with a one-line basis explaining the math. The Project Ideas view lists every candidate sized this way, so selection is a comparison of dollar figures rather than a debate about whose problem feels most urgent.

Define: charter the problem, not the solution

The Define phase produces one central deliverable: the project charter. Everything else in the project traces back to it.

Write the charter field by field

State the problem in neutral, quantified terms. A usable problem statement names the process, the metric, the current performance, the required performance, and the observation window. It contains no causes and no solutions. Juran's guidance is direct on this point: the phrase "due to" in a problem statement means the team has already jumped to root causation, and embedded solutions are among the most common charter mistakes.

Write the goal statement as the measurable counterpart: the same metric, the target value, and the date. The business case then answers one question: why this problem, why now, in currency.

The Charter tab in SixGrid holds these as separate structured fields: Problem Statement, Goal Statement, and Business Case, alongside a Charter Status that moves from Draft to Final when the champion signs off. The separation is deliberate. A form with distinct fields makes an embedded solution visible in a way a free-text document does not.

Set the metrics and the team

Define one primary metric with its baseline and target. Add secondary metrics as guardrails: the measures that must not degrade while the primary improves. A project that improves throughput while quietly increasing defects has not improved anything.

Staff the project with named roles. The champion owns the business result and clears obstacles. The project leader runs the work. A mentor, typically a Black Belt, advises on method. In SixGrid, the project wizard applies the DMAIC template, and the People tab assigns these as project roles with matching permissions: leaders edit the charter and financials, contributors add work and commentary.

Measure: earn a baseline you can defend

The Measure phase establishes current performance with data the whole team accepts. Its deliverables are a process map, an operational definition of the metric, a data collection plan, and the validated baseline.

Write the operational definition first: what exactly is being counted, at which process step, over what window. Ambiguity here surfaces weeks later as an argument about whether the improvement is real. Then execute the collection plan as scheduled work with named owners and dates, not as a standing intention.

This phase is where projects die. The termination data cited above peaks in Measure, usually because the data the charter assumed would exist does not. If collection stalls past its window, take that finding to the tollgate rather than quietly extending the phase.

SixGrid holds the baseline, current, and target values on the primary metric with a progress bar between them, and collection tasks are to-dos inside the Measure phase with assignees and due dates. Notes on the charter record collection decisions as a running journal, so the reasoning survives team turnover.

Analyze: prove the cause before touching the process

The Analyze phase separates suspected causes from verified ones. Its deliverable is a short list of root causes supported by data, confirmed before any solution work begins.

Generate candidate causes with structured tools: a cause-and-effect diagram to lay out the theories, then stratification or hypothesis testing against the Measure data to keep only the causes the data supports. The discipline to reject a plausible cause the data does not support is what distinguishes Analyze from ordinary troubleshooting.

Document each verified cause with its evidence in the phase's to-dos and notes. The Improve tollgate will ask for exactly this chain: metric, verified cause, proposed countermeasure.

Improve: pilot before you commit

The Improve phase selects countermeasures for the verified causes and proves they work at small scale. Deliverables are a solution selection matrix, a pilot result, and a cost and benefit accounting for the change.

Pilot in a bounded slice of the process and compare against the baseline using the same operational definition from Measure. A solution that cannot demonstrate movement in the primary metric during a pilot will not demonstrate it at full scale either.

Record the financial effects as they are validated, not reconstructed at close-out. In SixGrid, benefits carry two classifications: Hard or Soft, which drives the Net Hard Savings summary, and a Benefit Type such as cost savings, cost avoidance, or revenue increase. Costs are recorded with their own types. Classifying at entry time, with a Financial Rep on the team validating figures, is what makes the final numbers survive a controller's review.

Control: make the gain permanent

The Control phase transfers ownership from the project team to the process owner. Deliverables are a control plan, standardized procedures, and a response plan: the measurement that continues after the project, the threshold that triggers action, and the named person who acts.

An improvement without a control plan is a temporary condition. Write the plan while the team still exists, and confirm the process owner has accepted it at the final tollgate.

Control-phase milestones in SixGrid hold this handoff work, and the Controls and Sustainability section of the final report records the plan itself, so the close-out document and the control plan are the same artifact.

The tollgate rhythm

Tollgates are the mechanism that keeps the phases honest. At the end of each phase, the champion and sponsors review the phase deliverables and decide: proceed, repeat, or stop. Sponsors who take the review seriously ask pointed questions; published tollgate checklists run to 25 of them across the five phases.

Treat the tollgate as a working review of live evidence, not a presentation. The preparation burden drops when the evidence does not need to be assembled. In SixGrid, tollgates appear as distinct rows in the milestone sequence, and the review runs from the project itself: the charter, the metric progress, the financials, and the activity log are already current. Stopping a project at a tollgate is a legitimate outcome and costs far less than carrying a doomed project to the end.

Close-out: write the final report once

The final report answers four questions: what the project found and delivered (Executive Summary), what changed (Solution and Improvements), how the gain is protected (Controls and Sustainability), and what the next team should know (Lessons Learned).

Write it from the project record rather than from memory. In SixGrid, the Report tab holds the four sections and generates the PDF in one step, pulling in the charter, team, metrics, and financials that accumulated across the phases. A first project run this way becomes the template for the second, which is the point at which a single project becomes a program.