Lean Six Sigma Define Phase Guide with Example and Key Deliverables

A Yellow Belt project can fail before anyone measures a single data point. The usual reason is simple: the team starts with a vague concern, jumps to a favorite fix, or lets the scope grow until the project becomes too large to finish.

The Define phase prevents that. It turns a concern into a clear, approved project. By the end of Define, the team should know what problem is being addressed, why it matters, who needs to be involved, where the process starts and ends, and how success will be measured.

For Yellow Belt projects, Define does not need to be complicated. It does need to be disciplined.

Define starts by turning a concern into something the team can inspect.

What the Define phase is meant to accomplish

The Define phase is the first phase of DMAIC: Define, Measure, Analyze, Improve, and Control. Its purpose is to frame the project before the team invests time collecting detailed data or testing changes.

In practical terms, Define answers five questions:

1. What performance gap appears to exist?

2. Is the gap measurable?

3. Why does the gap matter to the business or customer?

4. What result should the project achieve?

5. What is inside and outside the project boundary?

   
   

A strong Define phase protects the team from three common mistakes.

The first is solving the wrong problem. A complaint may sound urgent, but the true process gap may sit somewhere else.

The second is starting with an assumed cause. “Orders are late because people are not trained” is not a problem statement. It is a guess.

The third is trying to fix too much. A Yellow Belt project should be focused enough to complete with the time, data, and authority available.

Key deliverables in the Define phase

The main Define deliverables are simple, but each one has a job to do.

Deliverable	Purpose
Initial evidence of a performance gap	Shows why the project is worth considering
Confirmed measurable gap	Proves the issue can be measured against an expectation
Problem statement	Describes what, where, when, and how big the issue is
Business and customer impact	Explains why the issue matters
Project goal	Defines the target result and completion date
Stakeholder and team list	Identifies owners, affected groups, experts, and approvers
VOC and CTQs	Converts needs into measurable requirements
High-level SIPOC	Frames the process from suppliers to customers
Scope statement	Defines what is included and excluded
Initial project plan	Sets activities, owners, dates, resources, and tollgates
Financial validation	Confirms benefits, costs, and approval
Define tollgate review	Checks readiness to move into Measure

These deliverables do not sit in separate boxes. They connect. For example, the VOC helps shape CTQs, CTQs influence the goal, and the SIPOC helps confirm scope.

What to expect during Define

Define often feels slower than expected because the team is reducing ambiguity. That is normal.

Expect questions such as:

• Are we describing the problem or guessing the cause?

• Do we have evidence, or only opinions?

• Which customer is affected?

• What does “late,” “defective,” “poor,” or “slow” mean in measurable terms?

• Who can approve the project goal and scope?

• Will this project fit a Yellow Belt level of authority?

  
  

The team should also expect some rework. A first draft of the problem statement may be too broad. A SIPOC may reveal that the wrong start point was chosen. A stakeholder review may show that a key approver was missing.

That rework is useful. It is far better to correct the project charter in Define than to discover halfway through Measure that the team collected data for the wrong process.

A clear process boundary keeps the project from becoming too broad.

A complete Define phase example

The example below shows how a Yellow Belt team might conduct Define for a warehouse order fulfillment process.

The organization ships replacement parts to service technicians. Technicians need the right parts on time so they can complete customer repairs during scheduled visits.

Document the initial evidence of a performance gap

The warehouse supervisor notices repeated complaints from technicians about parts arriving later than expected.

Initial evidence includes:

• Technician emails reporting late shipments.

• A weekly operations report showing missed same-day shipment cutoffs.

• Customer service notes showing rescheduled repair appointments linked to missing parts.

• Informal feedback from packers who say orders often wait for label correction.

  
  

At this point, the team has evidence of concern, not yet a fully confirmed project.

Confirm that a measurable difference exists

The expected performance is that 95% of technician parts orders entered before 2:00 p.m. ship the same day.

A quick review of recent shipping records shows that over the last four weeks, 82% of eligible orders shipped the same day.

That confirms a measurable gap:

Measure	Expected performance	Current performance	Gap
Same-day shipment rate for eligible orders	95%	82%	13 percentage points

The project is now grounded in data. The team still does not know why the gap exists, and should not claim to know yet.

Write the problem statement

A good problem statement describes the problem without cause or solution.

Weak version:

Orders are late because the warehouse team does not process labels fast enough, so we need a new labeling system.

This assumes a cause and proposes a fix.

Better version:

Over the past four weeks, from March 4, 2026, to March 28, 2026, 82% of technician parts orders placed before 2:00 p.m. at the main parts warehouse were shipped on the same day. This falls short of the anticipated same-day shipment rate of 95%, indicating a 13 percentage point gap for eligible orders.

This version states what is happening, where it happens, when it was observed, and the size of the issue.

Identify the business and customer impact

The team then describes why the gap matters.

Business and customer impacts may include:

• Delivery

  Technicians do not receive parts in time for scheduled service visits.

  
  

• Customer experience

  Customers may need to reschedule repair appointments.

  
  

• Cost

  The company may pay extra shipping charges to recover from late orders.

  
  

• Employee workload

  Customer service and warehouse staff handle more follow-up calls and rework.

  
  

• Reliability

  Field service schedules become less predictable.

  
  

The impact statement should be specific enough to justify the project, but not padded with claims the team cannot support.

Establish the project goal

The goal should be measurable and time-bound.

Example goal:

SMART Goal

Specific: Increase the same-day shipment rate for eligible technician parts orders at the main parts warehouse.

Measurable: Raise the shipment rate from 82% to a minimum of 95%.

Achievable: Implement process improvements and training for staff to ensure timely order processing and shipping.

Relevant: This goal aligns with the company's objective to enhance customer satisfaction and operational efficiency.

Time-bound: Achieve this goal by June 30.

Complete SMART Goal Statement

By June 30, increase the same-day shipment rate for eligible technician parts orders at the main parts warehouse from 82% to a minimum of 95% by implementing process improvements and staff training to enhance operational efficiency and customer satisfaction.

This goal matches the performance gap. It also avoids naming a solution. The team has not yet completed Measure or Analyze, so it should not commit to a fix.

SMART Goal Statement

Identify stakeholders and team members

The Yellow Belt now identifies who needs to be involved.

Role	Example participant	Why they are involved
Process owner	Warehouse supervisor	Owns daily order fulfillment
Project sponsor	Operations manager	Approves direction and resources
Yellow Belt lead	Shipping coordinator	Leads project work and updates
Subject matter expert	Senior picker	Knows picking and staging reality
Affected group	Service technicians	Receive the parts
Support function	Customer service representative	Sees complaint and reschedule data
Approver	Finance controller	Reviews financial benefits and costs
Data support	Systems analyst	Helps pull order and shipping data

This list helps prevent surprises. It also ensures the team includes people who understand the actual work, not only the report.

Translate the VOC into measurable CTQs

VOC means Voice of the Customer. It captures what customers need, in their own language. CTQ means Critical to Quality. It converts those needs into measurable characteristics.

For this project, customers include technicians and the end customers waiting for repairs.

VOC statement	Customer need	CTQ	Specification	Operational definition
“I need parts before my morning route starts.”	Parts arrive on time	Same-day shipment rate	At least 95%	Percent of orders entered before 2:00 p.m. that receive carrier scan by end of scheduled shipping day
“I cannot repair the unit if one item is missing.”	Complete order	Order completeness	99% or higher	Percent of shipped orders containing all requested line items
“I need to know if a part will not ship.”	Clear status	Exception notification time	Within 1 business hour	Time from known shipment exception to technician notification

CTQs matter because they remove vague language. “Fast” becomes a shipment cutoff. “Complete” becomes order accuracy. “Clear” becomes notification time.

VOC to CTQ Same-Day Parts Shipping, and 95% Target.

Create the high-level SIPOC

A SIPOC gives a high-level view of the process. It shows suppliers, inputs, process steps, outputs, and customers.

For this example, the process starts when an eligible technician parts order enters the warehouse queue and ends when the carrier scans the shipment.

Suppliers	Inputs	Process steps	Outputs	Customers
Field service system	Technician parts order	Receive order in queue	Shipped parts order	Service technician
Inventory system	Item availability data	Pick parts	Shipment tracking record	Customer service
Warehouse staff	Packing materials	Pack order	Exception notice if not shipped	End customer
Carrier	Shipping label requirements	Create label		Operations
		Stage for carrier pickup
		Carrier scan

The SIPOC also helps the team avoid getting pulled into unrelated areas, such as supplier purchasing delays or technician scheduling, unless those are inside the agreed scope.

SIPOC For Same-Day Parts Shipping

Establish the project scope and boundaries using the Is, Is Not Matrix

Scope defines what the project includes and excludes.

Included "IS":

• Technician parts orders entered before 2:00 p.m.

• Orders processed through the main parts warehouse.

• Same-day shipment performance.

• Picking, packing, labeling, staging, and carrier scan steps.

  
  

Excluded "IS NOT":

• Orders entered after 2:00 p.m.

• Backordered parts not available in inventory.

• Supplier lead times.

• Repair scheduling after parts ship.

• Other warehouses.

  
  

This boundary keeps the project manageable for a Yellow Belt. It also makes the Measure phase cleaner because the team knows which orders count.

Is Is Not Tool For Same-Day Parts Shipping

Develop the initial project plan

The initial plan does not need every detail. It should show the main work, owners, resources, deliverables, and tollgate dates.

Phase	Key activities	Owner	Deliverable	Target date
Define	Charter, SIPOC, VOC, CTQs, scope, financial estimate	Yellow Belt lead	Approved Define tollgate	March 15
Measure	Data collection plan, baseline validation, process observation	Yellow Belt lead and systems analyst	Measure tollgate	April 12
Analyze	Cause review, data stratification, process checks	Project team	Analyze tollgate	May 10
Improve	Select and test improvements	Project team	Improve tollgate	June 7
Control	Control plan, handoff, follow-up metric	Process owner	Control tollgate	June 30

The plan should also name needed resources, such as direct access to shipping data, time with warehouse staff, and support from the systems analyst.

Validate the project financials

Even small Yellow Belt projects need financial review. The goal is not to inflate benefits. The goal is to make sure the expected benefit is reasonable and approved.

For the warehouse example, expected benefits may include:

• Fewer expedited shipments.

• Less customer service follow-up time.

• Fewer rescheduled visits linked to late parts.

• Less warehouse rework.

  
  

Project costs may include:

• Team time.

• Data support time.

• Minor supplies for process changes.

• Possible system configuration fees, if later approved.

  
  

The Yellow Belt reviews these assumptions with the finance controller. The controller confirms which benefits can be counted, which should only be described as soft benefits, and whether the estimated return supports continuing the project.

Review the Define tollgate questions

Before moving to Measure, the team should review the Define tollgate.

Useful questions include:

• Is the performance gap supported by evidence?

• Is the gap measurable against a clear expectation?

• Does the problem statement avoid causes and solutions?

• Are business and customer impacts stated clearly?

• Is the project goal measurable and time-bound?

• Are the process owner, sponsor, affected groups, experts, and approvers identified?

• Have VOC statements been translated into CTQs?

• Does the SIPOC show clear start and stop points?

• Is the scope narrow enough for a Yellow Belt project?

• Does the project plan include activities, dates, responsibilities, resources, deliverables, and tollgates?

• Have financial assumptions been reviewed and approved?

  
  

If the answer is yes, the project is ready for Measure.

A good Define phase leaves the team ready to measure the right process.

The Define phase sets the quality of the whole project

The Define phase is not paperwork for its own sake. It is the part of the project where the team earns clarity.

A strong Define phase gives a Yellow Belt project a clear problem, a clear customer, a clear target, and a clear boundary. It also gives sponsors and process owners confidence that the team is working on a real gap, not a guess.

The best next step is simple: take one current process concern and draft the Define deliverables before discussing solutions. If the problem cannot be measured, scoped, and tied to a customer or business impact, it is not ready for DMAIC yet.