Module 3 · Define

Defining a project

Every DMAIC project starts before any data is collected: with a sentence that says what is wrong, a document that says why it is worth fixing, and a boundary that says where the team is and is not allowed to look. Get that sentence, document and boundary wrong, and the most careful capability study or gauge R&R in the world is answering a question nobody needed answered. This module covers Define: problem statements, project charters, translating customer voice into measurable requirements, the Kano model, stakeholder analysis, and what separates a Green Belt project that changes something from one that produces a binder.

Learning objectives

• Write a problem statement that names a measurable gap instead of a feeling.
• Build a one-page project charter with a business case, goal statement, scope and boundaries.
• Translate a customer's own words into a structured, measurable critical-to-quality (CTQ) requirement.
• Classify a requirement using the Kano model and explain why "meeting spec" is not the same as "delighting the customer."
• Map a project's stakeholders by power and interest and say what each group needs from the team.
• Recognise the difference between a Green Belt project with a real, scoped, measurable problem and one that is really an assignment to "go do something about quality."

Why this matters

Noriaki Kano and his co-authors published a two-dimensional model of quality in 1984 that is still the standard way to talk about customer requirements: some requirements are must-be (their absence causes real dissatisfaction, but meeting them earns no credit), some are one-dimensional (more is linearly better, less is linearly worse), and some are attractive (their absence causes no complaint, but their presence delights).^[1] Kano validated the categories with consumer surveys on televisions and table clocks, and the reason the model has lasted forty years is that it answers a question every Define phase has to answer: which requirement, if you miss it, actually matters. A charter built around a must-be requirement ("the assembly should not leak") is defending against real pain; a charter built around a one-dimensional requirement ("cycle time should be faster") is trading off against something else; and confusing the two wastes a project on a requirement nobody was going to complain about.

A published, peer-reviewed illustration of what a scoped Green Belt project looks like in a manufacturing setting: Sharma and Rao's 2014 open-access case study of a DMAIC project on an engine crankshaft line reports a defined problem (excess dimensional variation on a ground journal), a measured baseline standard deviation of 0.003 mm falling to 0.002 mm after the project, Cp rising from 1.29 to 2.02 and Cpk from 0.32 to 1.45, using a cause-and-effect diagram and a process FMEA as the Analyze-phase tools.^[6] Those numbers are quoted exactly as published; this course did not recompute them, and they are the one exception in this module to the rule that every number is independently checked, because they describe someone else's real production line, not a constructed dataset. What is worth noticing about the case is not the improvement itself but its shape: a specific characteristic, a specific gauge, a before-and-after Cpk, and root-cause tools used deliberately rather than a general instruction to "improve quality." That shape is what Define is supposed to produce, on every project, before Measure begins.

The opposite failure mode is familiar to anyone who has sat through a program review: a project chartered as "reduce scrap" or "improve the brazing process," with no baseline number, no goal number, and no stated boundary, staffed by whoever had time that quarter. Six months later nobody can say whether it succeeded, because nobody defined what success was. The tools in this module are not bureaucracy for its own sake; a charter, a CTQ tree and a stakeholder map are the fastest way to find out, before spending a single hour of Measure-phase data collection, whether a project is actually answerable.

Problem statements that survive scrutiny

A problem statement is one to three sentences. It names what is wrong, where, since when, and how big, without naming a cause and without naming a solution. Naming a cause turns the statement into an unverified hypothesis ("leaks are caused by bad flux application"); naming a solution skips Analyze entirely ("we need a new fixture"). A problem statement that survives a skeptical program manager's questions has four things in it:

• What is happening, described by a measurable characteristic, not an adjective. "Quality is bad" is not measurable; "4.2 % of assemblies fail the leak test" is.
• Where it happens: the process, the line, the product family. A statement that could describe any process in the plant is too vague to scope.
• Since when (or over what period) the data were collected, so the reader can judge whether the baseline is recent and representative.
• How big the gap is between current performance and requirement, ideally as a number the reader can check against a data source.

A statement that adds a cause or a fix, however plausible, has quietly closed off Measure and Analyze before they started. "Leak-test rejects are running at 4.2 %, up from a historical 2 %, because operators are rushing the flux step, so we need a poka-yoke fixture" contains a real problem statement, an unverified cause, and a proposed fix, all before anyone has looked at the data. Strip it back to "leak-test rejects on the brazed heat-exchanger line ran at 4.2 % over the last quarter (1,000 units), against a historical rate of 2 %" and the team can now go find out why, instead of assuming they already know.

Project charters

A charter is the one-page document that turns a problem statement into an authorized project. Every template varies in layout, but the content that has to be there is the same everywhere^[7]: a business case, a problem statement, a goal statement, a scope with explicit boundaries, a rough timeline with phase gates, and a named sponsor and team. The charter is a contract between the team and the organization: it says what the team is allowed to spend time on, and it is the document a sponsor signs to make that authorization real.

The elements, and what each one is for

Business case. Two or three sentences on why this problem is worth a team's time now: cost of poor quality, a customer complaint trend, a capacity constraint, a safety exposure. The business case is what a sponsor reads to decide whether to authorize the project at all.

Problem statement. As built above: measurable, causeless, solutionless.

Goal statement. A target for the same metric named in the problem statement, with a deadline. "Reduce the leak-test reject rate from 4.2 % to 1.0 % or lower by the end of Q3" is a goal statement; "reduce leak-test rejects" is not, because it cannot be checked against a number on a specific date. Goal-setting research going back decades is unambiguous on this point in a way that generalizes well beyond Six Sigma: specific, difficult but attainable goals produce better performance than vague or easy ones, and Linderman and co-authors made exactly this argument about Six Sigma projects specifically, framing well-run DMAIC projects as an organizational application of goal-setting theory.^[3]

Scope and boundaries. What process, what product family, what date range of data, and — just as important — what is explicitly out of scope. "In scope: the braze and leak-test steps for the heat-exchanger core. Out of scope: upstream tube-forming quality, the leak-test gauge's own measurement system (chartered separately if needed), and any change to the approved braze alloy." A boundary that is not written down gets renegotiated by whoever complains loudest in week six.

Timeline and team. Target dates for each DMAIC gate, a sponsor, a Green or Black Belt project lead, and the subject-matter experts the team needs access to (an operator, a process engineer, a quality engineer). Six Sigma's own academic reviewers have argued that this organizational structure — project charters, phase gates, a belt hierarchy, dedicated project time — is the part of the methodology that is actually new; the statistical tools themselves mostly predate the programme by decades.^[4] A charter without a named sponsor and a named lead is missing the one thing that makes the rest of the document enforceable.

Voice of the customer to critical-to-quality

Customers do not speak in specification language. "It shouldn't leak," "it feels flimsy," "I don't trust the seal" are all real customer statements and none of them can be handed to a machinist. Griffin and Hauser's structure for turning verbatim customer language into engineering requirements — capture the statement in the customer's own words, organize statements into a hierarchy of needs and the more specific drivers that satisfy them, then translate the most specific level into a measurable requirement with a target and a tolerance — is the standard method, and it is the one this course uses.^[2] The output is usually drawn as a tree: one voice-of-customer (VOC) statement branching into one or more drivers, each driver branching into one or more CTQs, each CTQ carrying a measurable target and a tolerance.

The example below is a constructed CTQ tree, drawn for teaching. It is not a transcription of a real customer interview.

Two failure modes recur. The first is stopping at the driver level and calling it a requirement: "braze joint integrity" cannot be measured on an incoming inspection report, but "leak-test reject rate" can. The second is translating one VOC statement into a single CTQ and missing that it usually implies several independent ones, each needing its own target: "it shouldn't leak" is really about joint integrity and about the leak-test method's own capability to detect a bad joint (Module 4's subject), and treating it as one requirement can leave a real driver unmeasured.

The Kano model

Once a CTQ exists, the Kano model asks a different question: if this requirement is met exactly, does the customer notice? Kano's survey method asks customers a pair of questions about each requirement — how would you feel if this feature were present, and how would you feel if it were absent — and classifies the answers into the categories below.^[1]

The category changes what a Cpk or a defect rate on that CTQ actually means to the customer. A must-be requirement that is 99 % met is not "mostly delighting" customers; the 1 % who get a leaking unit are simply dissatisfied, full stop, and there is no credit on the other side of the ledger for the 99 % who got what they were never going to praise you for. This is why a leak-test reject rate belongs in a charter's goal statement as a hard target, not as a index to be optimized against cost: for a must-be requirement, the business case is the cost of the failures, not the marginal value of exceeding the target. A one-dimensional requirement is different: cutting cycle time from 60 to 45 seconds is worth roughly proportionally more than cutting it from 45 to 44, and the charter should say so by putting a real number, not "as fast as possible," in the goal statement. Kano's own categories also shift over time — features that delight in one product generation are must-be by the next, a point the original paper makes about televisions and clocks and one that applies just as directly to two manufacturing generations of the same assembly.

Stakeholder analysis

A charter that is technically correct can still fail if the people who can stop the project, fund it, or quietly ignore its recommendations were never accounted for. A power/interest grid is the simplest tool for this: place each stakeholder by how much influence they have over the project's resources and outcome (power) and how much the project's result affects them day to day (interest).

The grid's value is not the diagram; it is the conversation it forces before the project starts. A process owner in the top-right quadrant who is not part of the core team will resist a change the team proposes in Improve, no matter how sound the data, simply because they were never consulted. An OEM customer in the "keep satisfied" quadrant does not need weekly control-chart updates, but does need to hear about a scope change or a schedule slip before they find out from a shipment. Getting this wrong is not a statistics mistake, and no amount of rigor in Measure and Analyze fixes it after the fact.

What a good Green Belt project looks like

The ASQ Green Belt Body of Knowledge frames Measure-phase work around verified measurement systems and capability studies that check stability and normality before quoting an index, and Analyze-phase work around root cause tools and hypothesis tests, all applied to a specific, scoped characteristic.^[5] Combined with the crankshaft case above, a usable checklist for "is this project actually scoped" is: one measurable characteristic (not a category of characteristics), one process step or a short, connected sequence of steps (not "the plant"), a baseline number from real data (not an estimate), a goal number with a date, and a named sponsor who can remove obstacles the team cannot remove itself. A project charter that cannot answer "what one number will you report at the end, and what is it today" is not ready to leave Define, no matter how enthusiastic the kickoff meeting was.

Worked examples

Worked example 1: the capstone charter, baseline to goal

The data below is a constructed example matching the capstone project's own baseline (Module 19), not a real production run.

The capstone line (Module 19) brazes aluminium heat-exchanger cores and leak-tests every unit before it ships. Over the most recent 1,000 units, 42 failed the leak test.

Converting that to a sigma level (Module 6 derives this properly; here it is only a preview): a DPO of 0.042 corresponds to a long-term Z of 1.73, or a "sigma level" of 3.23 under the Motorola 1.5σ-shift convention. The charter's goal statement targets a reject rate at or below 1.0 % (10 defects in the same 1,000 units): DPU 0.01, sigma level 3.83 — a target about six tenths of a sigma above where the line runs today, which is a meaningfully harder goal than it sounds when stated only as "4.2 % to 1 %."

Worked example 2: three problem statements, rewritten

Constructed statements, written to illustrate common failures, not quotations from a real project.

Worked example 3: a second CTQ tree

Constructed example, drawn for teaching.

A different VOC statement from the same customer base: "the connector housing sometimes doesn't seat properly." Following Griffin and Hauser's structure: the statement implies at least two independent drivers, each translating into its own CTQ.

Notice that "seat properly" alone cannot be handed to a machinist or written into a control plan; only the two rows on the right can. It is also worth checking, as Kano would, whether either driver is a must-be (a housing that will not seat at all is a hard failure, most likely must-be) or one-dimensional (insertion force has a comfort range, and both too loose and too tight are complaints, which is really a two-sided one-dimensional requirement, not a single-direction one). That classification changes how tightly Control (Module 18) needs to hold each characteristic.

Common mistakes

1. Writing a problem statement with the cause or the fix already in it. Consequence: Analyze becomes a formality that confirms what the team already decided, and the real cause, if different, is never found. Fix: read the statement back and delete any clause that starts with "because" or "so we need."
2. Chartering "quality" or "the plant" instead of one characteristic on one process. Consequence: no one can say what data to collect first, and the project drifts to whatever is easiest to measure. Fix: name the one characteristic and the one process step in the first sentence.
3. A goal statement with no number or no date. Consequence: the project cannot be closed, because "better" has no criterion. Fix: same metric as the problem statement, a target value, a date.
4. Skipping the CTQ tree and specifying straight from a customer's adjective. Consequence: engineering writes a spec for "feels solid" by guessing, and it is guessed wrong at least as often as it is guessed right. Fix: always pass through a driver before a number.
5. Treating every requirement as one-dimensional. Consequence: a must-be requirement gets a Cpk target instead of a near-zero-defect target, and the business case understates the cost of the failures that remain. Fix: ask the Kano question — does the customer notice when this is met, or only when it is missed?
6. Skipping stakeholder analysis because "everyone knows who's involved." Consequence: a process owner who was never consulted blocks the Improve-phase change, and the team relearns in week 10 what a fifteen-minute grid would have surfaced in week 1. Fix: do the grid on paper, by name, before the kickoff meeting.
7. No named sponsor, or a sponsor who cannot actually authorize the scope. Consequence: the team hits an obstacle (a needed line stoppage, a budget line) that only someone two levels up can clear, and the project stalls waiting for an escalation path that was never built. Fix: confirm the sponsor's authority matches the scope before the charter is signed.
8. Confusing a charter's business case with a savings estimate nobody can trace. Consequence: a project is sold on a round number ("this will save $500,000") that cannot survive a finance review, and the team's credibility is spent before Measure begins. Fix: tie the business case to a countable quantity from the problem statement (rework hours, units scrapped, complaints logged), and let finance do the currency conversion if one is needed.

Exercises

Exercise 1: rewrite a problem statement and set a goal

Constructed scenario, not a real project.

A colleague hands you this: "The wire-bond process keeps failing pull-strength testing because the bonder settings drift, and maintenance needs to recalibrate it weekly." You are told the actual data behind it: over the last 1,000 wire bonds, 42 fell below the minimum pull strength, against a target reject rate of 1.0 % or lower. Tasks. (a) Identify what is wrong with the statement as given. (b) Rewrite it as a proper problem statement. (c) Write a goal statement with a number and a plausible timeframe. (d) What is the sigma level (with the 1.5σ shift) of the current state, and of the goal state?

Exercise 2: build a CTQ tree and classify it

Constructed scenario, not a real customer interview.

A customer says: "The bracket assembly is fine, but I wish it were lighter — that would actually be a nice surprise, nobody's asked for it before." Tasks. (a) Identify the driver behind this VOC statement. (b) Propose one measurable CTQ (target and tolerance) for it. (c) Using the Kano model, classify this requirement, and justify your answer from the customer's own wording.

Quiz

Ten questions. Score 70 % or more to mark the module complete on this device.

Key takeaways

• A problem statement names a measurable gap: what, where, since when, how big — with no cause and no proposed fix.
• A charter is a contract: business case, problem statement, goal statement (a number and a date), scope with explicit boundaries, timeline, sponsor and team.
• The Kano model classifies requirements as must-be (absence dissatisfies, presence earns no credit), one-dimensional (linear trade-off), or attractive (absence unnoticed, presence delights); the category changes how a charter should set the target.
• VOC to CTQ translation (Griffin and Hauser) always passes through a driver: verbatim customer statement, then driver, then a measurable target and tolerance. Stopping at the driver produces an unmeasurable requirement.
• A stakeholder power/interest grid, done on paper before kickoff, surfaces who can block an Improve-phase change before that change is proposed, not after.
• A real-world published case (Sharma and Rao 2014) is cited as published, with a source; this course's own triple-check verification protocol applies to constructed examples, not to someone else's real data.
• A project that cannot state, in one sentence, the one number it will report at closure is not ready to leave Define.

References

All web sources accessed 2026-09-09 unless noted. Sources marked "secondary" were not read in the original by the course author; the claim is taken from the source shown.

1. Kano, N., Seraku, N., Takahashi, F., & Tsuji, S. (1984). Attractive quality and must-be quality. Journal of the Japanese Society for Quality Control, 14(2), 147–156. https://www.jstage.jst.go.jp/article/quality/14/2/14_KJ00002952366/_article/-char/en
2. Griffin, A., & Hauser, J. R. (1993). The voice of the customer. Marketing Science, 12(1), 1–27. https://pubsonline.informs.org/doi/10.1287/mksc.12.1.1
3. Linderman, K., Schroeder, R. G., Zaheer, S., & Choo, A. S. (2003). Six Sigma: a goal-theoretic perspective. Journal of Operations Management, 21(2), 193–203. https://pure.psu.edu/en/publications/six-sigma-a-goal-theoretic-perspective/
4. Schroeder, R. G., Linderman, K., Liedtke, C., & Choo, A. S. (2008). Six Sigma: definition and underlying theory. Journal of Operations Management, 26(4), 536–554. https://strategicimprovementsystems.com/wp-content/uploads/2011/07/PAPER_SIX_SIGMA.pdf
5. ASQ. Certified Six Sigma Green Belt (CSSGB) Body of Knowledge Map 2014–2022. ASQ, 2022. https://www.asq.org/cert/resource/pdf/certification/2022-CSSGB-BoK-Map.pdf
6. Sharma, G. V. S. S., & Rao, P. S. (2014). A DMAIC approach for process capability improvement: an engine crankshaft manufacturing process. Journal of Industrial Engineering International, 10, 65. https://link.springer.com/article/10.1007/s40092-014-0065-7
7. Pyzdek, T., & Keller, P. A. (2018). The Six Sigma Handbook, 5th ed. McGraw-Hill. https://www.accessengineeringlibrary.com/browse/six-sigma-handbook-fifth-edition (secondary: catalogue-level; general charter template reference)
8. Harry, M., & Schroeder, R. (2000). Six Sigma: The Breakthrough Management Strategy Revolutionizing the World's Top Corporations. Currency/Doubleday. https://books.google.com/books/about/Six_Sigma.html?id=RY0rAAAAYAAJ (secondary: catalogue-level; savings claims in this book are not repeated as fact; further reading, no claim on this page rests on it)