Define: What Does the Customer Count as a Defect?

"The approval process is too slow." I have heard that sentence in more kickoff meetings than I can count, and it has never once been a usable problem statement. It is a complaint, and complaints are fine as starting points, but nothing in it can be measured, so nothing in it can ever be proven fixed. The cost of that vagueness shows up months later. The project closes, someone says things feel faster, someone else says they feel the same, and neither of them is wrong, because "slow" was never defined. The Define phase exists to prevent that argument by settling, before any work starts, what is failing, for whom, and how anyone would know.

A defect is whatever the customer says it is

In Six Sigma a defect is any output that fails to meet a customer requirement. The important word is customer. It is not what the team considers acceptable, and it is not the average the dashboard reports. Take the property management team from yesterday, handling tenant fit-out requests. Internally the team feels reasonably quick. But tenants are promised a decision within five working days, and a tenant whose contractor is booked for Monday experiences a decision on day six as a failure, whatever the team's average looks like. So the defect is a decision communicated later than five working days after a complete submission. That sentence can be counted, and a vague complaint has just become a measurable problem.

The method behind that move is called capturing the voice of the customer and translating it into critical-to-quality requirements, usually shortened to CTQs. You gather what customers actually say, from complaints, call notes, survey comments and short interviews, then convert each loose word into something measurable. "Slow" becomes the working days from complete submission to decision. "Confusing" becomes the share of requests returned because information was missing. "Unreliable" becomes the share of decisions later changed. Each CTQ needs four things written down: the measure, the unit, the target, and the exact points where the clock starts and stops.

That last item is where arguments hide, so decide it early and decide it from the customer's side. If the clock starts when the team receives a complete request, the team will look faster than if it starts when the tenant presses submit. Neither is wrong, but only one matches what the tenant feels, and the tenant is the one whose definition of a defect governs this project.

Writing a problem statement that can be tested

A usable problem statement has a simple shape: what is failing, how often, since when, and what it costs, with no cause and no solution smuggled in. For the fit-out example it might read: tenants are promised a decision within five working days; escalations about late decisions reached the regional manager 14 times last quarter, up from 4 the quarter before; the current share of requests that miss the promise has not been measured. Notice the final clause. A good Define statement is honest about what is not yet known, and here the unknown is exactly what Wednesday's Measure phase will establish.

Two failures are common enough to name. The first is a solution disguised as a problem: "we need a new workflow tool" tells you what someone wants to buy and nothing about what is failing. The second is a cause disguised as a problem: "approvals are slow because the engineers are overloaded" may be true, but stating it now closes the investigation before it starts, and the data often points somewhere else. Keep the problem statement about the symptom the customer feels, and let the later phases earn the cause.

The goal line follows the same discipline. State it as a number with a date, for example no more than 10 percent of requests later than five working days within twelve weeks, and mark it provisional until the baseline confirms that the target is realistic. A goal set before anyone has seen the data is a guess wearing a suit.

A short test helps before moving on: read the defect definition aloud to someone who has never seen the process and ask how they would count it. If they ask a clarifying question, such as whether weekends count, or whether the clock stops while the tenant is asked for missing drawings, the definition is not finished. Every clarifying question collected now is an argument avoided in the Measure phase, when the numbers are on the table and everyone has a stake in them.

The one-page charter, and the scope line most people skip

Everything above fits on a single page called the project charter, and the page matters more than its length suggests. A useful charter holds six things:

• The problem statement and the CTQ it relies on, written as above.
• The business case: what the problem costs in time, money, escalations or lost tenants, so the sponsor can see why this deserves attention over other work.
• The goal, as a number and a date, marked provisional until the baseline is in.
• The scope, including what is explicitly out.
• The sponsor and the people who will be affected or asked for data.
• A rough timeline, with the points at which the sponsor will see progress.

The scope line deserves extra care because it is the one most analysts skip and later regret. For the fit-out project it might say: starts when a tenant submits a complete request, ends when the tenant receives the decision; excludes construction scheduling and the municipal permit process that follow approval. Scope boundaries stop a focused project from quietly growing into everything adjacent, and they connect to last week's lesson about systems. A boundary is a working decision, not a claim that nothing outside it matters, so note the neighbouring processes that your changes could affect and revisit them before anything ships.

The charter's most important job is agreement. A sponsor's signature turns a private idea held by the analyst into a shared commitment, in the same way that last week's read-back turns a workshop discussion into a decision nobody can quietly walk back. If the sponsor will not sign a one-page statement of the problem, that is valuable information at the cheapest possible moment, because it means the project would have stalled at a far more expensive one. Tomorrow moves to the phase most teams rush through: measuring how the process actually performs today.

Go out and be successful.

Oluwatosin Ogunkoya · Flotog BA Insights · 1:1 mentoring and coaching for BAs at every career stage · www.flotogbainsights.com

TOMORROW

Measure: Get a Baseline Before You Believe Anyone - How to find out how the process really performs today, with no statistics team and no special software.