Six Sigma Define Phase Explained: Goals, Deliverables, and Tools
The Six Sigma Define phase is where a DMAIC project earns the right to exist. Before anyone builds a control chart or hunts for root causes, you need a clear problem, a customer-backed reason to act, a tight scope, and a sponsor who agrees on what success means. For professionals building structured process improvement skills, a Certified Six Sigma Expert pathway can provide a useful foundation for understanding how Define sets up the rest of a DMAIC project.
ASQ describes DMAIC as a data-driven improvement cycle, and Define is the stage that frames the data question. Get this part wrong and the team may measure the wrong process for weeks. I have watched charter reviews stall over one vague phrase: improve turnaround time. Improve it where? For whom? By how much? That is exactly the kind of ambiguity Define is meant to remove.

What Is the Six Sigma Define Phase?
The Six Sigma Define phase is the first step in DMAIC: Define, Measure, Analyze, Improve, and Control. Its purpose is to state the business problem, identify customers and stakeholders, clarify the process boundaries, and set measurable project objectives.
Think of it as project initiation with sharper discipline. A good Define phase answers four questions:
Why does this project matter? Link the problem to cost, quality, risk, revenue, compliance, or customer experience.
Who is affected? Identify customers, process owners, sponsors, frontline teams, and support functions.
What is in scope? Define the start and end points of the process. Also state what is out of scope.
How will success be measured? Convert the problem into specific targets such as defect rate, cycle time, error rate, wait time, or rework cost.
For professionals connecting process improvement with broader leadership and organizational capabilities, Management Certifications can complement this foundation by supporting skills related to stakeholder coordination, project planning, and business management.
Goals of the Define Phase
The main goal is not to solve the problem. Not yet. The goal is to make sure you are solving the right problem.
Clarify the business problem
A strong problem statement names what is wrong, where it occurs, when it occurs, and how large the impact is. Compare two versions. Invoice corrections increased from 4.8 percent to 9.6 percent in the EMEA shared services process during Q2, causing delayed payments and extra review work is far better than billing is inefficient.
Translate customer needs into CTQs
Voice of the Customer, or VOC, should not stay as raw comments. You translate it into Critical to Quality requirements, often called CTQs. If customers say loan approvals are slow, the CTQ may become approval decision within 48 hours for complete applications. That target then guides Measure and Analyze.
Set boundaries before scope creep starts
Define protects the team from a classic mistake: turning one process issue into an enterprise transformation project. Be blunt. If the project covers order entry errors, do not let it drift into pricing policy, supplier contracts, and CRM redesign unless the sponsor formally changes the charter.
Align stakeholders early
Many Six Sigma projects fail for social reasons, not statistical ones. A process owner may fear blame. A sales leader may resist a new approval rule. A finance sponsor may want savings reported in a specific format. Stakeholder analysis surfaces these issues before the Improve phase becomes political.
Key Deliverables in the Six Sigma Define Phase
Define should produce reviewable documents, not hallway agreement. At a tollgate review, these deliverables show whether the project is ready to move into Measure.
Project charter
The project charter is the core Define document. It usually includes:
Problem statement
Business case and expected impact
Goal statement with measurable targets
In-scope and out-of-scope items
Process start and end points
Timeline, milestones, risks, assumptions, and constraints
Sponsor, process owner, Black Belt or Green Belt, and team members
SIPOC or high-level process map
A SIPOC diagram lists Suppliers, Inputs, Process, Outputs, and Customers. It is simple, but useful. In healthcare admissions, for example, a SIPOC can show that the delay is not only at registration. Missing referral information, insurance checks, and duplicate data entry may all sit upstream.
VOC and CTQ documentation
VOC inputs can come from surveys, interviews, complaints, call transcripts, service tickets, audits, and account reviews. The output should be a CTQ tree or CTQ list that connects customer language to measurable process requirements.
Stakeholder and communication plan
List who has influence, who is affected, what they care about, and how often they need updates. A weekly email may work for support teams. Sponsors often need a short monthly view of benefits, risks, and decisions required.
Initial project plan and risk register
Large organizations often add a Gantt chart, resource estimate, risk register, and milestone plan. PERT and Critical Path Method can help where dependencies are heavy, such as multi-site operations or regulated change control.
Core Tools Used in Define
The most common Six Sigma Define phase tools are practical rather than complex:
Project charter: authorizes the work and locks the business problem, scope, and goals.
VOC analysis: captures needs through surveys, interviews, complaints, and operational feedback.
CTQ tree: converts broad needs into measurable requirements.
SIPOC: defines process boundaries and major handoffs.
Stakeholder analysis: maps interest, influence, support, and likely resistance.
In-scope and out-of-scope list: keeps the project manageable.
Kano model and QFD: help prioritize customer requirements when teams disagree on what matters most.
Benchmarking: supports realistic targets by comparing performance with internal sites, competitors, or industry standards.
How Define Has Changed in Recent Practice
Define has become more standardized and more cross-functional. Charters, SIPOC diagrams, VOC summaries, CTQ trees, stakeholder maps, and communication plans are now treated as expected baseline outputs in many Lean Six Sigma toolkits.
There is also more emphasis on digital data. VOC is no longer limited to survey responses. Teams now pull evidence from CRM notes, contact center tags, product analytics, Google Analytics 4 events, Salesforce cases, and complaint databases. That helps, but do not confuse more data with a better definition. If the problem statement is muddy, dashboards will only make the confusion look official.
When the Define phase involves technology platforms, analytics infrastructure, automation, or digital transformation, broader technical understanding can also help teams frame realistic project boundaries. A Deep Tech Certification pathway can complement process improvement knowledge with technology-focused learning.
Common Define Phase Mistakes
Writing a solution as the problem: Need automation is not a problem statement. It is a proposed fix.
Skipping VOC: Internal metrics can improve while customers still feel the process is broken.
Using weak goals: Reduce errors is too loose. State the baseline, target, and date.
Ignoring handoffs: Many defects appear where work moves between teams, systems, or shifts.
Overloading the charter: A Define charter should guide the project, not become a 40-page archive.
Building Define Phase Skills
If you are preparing for Six Sigma work, spend extra time on charters, SIPOC, VOC, and CTQ trees. These tools show up in real projects and in certification assessments because they test judgment, not memorization. That is where candidates lose marks: they can recite the SIPOC acronym but cannot write a problem statement that survives a tollgate.
The Universal Business Council Six Sigma certification pathways and related process improvement courses cover these Define tools in applied detail. If your role touches operations, product, customer experience, analytics, or project governance, start by drafting a one-page charter for a live process problem this week. Then ask one uncomfortable question: Would the customer agree this is the right problem to solve?
As Define work increasingly connects with digital systems, data analysis, automation, and technology-enabled operations, a Tech Certification pathway can provide complementary technology-focused learning.
FAQs
1. What is the Define phase in Six Sigma DMAIC?
The Define phase is the first stage of the Six Sigma DMAIC methodology:
Define → Measure → Analyze → Improve → Control
Its purpose is to clearly establish the business problem, customer requirements, project objectives, scope, stakeholders, and expected benefits before detailed data collection begins.
A successful Define phase answers several basic questions: What problem are we solving? Why does it matter? Who is affected? What process is involved? What does success look like?
Without clear answers, teams can perform excellent analysis on the wrong problem, which is impressively precise and commercially useless.
2. What is the main goal of the Define phase?
The main goal is to convert a broad business concern into a clear, measurable, and manageable improvement project.
For example:
Vague concern: “Customers are unhappy with delivery.”
A stronger definition is:
“On-time delivery averaged 84% during the past six months compared with the customer requirement of at least 97%, contributing to increased complaints and expedited shipping costs.”
The Define phase creates enough clarity for the team to determine what should be measured during the next DMAIC phase.
3. What are the main deliverables of the Define phase?
Typical Define-phase deliverables include the project charter, problem statement, goal statement, business case, project scope, SIPOC, Voice of the Customer analysis, CTQs, stakeholder analysis, high-level process map, project team structure, and preliminary timeline.
Not every organization uses identical documentation, but the essential output should be a shared understanding of the problem and project boundaries.
The Define phase is complete when stakeholders agree on what the project is trying to accomplish and why.
4. What is a Six Sigma project charter?
A project charter formally defines and authorizes the DMAIC project.
It typically documents the business case, problem statement, goal statement, scope, key metrics, expected benefits, team members, Champion or sponsor, process owner, milestones, and major constraints.
The charter acts as a reference throughout the project. If the project begins drifting into unrelated problems, the team can compare new requests with the agreed scope.
This is useful because scope creep rarely introduces itself politely as scope creep.
5. How do you write a Six Sigma problem statement?
A strong problem statement describes the performance gap using facts without assuming the root cause or prescribing a solution.
For example:
“During the past six months, 7.2% of packaged units failed final packaging inspection compared with the customer requirement of less than 2%, resulting in increased rework and material waste.”
The statement identifies what is wrong, where it occurs, how large the problem is, and why it matters.
Avoid statements such as “poorly trained employees are causing defects” unless analysis has already demonstrated that relationship.
6. What should not be included in a DMAIC problem statement?
The problem statement should generally avoid unverified causes and predetermined solutions.
Weak example:
“The outdated software causes long processing times, so a new system must be implemented.”
Better:
“Average application-processing time is 4.8 days compared with the customer requirement of 2 days.”
The second statement leaves room for Measure and Analyze to determine whether software, staffing, approvals, workload, rework, or some other factor drives the delay.
DMAIC works rather better when the conclusion is not written before the investigation begins.
7. How do you write a Six Sigma goal statement?
A goal statement defines the measurable improvement the project intends to achieve.
A useful goal should identify the metric, baseline, target, and expected completion period.
For example:
“Increase on-time delivery from the current baseline of 84% to at least 97% within six months without increasing total fulfillment cost per order.”
This provides a clear definition of success while also identifying a guardrail against undesirable side effects.
The goal should describe the desired outcome rather than dictate the solution.
8. What is the business case in the Define phase?
The business case explains why the organization should invest resources in the DMAIC project.
It connects the process problem to business consequences such as cost, revenue, customer satisfaction, productivity, capacity, risk, compliance, or strategic objectives.
For example, poor first-pass yield may generate $500,000 in annual scrap and rework costs while limiting production capacity.
A strong business case answers:
“Why should this project receive resources instead of another improvement opportunity?”
9. How is project scope defined in the Define phase?
Project scope establishes the boundaries of what the DMAIC project will and will not address.
For example:
In Scope: Order processing from receipt of a complete customer order through release to the warehouse.
Out of Scope: Manufacturing, transportation, and customer billing.
Clear scope prevents the team from trying to improve an entire end-to-end organization when the original project concerned one specific performance gap.
Large problems can usually be divided into several manageable improvement projects.
10. What is SIPOC and how is it used during Define?
SIPOC stands for:
Suppliers → Inputs → Process → Outputs → Customers
It provides a high-level view of the process and helps establish project boundaries.
For an order-fulfillment process, suppliers might provide customer orders, inventory, payment information, and shipping resources. The process transforms those inputs into outputs such as completed orders and delivery information, which are received by customers or downstream processes.
SIPOC gives the team enough process context to proceed without immediately disappearing into hundreds of detailed workflow steps.
11. How is Voice of the Customer used in the Define phase?
Voice of the Customer (VOC) captures what customers need, expect, value, or complain about.
VOC information can come from interviews, surveys, complaints, reviews, returns, support interactions, warranty claims, customer observations, and behavioral data.
For example:
VOC: “Orders arrive too late.”
The team translates this broad statement into a measurable requirement rather than treating the complaint itself as the final project metric.
VOC keeps DMAIC connected to customer value instead of internal assumptions about what customers ought to care about.
12. How are CTQs identified during the Define phase?
Critical-to-Quality characteristics (CTQs) translate customer needs into measurable requirements.
For example:
VOC: “I need reliable delivery.”
↓
Customer Need: Timely delivery
↓
CTQ: On-time delivery percentage
↓
Requirement: ≥ 98%
The progression is:
Customer Language → Need → CTQ → Measurable Requirement
CTQs help establish what the project should ultimately improve and provide a bridge between Define and Measure.
13. What is a CTQ Tree in the Define phase?
A CTQ Tree breaks a broad customer need into specific quality drivers and measurable requirements.
For example:
Customer Need: Reliable Order Fulfillment
↓
Quality Drivers: Speed + Accuracy + Condition
↓
CTQs: On-time delivery ≥ 98% + Order accuracy ≥ 99.5% + Damage rate ≤ 0.2%
The CTQ Tree prevents vague customer statements from remaining vague throughout the project.
Six Sigma is rather attached to converting “make it better” into something that can actually be measured.
14. How is a high-level process map used during Define?
A high-level process map shows the major stages within the project scope.
For example:
Receive Order → Validate → Approve → Fulfill → Ship
The map helps team members agree on the basic workflow, major process boundaries, and important handoffs.
Detailed process mapping normally occurs later when additional operational understanding is required.
During Define, the purpose is clarity rather than documenting every decision, exception, email, spreadsheet, and mysterious workaround developed in 2019.
15. Who should be involved in the Define phase?
The Define phase usually involves the project leader, Champion or sponsor, process owner, subject-matter experts, frontline representatives, and other relevant stakeholders.
The Champion ensures strategic alignment and helps remove organizational barriers. The process owner provides accountability for the process. Frontline employees contribute knowledge about how work actually happens.
Customer or customer-facing perspectives may also be important when defining requirements.
A project designed entirely by people who never perform or receive the process tends to discover reality rather late.
16. What is stakeholder analysis in the Define phase?
Stakeholder analysis identifies people or groups who influence the project, are affected by it, or can help or hinder implementation.
Stakeholders may include executives, process owners, employees, customers, suppliers, IT, finance, quality, compliance, and other functions.
The team considers factors such as stakeholder influence, interest, expected impact, support level, and communication needs.
Early stakeholder analysis can reduce implementation resistance later, particularly when proposed improvements cross departmental boundaries or alter responsibilities.
17. How are financial benefits estimated during Define?
The Define phase normally develops a preliminary estimate of the project's financial opportunity.
Potential benefits may include reduced scrap, lower rework, less overtime, reduced warranty expense, improved productivity, increased capacity, avoided capital spending, lower inventory, or retained revenue.
Suppose annual rework costs are $600,000, and preliminary analysis suggests a 40% reduction may be feasible.
The potential opportunity is approximately:
$600,000 × 40% = $240,000 annually
Finance should later validate the assumptions and classify benefits appropriately.
18. What are common mistakes during the Six Sigma Define phase?
Common mistakes include selecting a problem with little business impact, writing vague problem statements, embedding solutions in the project charter, using an excessively broad scope, ignoring VOC, failing to identify CTQs, setting unrealistic targets, and starting without an engaged sponsor or process owner.
Another mistake is spending so long perfecting the charter that the project never progresses.
Define should establish sufficient clarity and alignment for disciplined measurement. It is not intended to become a doctoral dissertation on the existence of the problem.
19. How do you know when the Define phase is complete?
Define is generally complete when the team and sponsor can clearly answer:
What is the problem?
Why does it matter?
Who is the customer?
What does the customer require?
Which CTQs are involved?
What process is in scope?
What performance improvement is expected?
Who owns and supports the project?
What business value could the improvement create?
A formal Define tollgate review may be used to confirm these deliverables before the project moves into Measure.
20. How should Six Sigma teams complete the Define phase successfully?
A disciplined Define phase follows a logical progression:
Identify Business or Customer Problem
↓
Confirm Strategic Importance
↓
Capture Voice of the Customer
↓
Translate Needs into CTQs
↓
Define the Problem Statement
↓
Establish the Business Case
↓
Set the Project Goal
↓
Define In-Scope and Out-of-Scope Boundaries
↓
Create SIPOC
↓
Develop High-Level Process Map
↓
Identify Stakeholders
↓
Assign Champion, Process Owner and Team
↓
Estimate Financial Opportunity
↓
Establish Preliminary Timeline
↓
Complete Project Charter
↓
Conduct Define Tollgate Review
↓
Move to Measure
For example, a vague concern such as:
“Customers complain about delivery.”
might become:
Problem Statement: On-time delivery has averaged 84% during the past six months compared with the customer requirement of 98%.
CTQ: On-time delivery percentage.
Goal: Increase performance from 84% to at least 98% within six months without increasing fulfillment cost per order.
Scope: From receipt of a complete order through shipment release.
Business Case: Reduce complaints, expedited freight, and customer-retention risk.
That transformation is the real work of Define:
Broad Concern → Customer Requirement → Measurable Problem → Clear Scope → Business Case → Project Goal
The Define phase does not solve the process problem. It makes sure the team is solving the right problem, for the right customer, within the right boundaries, for a reason the organization can defend.
Skipping that discipline can produce a technically impressive DMAIC project that solves something nobody particularly needed solved.
A fine achievement for a statistics exercise. Less compelling for a business.
Related Articles
View AllSix Sigma
Six Sigma DMADV Explained: Define, Measure, Analyze, Design, Verify
Six Sigma DMADV explained through its five phases, practical use cases, DMAIC comparison, and how professionals apply it to design for quality.
Six Sigma
How to Build a Six Sigma Project Charter Aligned with Business Goals
Learn how to build a Six Sigma project charter that connects scope, metrics, financial impact, and DMAIC goals to real business priorities.
Six Sigma
Six Sigma vs Project Management: Methods, Tools, and Career Paths
Compare Six Sigma vs Project Management across methods, tools, salaries, and career paths. Learn when to use DMAIC, Agile, Waterfall, or both.
Trending Articles
The Role of Blockchain in Ethical AI Development
How blockchain technology is being used to promote transparency and accountability in artificial intelligence systems.
AWS Career Roadmap
A step-by-step guide to building a successful career in Amazon Web Services cloud computing.
Top 5 DeFi Platforms
Explore the leading decentralized finance platforms and what makes each one unique in the evolving DeFi landscape.