Define: Scoping the Problem and the Project Charter
The Define phase converts a vague complaint into a bounded, measurable project. The central deliverable is the project charter, which fixes the problem statement, goal statement, business case, scope (in and out), team, sponsor, milestones and expected benefit. A good problem statement describes the gap - what happens, where, since when, and with what measurable effect - without naming a cause or a solution. The voice of the customer (VOC) feeds this: raw customer statements are translated into CTQs (critical-to-quality requirements) that are measurable and testable.
Candidates must also know SIPOC (Suppliers, Inputs, Process, Outputs, Customers), a high-level map used to agree scope boundaries, and the stakeholder analysis that identifies who can block or support the work. SMART goal statements (Specific, Measurable, Achievable, Relevant, Time-bound) are the standard test.
Common traps: questions offer a problem statement that already contains a cause ("the line is slow because of worn tooling") - reject it. Another trap confuses a goal with a solution ("install a new conveyor"). Watch for charters with no baseline metric or no defined scope boundary; both are defects. Also distinguish the sponsor (provides resources, removes barriers) from the process owner (accountable for the process after handover).
Worked example / rule of thumb: rewrite "Customers are unhappy with delivery" as "Between January and June, 18% of orders shipped later than the promised date, against a target of 2%." If you cannot attach a number and a time window, the statement is not yet a Define-phase problem statement.
Remember the DMAIC logic: Define sets the question the rest of the project must answer, so ambiguity here propagates everywhere downstream.