Define — Framing the Right Problem
Define is the first phase of DMAIC (Define, Measure, Analyze, Improve, Control), and it answers a deceptively simple question: what problem are we solving, for whom, and why is it worth the effort? Everything downstream inherits the quality of the Define work, so a project that is poorly scoped or aimed at a symptom rather than a business pain will waste the Measure and Analyze effort that follows. Green Belts leave this phase with an approved charter, a translated Voice of the Customer, and an agreed process boundary.
The project charter: authorizing the work
The charter is the founding document of the project — it formally authorizes the team, secures the sponsor's commitment of time and resources, and keeps everyone aligned on a single objective. A complete charter carries a problem statement, a goal statement, the business case, the scope (in and out), the team and roles, and a milestone timeline. Because the charter is a contract between the team and the sponsor, it is a living document: as the team learns more in Measure, the scope or goal may be renegotiated with the sponsor rather than quietly changed. Exam items routinely contrast the charter with deliverables of later phases — a control plan, a hypothesis test, or a sigma calculation are NOT charter contents — so recognize the charter as the Define artifact that states problem, scope, goal, and business case.
Writing problem and goal statements that hold up
A strong problem statement is specific, measurable, and neutral: it says what is wrong, where, how big, and since when, without naming a cause or a solution. Compare a weak statement — 'orders ship too slowly' — with a defensible one: 'From January to June, 14% of online orders shipped more than 48 hours after payment, versus the 2% target, costing an estimated $180K in credits.' Naming a cause ('because the picking software is slow') pre-judges the Analyze phase and biases the team. The goal statement mirrors the problem but states the desired end condition and is written to be SMART — Specific, Measurable, Achievable, Relevant, Time-bound — for example 'reduce late shipments from 14% to 3% by Q4.' Exam traps include problem statements that embed a solution, omit a baseline number, or set a goal with no deadline.
The business case: why now, why this
The business case answers 'why should the organization fund this project instead of another?' It connects the process pain to money and strategy — cost of poor quality, lost revenue, capacity, risk, or customer retention — and gives the sponsor a basis to prioritize. A Green Belt does not need a full financial model, but should be able to state the size of the prize in the language the business uses. The business case is also the honest test of whether a Six Sigma project is even appropriate: if the cause is already known and the fix is obvious, a just-do-it or kaizen action is faster than a full DMAIC cycle. DMAIC earns its overhead when the cause is genuinely unknown and the process is chronically off target.
Voice of the Customer: proactive vs. reactive sources
Voice of the Customer (VOC) is the collected set of customer needs, expectations, and priorities, gathered in the customer's own words before it is translated into requirements. Sources split into two families that the exam tests directly. Reactive sources arrive on their own after something happens — complaints, warranty claims, returns, help-desk tickets, cancellations — and reflect problems already experienced. Proactive sources are ones the team deliberately goes out to collect — interviews, surveys, focus groups, direct observation, and market research — before problems surface. Relying only on reactive data biases the picture toward the loudest failures and misses silent dissatisfaction, so mature teams pair the two. Interviews, surveys, and focus groups are the classic proactive-gathering methods to recognize on the exam.
Kano model: sorting needs by how they satisfy
The Kano model classifies requirements by how their presence or absence affects satisfaction, and it appears often because it explains why 'more' is not always better. Must-be (basic) requirements cause strong dissatisfaction when absent but produce no delight when present — they are simply expected, like brakes on a car; you cannot win by meeting them, only lose by missing them. Performance (one-dimensional) requirements are linear: satisfaction rises as you deliver more, such as better fuel economy or faster delivery — these are usually the spoken needs customers rank in surveys. Delighters (exciters/attractive) are unexpected features that create disproportionate satisfaction when present but cause no dissatisfaction when absent. Over time, delighters decay into performance needs and then into must-bes as customers come to expect them, which is why continuous innovation is required.
From VOC to CTQ with the CTQ tree
Voice of the Customer is qualitative and vague; a project needs something measurable. Critical-to-Quality characteristics (CTQs) are the specific, measurable requirements a process must meet to satisfy a customer need, complete with a metric, a target, and a specification limit. The CTQ tree is the translation tool: start with the general need, break it into drivers, then define measurable requirements at the leaves. A customer's 'I want my coffee hot' is a need, not a CTQ; the CTQ is the measurable version — for example 'serving temperature between 150 °F and 175 °F.' The discipline is to convert every fuzzy want into a number the Measure phase can actually count. Exam items ask you to pick the option that turns a VOC statement into a specification with a measurable target, and to distinguish a CTQ (measurable requirement) from a VOC (raw customer language).
SIPOC and scoping the process
A SIPOC diagram maps the process at a high level in five columns — Suppliers, Inputs, Process, Outputs, Customers — and is usually the last Define deliverable because it sets the boundaries everyone will honor. Reading it: Suppliers provide the Inputs; the Process (typically five to seven high-level steps) transforms them into Outputs; the Outputs go to Customers. The 'I' is Inputs — the materials, information, and resources the process consumes — while Outputs are what it produces and hands to customers. SIPOC fixes the start and end points of the effort, which is the real defense against scope creep: work that touches suppliers upstream or customers downstream of those boundaries is explicitly out of scope. Green Belts also use a prioritization tool such as a weighted criteria matrix to choose which problem to charter in the first place, weighting candidate projects by customer impact, business benefit, and feasibility.
Keep going: the full Lean Six Sigma Green Belt (IASSC ICGB) guide covers every section of the exam. Lean Six Sigma Green Belt — Complete Study Guide (2026) — PDF + EPUB, $19.99 · 14-day refund →
Practice stays free. The full Lean Six Sigma Green Belt (IASSC ICGB) study guide is the material itself, taught start to finish — a downloadable PDF + EPUB you keep.