Define: Turning a Complaint into a Charter
What Define must produce
The Define phase converts a vague complaint into a scoped, measurable project. Concepts you must know: Voice of the Customer (VOC) gathered in customer language, then translated into Critical to Quality (CTQ) characteristics that can be measured; a problem statement stating what, where, when and how much; a goal statement tied to the CTQ; the business case and COPQ; scope boundaries (in / out); a high-level SIPOC; and team roles - sponsor/champion (funds the project, removes barriers), Belt (leads the work), process owner (owns the process and the gains after closure), subject-matter experts. Introduce Y = f(x) here: Y is the output metric, the x's are candidate causes the team will investigate later.
Traps questions exploit
- A problem statement that hides a solution ("we need new software") or a cause ("because operators are careless"). Both belong nowhere in Define.
- Confusing VOC (raw, qualitative) with CTQ (translated, measurable, with a target and specification).
- Scope creep presented as a helpful suggestion; in-scope/out-of-scope is a charter element, not an afterthought.
- Swapping sponsor and process owner, or claiming the Belt owns post-project results.
- A project with no baseline data - if the current performance cannot be measured, the work is Measure-first, not Improve.
Worked example
"Billing is a mess; IT should fix it" becomes: "From 1 Jan to 31 Mar, first-pass yield in the domestic billing queue was 71% against a 95% target, generating roughly $140k in rework; scope is domestic billing, collections excluded." Metric, baseline, gap, time frame, boundary - and no solution smuggled in.
Rule of thumb: if you cannot state the baseline number and its data source, you are not ready for a tollgate.