The DMAIC Tollgate Review Checklist, Gate by Gate

A tollgate is a decision, not a status meeting. At the end of each DMAIC phase the champion looks at the evidence the project leader brings and picks one of three outcomes: proceed to the next phase, go back and fix what is missing, or stop the project. Every other purpose people attach to the review (updating the sponsor, motivating the team, showing slides) is secondary to that choice.

The decision matters because most projects that die do so in the middle. Antony, Lizarelli, and Fernandes surveyed 201 Lean Six Sigma practitioners across service and manufacturing and found termination rates highest in the Measure and Analyze phases, with inconsistent monitoring and control of projects among the five leading causes of failure (IEEE Transactions on Engineering Management, 2022). A gate that asks for evidence is the monitoring mechanism. A gate that accepts a slide deck is not.

This checklist gives the champion the questions to ask at each of the five gates and gives the project leader the evidence to bring. It sits inside the DMAIC resource hub; for the phase work that produces the evidence, see How to Run a DMAIC Project End to End.

What a tollgate review is for

The review is short. iSixSigma's reference entry puts it at 30 to 60 minutes, attended by the champion or sponsor, the project leader, a Master Black Belt or mentor where one exists, and the process owner (iSixSigma, Tollgate). The champion owns the go or no-go call. Everyone else supplies evidence or expertise.

Three rules keep the meeting a review rather than a presentation.

First, the evidence is the project record, not a summary of it. If the charter, the data, and the metric are current, the champion reads them directly. A deck built the night before hides gaps; the record shows them.

Second, the exit condition for each gate is written before the phase starts. The team knows what "done" means for Measure on the day Measure begins, so there is no argument about the standard at the gate.

Third, the outcome is recorded with a date and a name. A gate that ended with "let's keep going and see" was not a gate.

How to read the checklist

Each gate below has three parts: the questions the champion asks, the evidence the project leader brings, and the exit condition. Treat the questions as the champion's script. Treat the evidence list as the project leader's preparation list. Treat the exit condition as the single sentence the champion signs.

In SixGrid, each gate is a tollgate milestone in the Milestones and To-dos phase navigator, marked distinctly from the working milestones around it. The evidence items become to-dos under that milestone, each with an owner and a due date. The checklist is then not a document anyone maintains. It is the phase itself.

Define gate

Questions the champion asks

1. What process is broken, by which metric, by how much, and over what window?
2. Does the problem statement contain a cause or a solution? If yes, the charter is not finished.
3. Who is the customer of this process, and which of their requirements does the problem violate?
4. What does this problem cost per year, and where did that number come from?
5. Who is on the team, what fraction of their time is committed, and has their manager agreed?
6. What is out of scope, and who decided?

Evidence the project leader brings

• The charter with Problem Statement, Goal Statement, and Business Case as separate fields, status Final. The standard each field must meet is in The Six Sigma Project Charter, Field by Field.
• A SIPOC or high-level process map showing the boundaries the scope statement claims.
• A primary metric with a baseline figure (even a rough one) and a target, plus any secondary metrics that must not degrade.
• A COPQ figure with its basis: the formula, in one line, behind the annual dollar figure.
• Named roles: champion, project leader, mentor, process owner, and a financial representative if the organization requires one.

Exit condition

The champion signs the charter. Specifically, the champion agrees that the problem as stated is worth the team's time at the cost stated, and that the scope as drawn is one the team can actually change.

Measure gate

Questions the champion asks

1. What exactly is being counted, at which step, by whom, and over what period? Read the operational definition aloud.
2. Has the measurement system been tested? What was the result?
3. What is the baseline, and how many observations support it?
4. Does the baseline agree with the number in the charter? If not, which one is right, and does the business case still hold?
5. Is the process stable enough that the baseline means anything, or is it drifting?
6. What did the data collection plan promise, and what did it deliver?

Evidence the project leader brings

• A written operational definition for the primary metric and each secondary metric.
• A measurement system analysis result. For variable data, the AIAG Measurement Systems Analysis manual (4th edition) treats a gage R&R under 10 percent of tolerance or process variation as acceptable, 10 to 30 percent as conditionally acceptable depending on cost and risk, and over 30 percent as unacceptable (SPC for Excel, summarizing AIAG). For attribute data, bring the agreement study.
• A detailed process map at the level where the data was collected.
• The baseline: the value, the sample size, the date range, and a run chart or control chart of the observations.
• The data collection plan with what was planned against what was collected.

Exit condition

The champion accepts the baseline as the number the project will be judged against. From this gate forward, the baseline does not move.

The Measure gate is the one most likely to end in "revise" or "stop," and that is the gate doing its job. If the data the charter assumed would exist does not, or if the measurement system cannot distinguish good from bad, the honest outcome is to go back to Define with a smaller scope, or to close the project. Either is cheaper than four more months of work on a number nobody trusts.

Analyze gate

Questions the champion asks

1. Which causes did the team suspect at the start, and which ones survived testing?
2. For each surviving cause, what is the evidence that it drives the primary metric? What test, what data, what result?
3. Which plausible causes did the data rule out?
4. How much of the gap between baseline and target do the verified causes explain?
5. Has anyone on the team proposed a solution yet? If so, was it before or after the causes were verified?

Evidence the project leader brings

• The list of candidate causes, usually from a cause-and-effect diagram, with a disposition for each: verified, rejected, or untested.
• For each verified cause, the analysis that verified it: stratified data, a hypothesis test with its p-value, a regression, or a designed experiment. The form matters less than the fact that a test was run and a result recorded.
• A statement of how much of the problem the verified causes account for. A project that has verified causes explaining 20 percent of the gap needs to return to Analyze before it goes anywhere near Improve.
• The list of rejected causes. Champions underrate this list. It is the proof that the team tested rather than confirmed.

Exit condition

The champion agrees that the verified causes are real and sufficient. The project may now design solutions, and only for those causes.

Question 4 is the one to press. Teams that reach the Analyze gate with a single verified cause explaining a small part of the variation often propose a solution for it anyway, because they have been working for months and want to show something. The gate is where the champion says no.

Improve gate

Questions the champion asks

1. Which verified cause does each proposed solution address?
2. What alternatives were considered, and why was this one chosen?
3. What did the pilot show, measured the same way as the baseline?
4. What did the pilot break? Did any secondary metric move the wrong way?
5. What will full implementation cost, who has approved the spend, and who will do the work?
6. What are the risks of rolling this out, and what is the plan for each?

Evidence the project leader brings

• A solution selection matrix or equivalent, mapping each solution to a verified cause and rating the alternatives on impact, cost, and ease.
• Pilot results using the operational definition and measurement system from Measure. Before and after data on the same chart, with the sample sizes.
• Secondary metric readings from the pilot window.
• An FMEA or risk assessment for the full rollout, with a mitigation for each high-priority failure mode.
• Costs and benefits entered as they were validated, classified at entry. What finance needs to see, and why reconstructing figures at close-out fails, is covered in Six Sigma Financial Tracking That Finance Will Sign Off On.
• An implementation plan with owners and dates for the full rollout.

Exit condition

The champion approves full implementation and the spend that goes with it. A pilot that did not move the primary metric does not pass this gate, no matter how well the solution was designed.

Control gate

Questions the champion asks

1. What will be measured after the team leaves, how often, and by whom?
2. What reading triggers action, and what is the action?
3. Has the process owner accepted the control plan, in writing?
4. Have the standard work documents, procedures, and training been updated?
5. What is the validated benefit, has finance signed it, and how will it be tracked for the next twelve months?
6. What did the team learn that the next project should know?

Evidence the project leader brings

• The control plan: the measurement, the frequency, the owner, the control limits or thresholds, and the response plan for an out-of-control reading.
• Updated standard work, procedures, and training records.
• Post-implementation data showing the primary metric holding at or near target. Thirty days of data is a common minimum; a process with long cycle times will need more.
• Process owner sign-off on the control plan.
• Validated financials with the finance representative's approval, and a tracking method for the post-project period.
• The final report: executive summary, solution and improvements, controls and sustainability, lessons learned.

Exit condition

The champion closes the project and transfers ownership to the process owner. The team is released. From this point, the process owner runs the control plan and the improvement either holds or it does not.

iSixSigma's phrasing for the Control checkpoint is whether the team has "implemented the solution as well as a control plan to ensure the process is robust to change." Read that sentence as two separate tests. A solution without a control plan is a temporary condition, and the gate should say so.

Running the gate from the project record

The preparation burden for a tollgate drops to nearly nothing when the evidence lives where the work happens. SixGrid makes that the default in a few ways.

The tollgate milestone sits in the phase navigator as a distinct row, so the team sees the gate coming and the champion can open the project and see which evidence items under it are done. Each evidence item is a to-do with a due date and a color-coded urgency indicator, so a measurement system study that is three days late is visible without anyone asking.

Each to-do has its own comment thread. The argument about whether the operational definition is precise enough happens on the to-do that holds the operational definition, dated and attributed, rather than in an email chain the next project leader will never find.

When a milestone is due within three days, SixGrid emails the project leader, associate leaders, champion, project creator, and the organization's owners and admins. The champion learns a gate is approaching from the system, not from the project leader deciding when to ask for a meeting. That distinction is what keeps a gate from quietly sliding six weeks.

When the answer is stop

A stopped project is not a failed project. It is a project the gate did its job on. Antony and colleagues found the termination rate lowest in Control, where 65 percent of respondents reported fewer than 5 percent of projects terminating, against far higher rates in Measure and Analyze. Projects that get past the middle gates finish. The money is lost on the ones that should have stopped at Measure and were allowed through.

Record the stop the way you would record a pass: the date, the champion's name, the gate, and the reason. Archive the project rather than deleting it. The charter, the baseline work, and the rejected causes are worth something to the next team that picks up the same problem with a better scope.