The Analyze Phase, deep-dive course
From a validated baseline to a statistically confirmed root cause — brainstorming, cause-and-effect tools, hypothesis testing, and DOE, worked through the same mid-sized IT project.
What is the Analyze phase?
Define named the problem. Measure produced a validated baseline. Analyze is where the team turns that baseline into a confirmed, statistically defensible root cause — the specific X (or few vital X's) that actually drives the Y everyone is trying to fix.
Analyze typically runs 2 to 3 weeks. It starts wide — every plausible cause on the table — and narrows systematically through data, not opinion, until only the vital few X's remain, each one backed by a statistical test rather than a hunch.
Use data to find probable causes
Mine the validated Measure-phase data for patterns before anyone brainstorms a single theory.
Find the actual root cause
Use brainstorming, the 5 Whys, and cause-and-effect tools to dig past symptoms to root causes.
Find the critical root cause
Of every plausible cause, identify the one (or few) with the highest impact on the CTQ.
Verify statistically
Confirm each root cause with the right statistical test — hypothesis testing, ANOVA, regression — not assumption.
Where the Service Desk Project stands
- Define: validated problem — average IT incident resolution time is 3.6 business days against a 1-day SLA. Goal: get to 1 day within 6 months.
- Measure: validated baseline — MSA confirmed the timestamp data is trustworthy (4% GRR); run charts showed a shift pattern partway through the data; ticket resolution time is right-skewed, not normal.
- Now — Analyze: the team has to explain why resolution time is 3.6 days, find the vital few X's driving it, and prove those X's statistically before Improve starts changing anything.
Tools Used in the Analyze Phase
| Category | Tools |
|---|---|
| Process analysis | Detailed process map, value stream mapping, waste analysis |
| Cause organization | Brainstorming, 5 Whys, fishbone (Ishikawa) diagram, fault tree analysis, affinity diagram, tree diagram, interrelationship digraph, FMEA |
| Mathematical foundations | Central Limit Theorem, continuous & discrete probability distributions |
| Hypothesis testing | 1-sample t-test, 2-sample t-test, paired t-test, one-way & two-way ANOVA, Mood's median test, chi-square test |
| Relationship analysis | Correlation, linear regression |
| Design of Experiments | Full & fractional factorial designs, Taguchi loss function, EVOP, Latin square and related designs |
Every tool in this course links out to a focused reference page at SixSigmaStudyGuide.com for anyone who wants to go deeper on the math.
Finding and Validating the Vital Few X's
Every tool in this course fits into one repeatable seven-step flow. This is the backbone of the whole Analyze phase — everything below is one of these steps in more depth.
Develop a detailed business process map
Go beyond Measure's high-level SIPOC to a step-by-step map of exactly how work actually flows today.
Analyze the process map for variation sources
Tag each step as value-added or non-value-added, and flag hand-offs, delays, and rework loops.
Determine the X's
Brainstorm and organize every plausible cause using fishbone, 5 Whys, FMEA, and related tools.
Prioritize and collect data on the X's
Rank candidate X's by likely impact and feasibility, then gather data on the ones worth testing.
Quantify the relationship, Y = f(X)
Use graphs, correlation, and regression to see how much each X actually moves the Y.
Identify the vital X's
Narrow from many potential X's to the few with real, demonstrable impact on the CTQ.
Validate the vital X's
Confirm each vital X with a formal statistical test — hypothesis testing, ANOVA, or DOE.
1. What comes right after "determine the X's" in the seven-step Analyze flow?
2. What does "Y = f(X)" mean in this context?
Process Map Analysis: Value and Non-Value Activities
A Detailed Process Map breaks the process into every actual step, not the five-to-ten box version from Measure's SIPOC. A Value Stream Map goes further, layering on time at each step so the team can see where work — and waiting — really happens.
| Step | Activity | Type | Time |
|---|---|---|---|
| 1 | Employee submits ticket | Value-added | 2 min |
| 2 | Ticket sits in unassigned queue | Non-value-added | 4.1 hrs (avg) |
| 3 | Agent triages and categorizes ticket | Value-added | 6 min |
| 4 | Ticket reassigned to correct tier (40% of tickets) | Non-value-added | 2.3 hrs (avg) |
| 5 | Agent diagnoses and resolves issue | Value-added | 22 min |
| 6 | Ticket waits for user confirmation | Necessary non-value-added | 3.8 hrs (avg) |
| 7 | Ticket closed and CSAT survey sent | Value-added | 1 min |
What the map reveals
Only about 31 minutes of the 3.6-day average is actual value-added work. Nearly all the elapsed time sits in queues and hand-offs — step 2 (unassigned queue) and step 4 (reassignment) alone account for over 6 hours of pure waiting, with no work happening at all. That's exactly the kind of signal Analyze is built to catch.
Waste Analysis: The Classic Wastes
The Classic Wastes give the team a checklist for spotting non-value-added activity hiding in the process map.
| Waste | What it looks like | IT example |
|---|---|---|
| Overproduction | Doing or producing more than the next step needs | Auto-generating duplicate diagnostic reports nobody reviews |
| Inventory | Work sitting, piled up, not being actively worked | A backlog of unassigned tickets sitting in the general queue |
| Waiting | Idle time between steps | Tickets waiting 4+ hours for an available agent |
| Motion | Unnecessary movement of people | An agent switching between three different tools to see one ticket's full history |
| Defects | Errors requiring rework | A ticket mis-categorized, requiring reassignment and restarting triage |
| Over-processing | Doing more work than the customer actually needs | Requiring manager approval for a routine password reset |
| Transport & handling | Unnecessary movement of work between people or systems | A ticket bouncing between Tier 1 and Tier 2 twice before resolution |
1. A ticket that gets reassigned twice between support tiers is an example of which classic waste?
2. In the IT process map above, which step contributed the most non-value-added time?
Organizing Potential Causes to Show Relationships
Once the process map exposes where time and waste hide, the team needs structured ways to generate and organize every plausible cause — before testing which ones actually matter.
Brainstorming
A structured group session for generating every plausible cause without judging them yet — quantity first, evaluation later. Read more →
IT example: the service desk team brainstorms every reason a ticket might sit unresolved — understaffing, unclear triage rules, missing asset data, VPN slowness, and a dozen more — with no idea yet ranked or judged.
5 Whys — try it live
Ask "why" repeatedly until the answer stops being a symptom and starts being a fixable root cause. Read more →
Click through the chain below, built from the IT case study:
Fishbone (Ishikawa) diagram
Sorts every brainstormed cause into People, Process, Equipment, Materials, Measurement, and Environment. Read more →
IT example: Measure's fishbone already surfaced candidates like staffing turnover, unclear triage rules, and inconsistent timestamp capture. Analyze picks up exactly there — each fishbone branch becomes a candidate X to prioritize and test below.
Fault Tree Analysis
Works top-down from the failure, breaking it into the combinations of conditions (AND/OR logic) that could cause it. Read more →
| Top event | SLA breach (resolution > 1 day) | |
|---|---|---|
| OR | Queue delay | Wrong initial assignment |
| Queue delay requires (AND) | Low agent availability | High ticket volume |
Reading it: the SLA breaches when either branch occurs, and the queue-delay branch itself only fires when both low availability and high volume happen together.
Affinity diagram
Groups a large, messy set of brainstormed ideas into natural themes — useful right after a big brainstorming session. Read more →
IT example: the team's 30+ brainstormed causes cluster into four themes: Staffing (turnover, scheduling), Tooling (slow VPN, manual routing), Process (no triage rules, unclear escalation), and Data quality (incomplete ticket descriptions).
Tree diagram
Breaks a broad goal down into increasingly specific means of achieving it — a "how" ladder. Read more →
IT example: Goal: Reduce resolution time → Means: Reduce queue time → Sub-means: Auto-assign by category, Align staffing to volume curve.
Interrelationship digraph
Maps how the causes influence each other, so the team can see which ones are root "drivers" versus downstream "outcomes." Read more →
IT example: staffing turnover → fewer available agents → longer queue time → longer total resolution time. Staffing turnover sits furthest upstream, making it a stronger candidate root cause than "long queue time" itself, which is really just a symptom passed downstream.
FMEA (Failure Mode & Effects Analysis)
Scores each potential failure mode on Severity, Occurrence, and Detection (1–10 each) and multiplies them into a Risk Priority Number (RPN) to rank what to fix first. Read more →
| Failure mode | Severity | Occurrence | Detection | RPN |
|---|---|---|---|---|
| Ticket sits unassigned too long | 7 | 8 | 6 | 336 |
| Ticket mis-categorized, needs reassignment | 6 | 6 | 5 | 180 |
| Missing asset info delays diagnosis | 5 | 5 | 4 | 100 |
| CSAT survey fails to send | 3 | 2 | 3 | 18 |
The unassigned-ticket failure mode's RPN of 336 towers over the rest — a strong signal about where to focus data collection next.
1. In FMEA, what does RPN stand for and how is it calculated?
2. Which tool works top-down using AND/OR logic to trace the combinations of conditions that cause a failure?
Mathematical Tools
Before running any statistical test, it helps to know what shape the data naturally takes — and why sample averages behave more predictably than individual data points.
Central Limit Theorem
The Central Limit Theorem (CLT) says that no matter how skewed the underlying data is, the distribution of sample means approaches a normal distribution as sample size grows. This is why the team can still use normal-based tests (like the t-test) on average daily resolution times, even though individual ticket times are right-skewed.
Distribution Types
See the full overview at Distribution Types. Below are the specific distributions called out for the Analyze phase.
| Continuous distribution | Models | IT example |
|---|---|---|
| Normal (Gaussian) | Symmetric, bell-shaped data | Average daily resolution time across many days (via CLT) |
| Lognormal | Right-skewed data with a hard floor at zero | Individual ticket resolution times |
| F-distribution | Ratio of two variances | Comparing variance between two agents' resolution times (used inside ANOVA) |
| Chi-square | Sums of squared deviations; category-count comparisons | Whether SLA breach rate differs by ticket category |
| Exponential | Time between independent events | Time between successive high-priority ticket arrivals |
| Student's t | Small-sample mean comparisons | Comparing this month's average resolution time to the 1-day target |
| Paired t | Before/after on the same subject | Same agents' resolution times before and after a new tool rollout |
| Two-sample t | Comparing means of two independent groups | Agent Team A vs. Agent Team B average resolution time |
| Discrete distribution | Models | IT example |
|---|---|---|
| Binomial | Number of successes in a fixed number of pass/fail trials | Number of tickets breaching SLA out of the next 50 tickets |
| Poisson | Count of rare events in a fixed time or space | Number of critical outages in a given week |
| Hypergeometric | Sampling without replacement from a finite population | Auditing 20 tickets pulled from a finite batch of 200 for the week |
Try it: shape explorer
Hypothesis Testing Fundamentals
Every statistical test in Analyze follows the same logic: assume nothing changed (the null hypothesis, H₀), then check whether the data gives strong enough evidence to reject that assumption in favor of the alternative (H₁). See Hypothesis Testing Terminology for the full glossary.
| H₀ is actually true | H₀ is actually false | |
|---|---|---|
| We reject H₀ | Type I error (α) | Correct decision |
| We fail to reject H₀ | Correct decision | Type II error (β) |
Type I error (α)
Concluding a change made a difference when it actually didn't — a false alarm. IT example: declaring the new triage rule worked when the improvement was really just random variation.
Type II error (β)
Concluding there's no difference when one really exists — a missed signal. IT example: concluding the new tool didn't help when it actually cut resolution time, but the sample was too small to detect it.
1. Concluding a process change helped, when in reality it made no real difference, is:
2. What is the null hypothesis (H₀) generally assumed to state?
Five Statistical Tests, Worked in Full
Each test below follows the same structure: Definition, Situation, Null Hypothesis, Alternative Hypothesis, and Result — using real numbers from the Service Desk Project.
1-Sample t-Test
Definition: Tests whether a sample mean is significantly different from a known or target value.
Situation: After early process tweaks, the team samples 30 days of resolution times (mean = 3.35 days, s = 0.85) and wants to know if this is significantly better than the 3.6-day Measure-phase baseline.
H₀: μ = 3.6 days H₁: μ < 3.6 days
| n | Sample mean | Std. dev. | t-statistic | p-value |
|---|---|---|---|---|
| 30 | 3.35 days | 0.85 | −1.61 | ≈0.059 |
Result: At α = 0.05, p ≈ 0.059 is just above the threshold — the team fails to reject H₀. The average has moved in the right direction, but not by enough (yet) to call it statistically significant. This is a useful, honest result: it argues for more data or a stronger fix, not premature celebration.
2-Sample t-Test
Definition: Tests whether the means of two independent groups differ significantly.
Situation: Comparing average resolution time between Team A (n=20, mean=3.1 days, s=0.7) and Team B (n=20, mean=3.9 days, s=0.8).
H₀: μA = μB H₁: μA ≠ μB
| Group | n | Mean | Std. dev. |
|---|---|---|---|
| Team A | 20 | 3.1 days | 0.7 |
| Team B | 20 | 3.9 days | 0.8 |
Result: t ≈ 3.37, p < 0.01 — reject H₀. Team B is statistically significantly slower than Team A, which turns "the teams feel different" into a confirmed X worth investigating (staffing mix, training, ticket assignment rules).
One-Way ANOVA
Definition: Compares the means of three or more groups at once. Read more →
Situation: Comparing average resolution time across three ticket categories: Password/Access, Software, and Hardware.
H₀: μpassword = μsoftware = μhardware H₁: at least one mean differs
| Category | n | Mean resolution time |
|---|---|---|
| Password / Access | 15 | 1.8 days |
| Software | 15 | 3.9 days |
| Hardware | 15 | 5.1 days |
Result: F ≈ 18.4, p < 0.001 — reject H₀. Category clearly matters; hardware tickets take dramatically longer, likely because they depend on parts or vendor availability outside the service desk's control.
Mood's Median Test
Definition: A non-parametric test that compares medians across groups without assuming a normal distribution — a good fit when raw data is skewed, like individual ticket times.
Situation: Since raw ticket times are right-skewed (not normal), the team re-checks the category effect using medians on the raw, ticket-level data instead of category averages.
H₀: all category medians are equal H₁: at least one median differs
| Category | Median resolution time |
|---|---|
| Password / Access | 1.1 days |
| Software | 3.2 days |
| Hardware | 4.6 days |
Result: χ² ≈ 14.2, df = 2, p ≈ 0.0008 — reject H₀. Medians differ significantly, confirming the category effect holds even without assuming a normal distribution — good corroboration of the ANOVA finding above.
Chi-Square Test
Definition: Tests whether two categorical variables are independent of each other, by comparing observed counts to what would be expected if there were no relationship.
Situation: Is SLA-breach status independent of ticket category?
H₀: SLA-breach status is independent of ticket category H₁: SLA-breach status depends on ticket category
| Category | Breached | Not breached |
|---|---|---|
| Password / Access | 12 | 88 |
| Software | 45 | 55 |
| Hardware | 60 | 40 |
Result: χ² ≈ 41.3, df = 2, p < 0.001 — reject H₀. Breach rate clearly depends on category, with hardware tickets breaching far more often — consistent with everything the ANOVA and median test already pointed to.
1. Why did the team use Mood's Median Test in addition to ANOVA?
2. In the chi-square example, what were the two categorical variables being tested for independence?
ANOVA and Regression Analysis
One-way ANOVA (above) compares groups defined by a single factor. Two-way ANOVA extends this to two factors at once — for example, testing whether both ticket category and agent experience level affect resolution time, including whether they interact. Read more on ANOVA →
Regression Analysis and Linear Regression go a step further than a group comparison — they quantify exactly how much a continuous X moves a continuous Y, which is exactly what "Y = f(X)" means in practice.
Design of Experiments (DOE)
When more than one X might matter at once, DOE tests them together deliberately, so the team can see individual effects and interactions in one pass, instead of guessing one variable at a time.
| Design | What it does | When it's used |
|---|---|---|
| Full Factorial Design | Tests every combination of every factor and level | A small number of factors/levels, and interactions matter |
| Fractional Factorial Design | Tests a carefully chosen subset of combinations | Full factorial would need too many runs to be practical |
| Taguchi Loss Function | Quantifies quality loss as any deviation from target, not just out-of-spec | Being "within spec" isn't good enough — minimizing variation from target matters |
| Evolutionary Operations (EVOP) | Makes small, deliberate process changes during normal production | The process can't be paused to run a formal experiment |
| Latin Square | Controls for two nuisance factors while isolating one main factor | Two extra sources of variation need to be balanced out |
| Graeco-Latin Square | Extends the Latin Square to control a third nuisance factor | A third nuisance variable also needs balancing |
| Hyper-Graeco-Latin Square | Extends further to control a fourth nuisance factor | Even more nuisance variables must be balanced simultaneously |
Worked example: a small full factorial design
The team tests two candidate fixes at once — auto-routing rules and extra triage training — across all four combinations.
| Auto-routing | Extra training | Avg. resolution time |
|---|---|---|
| Off | Off | 86 hrs |
| On | Off | 71 hrs |
| Off | On | 68 hrs |
| On | On | 42 hrs |
Why this matters
Auto-routing alone saves about 15 hours; training alone saves about 18 hours. If the effects were purely additive, combining both would save roughly 33 hours (down to ~53). Instead, the combination reaches 42 hours — a bigger gain than the two effects added together, a classic interaction effect that testing one factor at a time would have completely missed.
1. What does it mean when a full factorial design reveals an "interaction effect"?
2. Which DOE approach is chosen specifically when the process cannot be paused for a formal experiment?
Analyze Phase Deliverables
Checks are saved in your browser as you go.
Root Cause Survival Challenge
Three hearts. Answer wrong three times and it's game over — survive all the questions to earn the badge.
Final score:
20-Question Final Quiz
Everything above builds toward this. 70% (14 of 20) or better is a pass.
Quiz complete
Score: / 20
Sources & further reading
- Detailed Process Map
- Value Stream Mapping
- Classic Wastes
- Brainstorming
- 5 Whys
- Fishbone Diagram
- Fault Tree Analysis
- Affinity Diagram
- Tree Diagram
- Interrelationship Digraph
- FMEA
- Central Limit Theorem
- Distribution Types
- Normal Distribution
- F Distribution
- Chi-Square Distribution
- Exponential Distribution
- Student's t Distribution
- Paired & Two-Sample t-Test
- Binomial Distribution
- Poisson Distribution
- Hypergeometric Distribution
- Hypothesis Testing Terminology
- ANOVA
- Regression Analysis
- Linear Regression
- Full Factorial Design
- Fractional Factorial Design
- Taguchi Loss Function
- Evolutionary Operations (EVOP)
- Latin / Graeco-Latin Square Designs