Analyse Phase (DMAIC): Where the Data Stops Whispering and Starts Testifying

A Lean Six Sigma project becomes genuinely valuable when it stops describing a problem and starts explaining it.

That is the purpose of the Analyse Phase in DMAIC. After Define establishes the business problem and Measure quantifies current performance, Analyse examines the evidence to determine which inputs are influencing the output, how strongly they influence it, and whether the suspected relationship is statistically credible.

The fundamental purpose is not to produce more charts. It is to prevent teams from investing time and money in solutions that address symptoms rather than causes.

In the realm of process improvement, the Analyse Phase is where raw data becomes a defensible improvement strategy.

What Is the Analyse Phase of DMAIC?

DMAIC stands for Define, Measure, Analyse, Improve and Control. Analyse is the third phase, positioned between baseline measurement and solution development.

During this phase, the project team:

• Reviews patterns in the measured data
• Separates common-cause from special-cause variation
• Identifies potential relationships between inputs and outputs
• Prioritises likely causes
• Tests hypotheses using statistical evidence
• Validates the critical root causes before entering Improve

A useful way to frame the analysis is:

Y = f(X)

Here, Y represents the process output or customer-critical result, while X represents the inputs that influence it.

For example:

• Y: Customer onboarding cycle time
• X₁: Number of manual handoffs
• X₂: Intake channel
• X₃: Verification method
• X₄: Staff availability
• X₅: Information completeness

The Analyse Phase asks a precise question: Which Xs materially affect Y?

Teams can use visual tools such as Pareto Analysis and fishbone diagrams to structure their thinking, then use statistical methods to validate or reject the resulting hypotheses.

Start with Visual Analysis Before Statistical Testing

Statistical analysis is most effective when it is preceded by disciplined visual investigation. Visual tools reveal patterns, clusters and unusual observations that help the team select appropriate tests.

Pareto Analysis: Identify the Vital Few

A Pareto chart ranks categories from largest to smallest and displays their cumulative contribution. It helps answer:

• Which defect types occur most frequently?
• Which delay categories create the greatest cost?
• Which failure modes account for most customer impact?
• Where should the team focus its analytical effort?

Suppose a service process records 1,000 delays:

The first three categories account for 78% of all delays. This does not prove that manual verification is the root cause, but it establishes where deeper analysis should begin.

Fishbone Diagram: Organise Potential Causes

A fishbone, or Ishikawa, diagram organises possible causes under categories such as:

• People
• Methods
• Machines or systems
• Materials or information
• Measurement
• Environment

The fishbone is a structured way to convert team knowledge into testable potential Xs. It is not, by itself, proof of causation. A well-constructed fishbone produces hypotheses; data validates them.

Teams may also use the 5 Whys, process stratification, affinity diagrams and FMEA to narrow the list. The goal is to move from a broad collection of possible causes to a short list of measurable candidates.

Variation Analysis: Find the Signal in the Noise

Every process contains variation. The key analytical distinction is whether that variation is:

• Common cause variation: Natural fluctuation built into the current process
• Special cause variation: An identifiable influence producing an unusual shift or pattern

This distinction matters because the response must match the type of variation. Common-cause variation generally requires process redesign or systemic improvement. Special-cause variation may require a targeted correction, such as resolving a software issue, supplier event or training gap.

Useful visual tools include:

• Histograms to show distribution shape
• Box plots to compare groups and identify outliers
• Run charts and control charts to reveal time-based patterns
• Scatter plots to examine relationships between continuous variables

Averages alone are insufficient. Two groups may have the same mean but dramatically different spreads, which could create different levels of customer risk.

Hypothesis Testing: Convert Suspicion into Evidence

Once potential causes are identified, the team expresses them as formal hypotheses.

For example:

• Null hypothesis (H₀): Cases with and without manual verification have the same average cycle time.
• Alternative hypothesis (H₁): Cases requiring manual verification have a different average cycle time.

A significance level, commonly α = 0.05, is selected before testing. If the resulting p-value is below 0.05, the team has evidence to reject the null hypothesis. However, statistical significance should always be considered alongside practical significance.

A difference of 0.2 minutes may be statistically significant in a very large dataset but irrelevant to the business. Conversely, a meaningful operational difference may require additional data to confirm confidently.

ANOVA: Compare Three or More Groups

ANOVA, or Analysis of Variance, compares the means of three or more groups.

It is useful when a team wants to compare:

• Three or more shifts
• Multiple suppliers
• Several production machines
• Different regions or intake channels
• Distinct process conditions

ANOVA tests whether the observed variation between group means is greater than would reasonably be expected from variation within the groups.

Bartlett’s Test: Check Variance Equality

Before relying on a standard one-way ANOVA, the team should consider whether group variances are reasonably equal. Bartlett’s Test assesses whether the variances of several groups differ significantly.

For example:

• H₀: All group variances are equal.
• H₁: At least one group variance is different.

If the p-value is greater than 0.05, there is insufficient evidence that the variances differ. If the result is significant, the team may need to investigate the variation further or use a more robust alternative, such as Welch’s ANOVA.

Bartlett’s Test is particularly sensitive to non-normal data, so analysts should review distributions and residuals rather than treating the test as an automatic approval gate.

Worked Example: Turning Raw Data into a Validated Root Cause

Consider a hypothetical customer onboarding process. The customer requirement is that applications should be completed within 48 hours.

During Measure, the team reviews 120 applications:

• Average cycle time: 63.4 hours
• Standard deviation: 21.7 hours
• Applications exceeding 48 hours: 46
• Initial over-target rate: 38.3%

The process owner estimates that every expedited or escalated application costs approximately $18 in additional labour and coordination.

At 3,000 applications per month, the current opportunity is:

• 3,000 × 38.3% = 1,149 over-target applications
• 1,149 × $18 = $20,682 estimated monthly cost

The team begins with Pareto analysis and finds that manual verification, missing information and approval queues represent most of the delays. A fishbone diagram identifies several potential Xs, including staff experience, intake channel, verification method and number of handoffs.

Step 1: Compare Intake Channels

The team separates the 120 applications into three intake channels:

A one-way ANOVA produces:

• F-statistic: 24.6
• p-value: < 0.001

The group means are not all equal. Bartlett’s Test produces a p-value of 0.31, indicating no statistically significant evidence that the group variances are different. The ANOVA assumptions are therefore reasonable for this comparison.

The intake channel is associated with cycle time, but it may not be the true controllable cause. The team investigates further.

Step 2: Test the Number of Manual Handoffs

The same applications are grouped by handoffs:

Regression analysis models cycle time as a function of handoffs:

Cycle time = 42.1 + 11.6 × number of handoffs

The model produces:

• R²: 0.64
• Regression p-value: < 0.001
• Estimated increase per additional handoff: 11.6 hours

The team then stratifies the results by intake channel. The relationship remains present within each channel, reducing the likelihood that intake channel alone explains the result.

Step 3: Validate the Root Cause

The evidence now forms a coherent cause-and-effect story:

1. Manual handoffs are concentrated in the delay Pareto.
2. Applications with more handoffs have higher average cycle times.
3. The difference is statistically significant.
4. Regression shows a substantial practical effect.
5. The relationship remains after considering intake channel.
6. The process map confirms that each handoff introduces queue time and repeated verification.

The validated root cause is therefore not simply “email requests take longer.” The stronger conclusion is:

Additional manual handoffs create queue time and repeated verification, increasing onboarding cycle time by approximately 11.6 hours per handoff.

That is a root cause the Improve Phase can act on. The team can now evaluate a standardised digital intake form, automated information checks, clearer decision rules and a reduced approval path.

If the improvements reduce the over-target rate from 38.3% to 17%, the estimated opportunity is:

• 3,000 × (38.3% − 17%) = 639 fewer over-target applications per month
• 639 × $18 = $11,502 potential monthly benefit
• Annualised opportunity: $138,024

These are projected benefits, not yet confirmed savings. The Improve and Control phases must validate the result through piloting, implementation and sustained performance monitoring.

A Practical Analyse Phase Protocol

A disciplined team can use the following sequence:

1. Confirm the Measure Phase data is accurate, complete and operationally defined.
2. Stratify the data by relevant factors such as shift, supplier, channel, machine or product.
3. Use Pareto analysis to identify the largest contributors.
4. Build a fishbone diagram to organise potential causes.
5. Express each suspected cause as Y = f(X).
6. Select the correct statistical test for the data type and number of groups.
7. Review variation, distribution shape and outliers.
8. Check assumptions, including variance equality where appropriate.
9. Distinguish statistical significance from practical significance.
10. Document validated root causes before proposing solutions.

A well-managed Analyse Phase also records rejected hypotheses. Demonstrating that a suspected cause was tested and ruled out strengthens the project’s credibility and prevents the team from revisiting unsupported assumptions.

Build the Capability to Analyse with Confidence

To fully appreciate the power of DMAIC, professionals need more than definitions. They need repeated practice selecting tools, interpreting outputs and connecting statistical evidence to operational decisions.

Lean 6 Sigma Hub’s online Lean Six Sigma training is designed around practical application, with self-paced learning, real-world simulations, dummy data, charts, worked examples and end-to-end DMAIC case studies. The Green Belt course is especially relevant for professionals who need to apply hypothesis testing, regression and project management in the workplace.

You can also explore the Lean Six Sigma project storyboard toolkit to see how Analyse deliverables fit into a structured project record and tollgate review.

Build your Lean Six Sigma capability, complete accredited training and learn to validate root causes before investing in improvement solutions.

Kaizen. Kai-Care. Kai-Done. ( Lean Six Sigma)