The Define Phase, Deep-dive Course
A practical walkthrough of objectives, tools, and steps — illustrated with a mid-sized IT project from charter to gate review.
What is the Define phase?
Six Sigma is a data-driven methodology for reducing defects and variation, organized around the DMAIC framework: Define, Measure, Analyze, Improve, and Control. Define is where a project is born — before anyone collects a single data point, the team agrees on the problem, why it matters, who is affected, what success looks like, and what's explicitly out of bounds.
Think of Define as writing the project's constitution. Everything in Measure, Analyze, Improve, and Control refers back to the agreements made here. Skipping or rushing it is the single biggest reason improvement projects stall later — teams end up measuring the wrong thing, chasing scope creep, or losing sponsor support because no one agreed on the goal in the first place.
Alignment
The sponsor, team, and stakeholders describe the problem and goal the same way.
Clarity
The problem, goal, and scope are written down, specific, and based on data — not opinion.
Commitment
The sponsor has formally approved the charter and committed budget, time, and people.
Foundation
The project is scoped well enough that Measure knows exactly what to collect.
What Define needs to answer
By the end of Define, the team should have a documented, sponsor-approved answer to each of these.
| Objective | Question it answers |
|---|---|
| Business case | Why does this project matter right now, and what happens if we do nothing? |
| Problem statement | What, specifically, is wrong — backed by baseline data? |
| Goal statement | What measurable result will we achieve, and by when? |
| Scope | Where does the project start and stop — process, systems, org boundaries? |
| Stakeholders | Who is impacted, who has authority, and who needs to be informed? |
| Financial benefit | What is this worth in hard or soft dollars, and who validates that number? |
| Team & governance | Who is on the team, and who is the sponsor / process owner? |
Tools used in the Define phase
| Tool | Purpose |
|---|---|
| Project charter | Single source of truth for problem, goal, scope, team, and timeline |
| SIPOC diagram | High-level view of Suppliers, Inputs, Process, Outputs, Customers |
| Voice of the Customer / Kano model | Captures what customers actually need, translated into requirements |
| CTQ tree (critical-to-quality) | Breaks broad customer needs into specific, measurable requirements |
| Stakeholder analysis / RACI matrix | Maps who is Responsible, Accountable, Consulted, Informed |
| High-level "as-is" process map | Visualizes the current process to confirm scope and boundaries |
| Pareto chart | Prioritizes which problem(s) to tackle first using existing data |
| Affinity diagram | Organizes qualitative input (interviews, complaints) into themes |
| Cost-benefit / financial analysis | Quantifies hard and soft savings tied to the project |
| Communication plan | Defines what gets communicated, to whom, how often, by whom |
| Schedule & budget | Sequences work across all five DMAIC phases with resourcing |
| Define gate review checklist | Formal go / no-go checklist before moving into Measure |
A mid-sized IT project
To make each step concrete, this course follows one project from charter to gate review.
Case: IT service desk ticket resolution
- Company: a 2,200-employee mid-sized company with one internal IT service desk
- Symptom: average incident resolution time is 3.5 business days against a published SLA of 1 business day
- Volume: roughly 850 tickets per month, ~40% categorized as "password/access" or "software install" issues
- Impact: productivity complaints have risen and internal IT satisfaction (CSAT) dropped from 4.2 to 3.1 out of 5 over two quarters
- Sponsor: VP of IT Operations · Process owner: Service Desk Manager
We'll return to this "Service Desk Project" at every step below.
Step-by-step through Define
Define isn't one document — it's a sequence of steps, each building on the last and needing its own validation before the team moves forward. Click a step to expand it.
1 Develop the project charter
The charter is the anchor document for the whole project: business case, problem statement, goal statement, scope, team, timeline, and expected benefits.
IT example — charter
- Business case: SLA breaches are driving escalations and quietly costing productivity across every department.
- Problem statement (draft): average ticket resolution time is 3.5 days vs. a 1-day SLA, based on the last 90 days of data.
- Goal statement (draft): reduce average resolution time to 1 business day within 6 months without adding headcount.
- Team: Sponsor (VP of IT Ops), Process Owner (Service Desk Manager), Green Belt Lead, 2 service desk analysts, 1 systems engineer.
2 Validate the problem statement
A charter's problem statement is a hypothesis until it's checked against real data. Validation confirms it's specific, measurable, time-bound, and free of assumed causes or solutions.
- Pull the actual baseline data — don't rely on anecdote or the charter draft alone.
- Confirm the gap is real and material, not a one-off spike or measurement error.
- Strip out any embedded root cause or solution.
- Get the process owner and sponsor to confirm the numbers.
IT example — validation
- 90 days of ServiceNow data shows average resolution is actually 3.6 days, with password/access tickets averaging 4.1 days despite being the simplest type.
- Validated statement: "Over the last 90 days, average IT incident resolution time was 3.6 business days against a 1-day SLA, with the largest gap in the highest-volume category (password/access, 40% of volume)."
3 Solidify goals and financial benefits
The goal statement gets locked down using SMART criteria, and the financial case is quantified well enough for finance or the PMO to sign off.
- Convert the goal into a specific numeric target and deadline.
- Separate hard savings (direct, bookable) from soft savings (productivity, satisfaction, risk avoidance).
- Have finance sanity-check the benefit estimate — credibility matters more than size.
IT example — goals & financial benefit
- Goal: reduce average resolution from 3.6 to 1 day within 6 months; password/access tickets under 4 hours.
- Hard savings: ~1,200 hours/year of recovered productivity, ≈$54,000/year in loaded labor cost.
- Soft benefits: projected CSAT recovery from 3.1 to 4.0+, fewer escalations to managers.
- Total estimated annual benefit: ~$70,000, validated with the Finance business partner.
4 Validate the process map and scope
The team builds a high-level "as-is" process map — often a SIPOC — and uses it to draw a hard line around what is and isn't in scope, before scope creep starts.
- Map the process at a high level: 5–10 steps, not a detailed flowchart.
- Identify the explicit start and end points.
- Walk the map with people who actually do the work, not just the process owner.
- Write explicit in-scope and out-of-scope statements.
IT example — process map & scope
- SIPOC: Suppliers (employees, monitoring systems) → Inputs (ticket submissions, alerts) → Process (log → triage → assign → resolve → close) → Outputs (resolved ticket) → Customers (end users, managers).
- In scope: intake, triage, assignment, resolution, and closure of incident tickets.
- Out of scope: hardware procurement lead times, new-employee onboarding provisioning, enhancement/feature requests.
5 Create a communication plan
A communication plan makes sure the right people hear the right information at the right cadence, without turning every stakeholder into a bottleneck.
| Audience | Frequency | Channel |
|---|---|---|
| Sponsor (VP of IT Ops) | Weekly | 15-min status call |
| Steering committee | Monthly | Steering deck |
| Service desk staff | Bi-weekly | Team huddle |
| End users / departments | At major milestones | Intranet post |
6 Develop a schedule, budget, and set milestones
The team lays out a realistic timeline across all five DMAIC phases, attaches a budget, and defines checkpoints for tracking progress.
IT example — schedule, budget & milestones
- Schedule: Define (weeks 1–2), Measure (3–5), Analyze (6–8), Improve (9–14), Control (15–18) — about 4.5 months.
- Budget: ~$18,000 — team labor, a minor ticketing-tool configuration change, and staff training.
- Milestones: charter approved (end of week 1), Define gate passed (end of week 2), root causes confirmed (week 8), new process piloted (week 12), full rollout (week 18).
7 Complete the Define gate review
The gate review is the formal checkpoint where the sponsor and champion review everything produced so far and make a go/no-go decision before the team spends Measure-phase time and budget.
- Confirm the charter is complete and signed by the sponsor.
- Confirm the problem statement is validated against real baseline data.
- Confirm the goal statement is SMART and the financial benefit is credible.
- Confirm the process map, scope, and boundaries are agreed upon.
- Confirm the communication plan, schedule, budget, and milestones are documented.
- Sponsor and champion formally approve moving into Measure.
IT example — gate review outcome
- The VP of IT Ops and Service Desk Manager review the completed charter, validated problem statement, financial benefit, SIPOC/scope, communication plan, and schedule in a 30-minute meeting.
- Outcome: approved to proceed to Measure, with one condition — add the change-management team as an "Informed" stakeholder.
Define phase deliverables
Use this as your exit checklist before requesting a Define gate review. Checks are saved in your browser.
Key takeaway
- Define succeeds when the team, sponsor, and stakeholders can all describe the problem, goal, and scope the same way, using the same numbers — and everyone has signed off before a single measurement begins.
Define phase belt challenge
Eight rapid-fire questions. Answer well and earn a belt rank.
Final score: / 8
Five-question review
A short, focused check on the core concepts.
Quiz complete
Score: / 5