Writing a Six Sigma Problem Statement That Survives the Define Tollgate

A problem statement fails the Define tollgate for one of four reasons: it has no number, it has no window, it names a cause, or it names a fix. What the team hears is "come back when you have data" or "how do you know it's the staffing," and the tollgate slips two weeks. This post gives the checks a reviewer applies, six weak-versus-strong pairs from different industries with the reason each weak one fails, and a drafting procedure that produces a statement that passes the first time.

The Six Sigma project charter, field by field covers how the problem statement pairs with the goal statement. This post stays on the problem statement alone, the field reviewers reject most often.

What the tollgate checks

The Define tollgate checklist opens with the business Y and then asks, second, "What is the problem statement?" (Master of Project Academy). The champion is not asking whether one exists. The champion is checking it against a short list of required parts. Vishy Chandra's charter-mistakes guide on the Process Excellence Network lists four: the timeframe of the initial data, the metric, target versus actual performance on that data, and the financial loss from the gap (PEX Network). Add a fifth that most reviewers assume: where the problem occurs, meaning the process, line, site, or product family.

Written out, a complete statement has this shape: at [location], [metric] ran at [actual] against a requirement of [target] between [start] and [end], costing [amount] over that period. One or two sentences.

Two things must be absent. The statement contains no cause and no solution. The word that gives a cause away is "due to." A statement that reads "invoices are late due to understaffing in AP" has finished Analyze before Measure has started, and every later phase will lean toward confirming the guess. Retrium's guidance on writing problem statements for root cause analysis uses the same example: "the project ran over budget due to understaffing" narrows the whole investigation to staffing when the overrun could have a dozen sources (Retrium). Solutions hide behind "need to," "implement," "install," and "train."

Weak versus strong, six industries

Each pair gives the weak version as a team would first write it, the check it fails, and the version that passes. Numbers are illustrative.

Manufacturing: scrap on a stamping line

Weak: "Line 4 produces too much scrap and we need to recalibrate the press."

Why it fails: no metric, no window, and a solution. "Recalibrate the press" assumes the press is the cause. If the scrap turns out to come from incoming coil variation, the project has already spent its credibility on the wrong fix.

Strong: "Scrap on stamping line 4 averaged 6.8 percent of units produced from January through April, against a plant standard of 2.5 percent. The excess scrap consumed $214,000 in material and rework labor over the four months."

Healthcare: discharge delays

Weak: "Patients wait too long to be discharged because nursing is short-staffed on weekends."

Why it fails: a cause, and no number. Weekend staffing may be part of the story. Stating it in the charter means the tollgate reviewer cannot tell whether the team measured anything or repeated what the unit manager believes.

Strong: "On the medical-surgical unit, time from discharge order to patient departure averaged 4.9 hours in the second quarter, against a hospital target of 2 hours. The delay held 11 bed-hours per day on average, deferring an estimated 340 admissions over the quarter."

Finance: month-end close

Weak: "The month-end close takes far longer than it should and creates stress for the accounting team."

Why it fails: "far longer" is an opinion. No target, no baseline, no cost. Stress is real but not a metric the sponsor can trade against other projects.

Strong: "The corporate month-end close took an average of 9 working days across the last 12 closes, against a policy standard of 5. Late closes delayed board reporting in 7 of 12 months and required an average of 112 hours of overtime per close."

Logistics: on-time delivery

Weak: "Our carriers are unreliable and deliveries are always late."

Why it fails: blame in place of measurement. "Always" is not a rate. Assigning the problem to carriers also puts the fix outside the team's authority, which is a scope failure as much as a problem-statement failure.

Strong: "On-time delivery for the Midwest region measured 83.1 percent of shipments from March through August, against a customer contract standard of 96 percent. Late shipments triggered $148,000 in service credits over the period."

IT service desk: ticket resolution

Weak: "Ticket resolution is slow. Junior analysts need better training."

Why it fails: two sentences, two problems. The first has no number. The second is a solution that also blames a group of people, which guarantees the analysts will not help the project.

Strong: "Mean time to resolve priority 3 tickets at the internal service desk was 3.4 business days from April through June, against a service-level target of 1 business day. 41 percent of tickets breached the SLA, and breached tickets were reopened at twice the rate of on-time tickets."

Contact center: first-call resolution

Weak: "Customers have to call back too often, and satisfaction scores are dropping."

Why it fails: two metrics with no numbers, and no window. A reviewer cannot tell which one the project targets. First-call resolution and satisfaction may move together, but a project charters one primary metric.

Strong: "First-call resolution for billing inquiries averaged 61 percent from May through July, against an internal standard of 80 percent. Repeat calls on billing added roughly 2,900 handled contacts per month at $6.40 each."

A drafting procedure

Draft the statement with the six questions of 5W2H that describe a situation, and hold back the seventh. The tool asks who, what, when, where, why, how, and how much; Quality Gurus draws the line between 5W2H as a situation-description tool and Five Whys as a cause-finding tool (Quality Gurus). For a problem statement, "why" is the one question the Define phase does not answer.

1. What: name the process and the single metric that shows the gap. If two metrics compete, pick the one leadership already tracks and make the other a secondary metric.
2. Where: name the site, line, unit, region, or product family. A problem that is everywhere is not scoped yet.
3. When: state the observation window with start and end. Six to twelve months is typical; shorter windows need a reason.
4. How much: report actual against target in the same unit. Then price the gap. This figure is the COPQ, and it is what lets the sponsor rank the project against others.
5. Who: identify the customer of the process, internal or external, whose requirement sets the target. Do not name people as the cause.
6. How: describe how the gap shows up (rework, credits, overtime, deferred admissions), not how it will be fixed.

Then run the two deletions. Search the draft for "due to," "because," "caused by," "lack of," and remove the clause. Search for "need to," "implement," "install," "train," "upgrade," and remove the clause. If the statement is now empty, the team had a solution and no problem, and the project should go back to the Idea stage until someone measures something.

Locking the statement at the tollgate

A problem statement that passes Define becomes a fixed reference for the rest of the project. The Measure phase refines the baseline, and that refinement should be visible as an update with a date, not a silent overwrite of the number the sponsor approved. Changes to scope, metric, or window after the tollgate go back through the sponsor. How to run a DMAIC project end to end covers the phase-by-phase evidence each tollgate expects.

In SixGrid the Problem Statement is a separate field on the Charter tab, above the Goal Statement and Business Case, with the Primary Metric card holding baseline, current, and target as numbers below. A cause or a solution written into the problem field stands out because the neighboring fields exist for those things and are empty. Charter Status on the same tab moves from Draft to Final when the champion signs off. That status is independent of Project Status, so a project can be Active while the charter is still Draft, and the open Draft flag is what tells a reviewer the statement is not yet a contract. Once it is Final, an edit is a visible act rather than a quiet change to a shared document.

Six Sigma financial tracking that finance will sign off on explains how the Define-phase COPQ figure connects to the benefits recorded at Improve. For a broader view of the method, see the DMAIC resource hub.