DMAIC Toolbox

What the Define Phase Is For

Most improvement projects that fail were not defeated by difficult statistics. They were defeated at the start: the problem was vague, the scope kept growing, the sponsor was not committed, or nobody agreed what success meant. Define exists to prevent that. It is the phase in which the project earns the right to consume time and money.

Define is also where the improvement method is chosen. Not every problem needs DMAIC. The next sections cover that decision, and each of the steps in order.

The Define Process, Step by Step

1. 1

   Identify the problem or opportunity

   Start from evidence: customer complaints, scrap and rework reports, missed deliveries, audit findings, safety events, cost trends, or a strategic gap. Write down who raised it, what they observed, and what data they used.

   • Collect the raw signals: complaints, defect and downtime data, cost reports, customer scorecards
   • Ask the people who raised the concern for examples and dates
   • Check whether the problem is chronic and recurring or a one-time event

   Output: A short list of candidate problems with the evidence behind each

   Watch for: Problems described only as opinions (“quality is bad”) and problems already caused by a known, fixable event

2. 2

   Select and prioritize the project

   Compare candidates against agreed criteria: strategic fit, customer impact, financial impact, feasibility, and sponsor support. Decide whether DMAIC is the right method (see the next section).

   • Score candidates with a prioritization matrix
   • Check that the root cause is not already known
   • Confirm that the project can be completed in roughly three to six months

   Output: One selected project, a recorded reason for choosing it, and the method chosen

   Watch for: Choosing the project that is easiest to explain, not the one with the best evidence and value

3. 3

   Understand the customer and the process at a high level

   Identify the customers of the process output, listen to them, and translate what they say into measurable requirements. Draw a SIPOC to agree the boundary and flow.

   • Gather the voice of the customer from interviews, complaints, surveys, and data
   • Classify needs with the Kano model
   • Build a CTQ tree
   • Draw the SIPOC with the team and the process owner

   Output: CTQs with measurable definitions, and a SIPOC

   Watch for: Assuming you know what the customer wants without asking, and drawing the process as it should be rather than as it is

4. 4

   Quantify the impact and the baseline

   Put numbers on the problem: how often, how large, since when, and what it costs. Use the data that already exists. A preliminary baseline is enough; detailed measurement belongs in the next phase.

   • Pull existing data on the primary metric for a representative period
   • Estimate the cost of poor quality and the benefit if the goal is met
   • Ask finance to review the benefit method

   Output: A preliminary baseline, a benefit estimate, and agreement on how the benefit will be validated

   Watch for: Benefit estimates that count every cost as savings, or that finance has never seen

5. 5

   Draft the charter and form the team

   Write the charter: problem statement, goal, scope, business case, constraints, risks, timeline, and roles. Name the sponsor, process owner, project leader, and team members, and confirm their time with their managers.

   • Draft the problem and goal statements and test them with the sponsor
   • Choose team members who know the process and can act on findings
   • Analyze stakeholders and plan communication

   Output: A draft charter, a named team, a stakeholder analysis, and a communication plan

   Watch for: A team assembled by availability rather than knowledge, and a charter written alone by the project leader

6. 6

   Hold the tollgate review

   Present the charter, SIPOC, customer requirements, baseline, benefit case, and plan to the sponsor and process owner. The aim is a decision: proceed, proceed with conditions, re-scope, or stop.

   • Use the tollgate checklist in this tab
   • Record decisions and actions
   • Obtain signatures

   Output: A signed charter and a recorded go, conditional go, re-scope, or stop decision

   Watch for: A review that is a formality. A project stopped at this point is a good outcome, because it frees resources for work that is worth doing

Choosing the Right Project and the Right Method

A well-defined project that is the wrong project still wastes months. Selection is therefore part of Define. Use criteria that the sponsor has agreed, score candidate projects against them, and keep a record of why the winner was chosen.

Is DMAIC the right method? Match the method to the problem:

Writing the Problem Statement and the Goal Statement

The problem statement describes the gap between what is happening and what should be happening, in measurable terms. The goal statement describes the improvement the project will deliver. Both should be clear enough that two people would measure them the same way.

The examples above are illustrative.

The goal statement follows the SMART pattern: Specific, Measurable, Achievable, Relevant, and Time-bound. It should use the same metric as the problem statement, state the baseline and target, and give a date.

Set the target with evidence. A goal taken from a best-case month or a competitor's claim may not be achievable. Use demonstrated past performance, customer requirements, or technical limits, and agree that the target may be revisited at the end of Measure when the baseline is firm. For a tool to test wording, see the Project Charter guide.

Scope: Drawing the Boundary, and the SIPOC

Scope says what the project will and will not address. Most projects that stall are too broad, so draw the boundary deliberately and write it down. A boundary has four parts: where the process starts and stops, which products, sites, or customers are included, which causes or solution areas are in bounds, and what is explicitly out.

SIPOC stands for Suppliers, Inputs, Process, Outputs, Customers. It is a one-page, high-level picture that shows the boundary and who is connected to it. Keep the process to four to seven steps. Build it with the team and the process owner, and start in the middle: map the process steps first, then outputs, then customers, then inputs and suppliers.

Keep an is / is-not list alongside the scope: what the problem is and is not, where and when it occurs and does not occur. See Is / Is-Not Analysis.

From the Voice of the Customer to Critical-to-Quality Requirements

The customer decides whether the output is good enough, so a project that ignores the customer will optimize the wrong thing. Define converts what customers say, in their words, into specific, measurable characteristics the team can control. The customer may be external, or it may be the next department or process step.

Organize what you hear. Group comments with an affinity diagram, then rank importance. The Kano model adds a second dimension: which needs are basic expectations (dissatisfy when absent), which are performance needs (more is better), and which are delighters. See the Voice of the Customer and Kano guide and the Kano Model Analyzer.

Translate needs into CTQs. A critical-to-quality characteristic is a measurable requirement that is closely tied to what the customer values. A CTQ tree moves from the broad need, to a driver, to a specific measure with a target.

Define the primary metric (Y) operationally. Write exactly how it will be counted: what is a unit, what counts as a pass, what is included and excluded, where and when it is measured, and by whom. Ambiguity here will produce different numbers from different people, which becomes an expensive problem in Measure.

The Business Case: Cost of Poor Quality and Expected Benefits

A project competes for time and attention with other work, so the sponsor needs to know what it is worth. The business case estimates the cost of the problem and the benefit of solving it, in terms finance recognizes.

Use the COPQ Estimator and the COPQ overview to structure the estimate. Prevention and appraisal costs are not waste in themselves; the aim is to reduce failures, then reduce the appraisal needed to catch them.

Worked benefit estimate, Line 3 final test. The figures below are illustrative.

For an investment view, use the Project ROI Calculator and the Kaizen Savings ROI Calculator.

Team, Roles, and Stakeholders

Improvement is done by people, and projects fail from lack of access, authority, and support more often than from lack of technique. Define names the people and confirms what each is committing.

Pick team members for knowledge. Include people who do the work, people who feed it, people who receive its output, and someone who can analyze data. Teams of four to eight work well. Confirm the time with each member's manager, not just the member.

Analyze stakeholders. List the people and groups affected, estimate their influence and their current support, and plan how to engage each. Those with high influence and low support need conversations early. See the Stakeholder Analysis Builder and Stakeholder Analysis.

Clarify who decides what. A RACI matrix shows who is Responsible, Accountable, Consulted, and Informed for key activities.

Build one with the RACI Matrix Builder. Finally, agree a communication plan:

Just Enough Data in Define

Define needs enough data to size the problem and justify the project, and no more. Careful measurement, including checking that the measurement system is reliable, belongs in Measure. If you wait for perfect data before chartering, the project will never start.

A preliminary look at the baseline. A yield of 91.2% corresponds to a sigma level of about 2.85, and a yield of 96.0% to about 3.25, using the conventional 1.5-sigma shift. The sigma level is a convenient way to compare processes. It is not a goal in itself. Use the Sigma Level and DPMO Suite to convert between yield, defect rates, and sigma level.

Look for the shape of the problem. A quick Pareto chart of defect types, or a run chart of the metric over time, often shows whether the issue is sudden (a recent change) or long-standing (a chronic cause). That affects scope and the approach in later phases.

Putting It Together: The Project Charter

The charter is the one-page agreement that records everything above. It is signed by the sponsor and referred to throughout the project. The table shows its elements, with the Line 3 example completed.

See the Project Charter guide for how to draft, review, and keep a charter alive. The DMAIC project files and the Kaizen Event Charter Template provide formats to start from.

Tollgate Review: Are We Ready for Measure?

A tollgate is a decision point. The sponsor reviews the work and decides whether the project should proceed. Use the checklist below before the review. Your progress is saved in this browser only, and nothing is sent anywhere.

Questions a sponsor should ask:

• If this project succeeds, what will be different for customers and for the business, and how will we know?
• Is this the right size? Could it be finished in about five or six months?
• How was the benefit estimated, and who will validate it?
• Who owns the process, and are they committed to sustaining the result?
• What are the biggest risks to this project, and what is the plan for each?
• Is there anything in the charter that assumes a cause or a solution?

Adapting Define to the Situation

Lean and Six Sigma together. Lean projects often start from a value stream map that points to waiting and flow problems; Six Sigma projects start from variation and defects. In Define, the same questions apply: what is the problem, who is the customer, and what is the boundary? See Lean Six Sigma Integration.

Common Mistakes and Red Flags

Define Resources on This Site

Define Phase Frequently Asked Questions

Sources and Further Reading

What the Measure Phase Is For

Define says what the problem is. Measure says how big it really is, where and when it occurs, and whether the numbers can be believed. Teams that skip this phase tend to analyze guesses; teams that rush it often discover later that their data cannot support a conclusion.

The Measure Process, Step by Step

1. 1

   Select and define the measures

   Translate the CTQ from Define into the primary measure (Y). Add process measures and key input measures (Xs) that may influence it. Write an operational definition for each.

   • Confirm the primary metric from the charter
   • List candidate process and input measures
   • Write definitions: what is counted, how, where, by whom, and when
   • Decide whether each is continuous or discrete data

   Output: Operational definitions for every measure

   Watch for: Definitions that differ between shifts or departments, and measures chosen only because the data is easy to get

2. 2

   Map the process as it actually runs

   Go to the place where the work is done and trace the real flow, including rework loops, waiting, and workarounds. Mark where measurements are or could be taken, and list candidate inputs.

   • Walk the process from start to end with the people who do it
   • Record steps, times, handoffs, and decision points
   • Identify value-adding and non-value-adding steps
   • List potential Xs with a cause-and-effect matrix or diagram

   Output: A detailed process map and a list of candidate Xs

   Watch for: A map of the procedure as written instead of the process as performed

3. 3

   Build the data collection plan

   Decide exactly what data to collect, from where, how, how much, by whom, and over what period, including the factors needed to stratify the data later.

   • Define the sample size and sampling method
   • Choose stratification factors up front
   • Design forms or extracts, and train data collectors
   • Agree the time period and how special events will be recorded

   Output: A written data collection plan and test of the forms

   Watch for: Collecting data first and thinking about the questions later

4. 4

   Validate the measurement system

   Before relying on the data, test whether the measurement process is accurate and precise enough. Use gage R&R for continuous data and attribute agreement analysis for pass/fail or category data.

   • Choose parts or samples that span the real range
   • Include the operators who normally measure
   • Randomize order and blind the samples
   • Analyze, and improve the system if it is not acceptable

   Output: Documented measurement system results and any fixes

   Watch for: Skipping the study because “the gauge is calibrated”. Calibration is not the same as capability

5. 5

   Collect the data

   Follow the plan, record time and context for each data point, and check the data as it arrives so that problems are caught early.

   • Run a short pilot of the collection
   • Monitor completeness and plausibility daily or weekly
   • Record changes, breakdowns, and other events as notes

   Output: A clean, time-ordered, annotated data set

   Watch for: Changing the process while collecting, which changes the thing you are trying to measure

6. 6

   Baseline and stratify

   Plot the data in time order, check stability, describe the distribution, and calculate performance and capability. Then break the data down by the factors in the plan to find where the problem concentrates.

   • Run or control charts, histograms, and box plots
   • Capability or sigma level, with the method stated
   • Pareto charts and stratified comparisons

   Output: The baseline, with evidence of where and when the problem occurs

   Watch for: Calculating capability for a process that is not stable, and reporting only an average

7. 7

   Refine the charter and hold the tollgate

   Update the problem statement, goal, and scope in light of the data. Present the baseline and findings to the sponsor and process owner and agree the focus for Analyze.

   • Revise the charter where the data call for it
   • Use the tollgate checklist in this tab
   • Record decisions and signatures

   Output: An updated charter and a recorded tollgate decision

   Watch for: Holding on to the original problem statement after the data show something different

Choosing and Defining the Right Measures

A project needs a small, deliberate set of measures. The primary measure (Y) comes from the CTQ in the charter. Supporting measures describe the process and its inputs, and a balancing measure shows whether improving one thing worsens another.

Operational definitions. An operational definition says exactly how a measure is obtained, so that two people get the same number. It states what is counted, the unit, the rules for inclusion and exclusion, the method and instrument, the location and time, and who records it.

Continuous or discrete data? The data type decides the tools you can use, and continuous data usually carry more information per observation than counts.

Mapping the Process and Finding the Candidate Xs

The SIPOC from Define showed the boundary. Measure goes inside it. The aim is to understand how the work really happens, where time and defects arise, and which inputs might matter, without deciding yet which ones do.

• Walk it. Observe the process on every shift that matters. Differences between shifts are often findings.
• Map what happens, not what should happen. Include rework loops, workarounds, and waiting.
• Add data to the map: cycle times, queue sizes, yields, and defects at each step.
• Mark value. Classify each step as value-adding, necessary non-value-adding, or waste, from the customer's viewpoint.

From the map to candidate Xs. A cause-and-effect matrix rates each input against the customer requirements and ranks the inputs by their likely influence. A fishbone diagram collects possible causes by category. Both are hypotheses to test in Analyze, not conclusions. See the Cause-and-Effect Matrix and the Fishbone Builder.

The Data Collection Plan

The plan turns questions into data. It should be specific enough that someone else could collect the data and get the same results. Write it before collecting, review it with the process owner, and test the forms in a pilot.

Sampling. If you cannot measure everything, choose the sample deliberately. Random sampling gives each item an equal chance. Systematic sampling takes every kth item. Stratified sampling samples separately from groups, such as shifts or lots, so that each is represented. Rational subgrouping collects small groups of consecutive units so that variation within a group reflects short-term noise, and variation between groups reveals shifts. See Sampling Methods.

How much data? The answer depends on the question. Two common calculations:

These are planning aids that assume random samples. Use the Sample Size and Confidence Calculator and build the plan with the Data Collection Plan Builder. For a control chart baseline, a common guideline is 20 to 25 subgroups, and for a continuous-data capability study many practitioners look for at least 100 observations across normal operating variation.

Validating the Measurement System

Every observed value is the true value plus measurement error. If the measurement error is large compared with the process variation or the tolerance, the data cannot reveal real differences. A measurement system analysis (MSA) quantifies the error.

Gage R&R for continuous data. A typical crossed study uses about 10 parts that span the process range, 2 or 3 operators, and 2 or 3 trials each, measured in random order and blinded where possible. The analysis separates repeatability, reproducibility, and part-to-part variation.

These guidelines are from widely used automotive industry MSA practice; use the criteria your customers or standards require. Run a study with the Gauge R&R Calculator and record it in the Gage R&R Study Template. See the Measurement System Analysis guide.

Attribute data. For pass/fail or rating data, use an attribute agreement analysis. Several appraisers classify the same set of items, ideally including known reference answers, more than once. The analysis shows agreement within each appraiser, between appraisers, and with the standard, usually summarized with kappa statistics. A commonly used guideline treats kappa above 0.75 as good agreement and below 0.40 as poor. See Attribute Agreement Analysis.

Establishing the Baseline: Stability, Capability, and Sigma Level

The baseline describes how the process performs now. Always check stability before calculating capability, because capability indices assume a stable, predictable process.

1. Plot the data in time order on a run chart or control chart. Look for shifts, trends, cycles, and points outside the limits.
2. Investigate special causes. Note or correct them; do not blend them silently into the baseline.
3. Describe the distribution with a histogram and box plot, and check for outliers and multiple peaks.
4. Calculate performance with the appropriate measures for the data type.
5. State the method and period so that the baseline can be reproduced.

Choose the control chart by data type with the Control Chart Selector, and calculate limits with the Control Limits Generator. See the SPC Control Charts guide.

Continuous data: capability indices. They compare the spread of the process with the specification.

Check the assumptions. The simple indices assume a stable process and, for the percent-out-of-specification estimate, an approximately normal distribution. For non-normal data, use a transformation or a method designed for the distribution. See Process Capability, Non-Normal Capability, and the Process Capability Helper.

Discrete data: defect rates and sigma level.

Convert between yield, DPMO, and sigma level with the Sigma Level and DPMO Suite and the Rolled Throughput Yield Calculator. See the Sigma Level, DPMO, and RTY guide.

Stratification: Where Does the Problem Concentrate?

An average hides structure. Stratification splits the data by a factor that might matter, such as shift, machine, operator, product, supplier, lot, location, time of day, or failure type, and compares the groups. It is the main route from a broad baseline to a focused problem.

• Pareto analysis ranks categories and shows the vital few. See the Pareto Analysis guide.
• Run charts by group show whether a difference is persistent or a one-off.
• Multi-vari charts separate variation within a part, between parts, and over time, to show where the variation lives. See Multi-Vari Studies.
• Box plots and histograms by group compare center and spread for continuous data.

Refine the problem. The stratified view often narrows the project considerably: “first-pass yield at final test is 91.2%” becomes “connector seating and firmware load errors, concentrated on shift 3, account for two thirds of failures.”

Data Quality and Common Data Problems

Check the data early and often. Plot it as it arrives. Compare a sample of records with the physical items. Ask the people who collect it what is hard. Problems found in week one cost little; problems found in week eight can cost the schedule.

Revisiting the Charter at the End of Measure

The baseline is the first time the project meets real data. The charter may need to change, and changing it by agreement is a sign of a healthy project.

See the Project Charter guide on keeping a charter alive, and return to the Define tab for the original elements.

Tollgate Review: Are We Ready for Analyze?

The Measure tollgate confirms that the baseline can be trusted and that the problem is focused enough to analyze. Use the checklist before the review. Progress saves in this browser only, and nothing is sent anywhere.

Questions a sponsor should ask:

• How do we know the measurements are reliable?
• Is the process stable, and what does the baseline tell us about the size of the gap to the goal?
• Where does the problem concentrate, and what do we not yet know?
• Has anything in the data changed what we should be working on?
• What data limitations or risks should we keep in mind?
• Do the goal and the business case still hold?

Adapting Measure to the Situation

When data cannot be collected quickly. A short manual data collection with a well-designed form usually beats waiting for a system change. If a proxy measure must be used, state clearly how it relates to the true measure and its limits, and plan to check it later.

Common Mistakes and Red Flags

Measure Resources on This Site

Measure Phase Frequently Asked Questions

Sources and Further Reading

What the Analyze Phase Is For

Measure shows how large the problem is and where it concentrates. Analyze explains why. The risk in this phase is jumping to a favorite theory, or accepting a plausible story without evidence, and then spending Improve on the wrong fix. The discipline of Analyze is to require evidence for each cause before acting on it.

The Analyze Process, Step by Step

1. 1

   Review the baseline and the stratified findings

   Start from what Measure showed: where and when the problem concentrates, which categories dominate, and what the process map revealed. These are the clues the hypotheses should explain.

   • Re-read the Pareto charts, run charts, and stratified comparisons
   • List what is known, what is not, and what changed when the problem began
   • Check the time of first occurrence against known changes

   Output: A short summary of the clues that any explanation must fit

   Watch for: Ignoring evidence that does not fit a favored theory

2. 2

   Generate hypotheses broadly

   Use structured methods and the people who run the process to list every plausible cause, before narrowing. Separate hypotheses about the process (how work flows) from those about data (what the numbers show).

   • Run a cause-and-effect (fishbone) session
   • Drill into the top defect types with 5 Whys
   • Use the process map and FMEA to find where failures can arise
   • Compare good and bad cases with is / is-not analysis

   Output: A full list of hypotheses, grouped by category

   Watch for: Letting one voice dominate and recording only the first idea

3. 3

   Prioritize the hypotheses

   Rank by likelihood and by potential influence on the problem, using the data and process knowledge. Decide what to test first and how.

   • Use a cause-and-effect matrix or voting to rank
   • Link each hypothesis to a test or observation
   • Start with tests that are quick, cheap, and decisive

   Output: A ranked test plan

   Watch for: Testing only the hypotheses that are easy to test

4. 4

   Analyze the process

   Look for causes in how the work flows: waiting, rework loops, handoffs, bottlenecks, variation in method, and non-value-adding steps.

   • Value-added and non-value-added analysis
   • Cycle-time and queue analysis
   • Comparison of how different shifts or people do the task

   Output: Process-based findings, supported by observation and times

   Watch for: Relying on the documented procedure instead of what happens at the workstation

5. 5

   Analyze the data

   Use graphs first, then statistical tests where needed, to compare groups, show relationships, and separate real effects from random variation.

   • Choose the test by the data type of the Y and the X
   • Check assumptions and sample sizes
   • Report effect sizes and intervals, not only p-values

   Output: Evidence for or against each hypothesis

   Watch for: Running every possible test and picking the significant ones

6. 6

   Verify the causes

   Confirm that the apparent cause is real. Observe the mechanism, check that the timing fits, and, where practical, change the factor on a small scale and watch the effect.

   • Go to the process and see the mechanism
   • Run a small confirming trial or designed experiment
   • Check for alternative explanations and confounding

   Output: Verified root causes and the evidence for each

   Watch for: Accepting a statistical association without a mechanism or a test

7. 7

   Quantify the contribution and hold the tollgate

   Estimate how much of the gap each verified cause explains and what the business case looks like when they are fixed. Present the causes and evidence to the sponsor and process owner.

   • Calculate the excess defects or time attributable to each cause
   • Update the business case with finance
   • Use the tollgate checklist in this tab

   Output: A gap-closure estimate and a recorded tollgate decision

   Watch for: A list of causes with no estimate of their size

Generating Hypotheses with Structure

A hypothesis in Analyze is a testable statement of a cause: “Failures at connector seating are higher on fixture 3 because its contact pins are worn.” Good hypotheses are specific, tied to a process step, and testable with data or observation.

Symptoms, causes, and root causes. A symptom is what is observed (“connector not seated”). A cause explains it (“contact pins on fixture 3 are worn”). A root cause is the underlying condition that, if corrected, prevents recurrence (“the pin replacement interval was missed because the preventive maintenance task was skipped in a holiday week and has no check”). Keep asking why while the answer is something the team can act on, and verify each link.

Prioritizing What to Test

A fishbone can produce fifty causes. Testing all of them is wasteful. Prioritize by how likely each is to be true, how much it could influence the problem, and how easy it is to test.

A cause-and-effect matrix (rating each input against the customer requirements and weighting by importance) gives a transparent ranking, and the Impact-Effort Matrix Builder can help balance influence against the effort of testing. An FMEA ranks failure modes by severity, occurrence, and detection; use the FMEA RPN and Action Priority Tool.

Link every hypothesis to a test. For each, write what you will look at, what result would support it, and what result would reject it, before you look. This protects against reading the data to fit the theory.

Process Analysis: Causes in the Flow of Work

Some causes show up in numbers; many are visible only by watching the process. Process analysis looks for causes in how work moves: where it waits, where it loops back, where handoffs lose information, and where methods vary between people.

Use the Value-Added Flow Analysis tool and the Cycle Time and Takt Gap Analyzer for the numbers. See also the Standard Work guide when method variation is the finding.

Data Analysis: Start with Pictures, Then Test

Statistical tests answer narrow questions. Before running any, plot the data and ask what the picture suggests. Choose the technique by the type of data in the outcome (Y) and the factor (X).

Before applying a test, check its assumptions: independent observations, adequate sample size, and, for many tests, approximately normal data or similar spread between groups. Use the normality testing and plots for that check.

Hypothesis Testing in Practice

A hypothesis test asks whether the difference in the data is larger than chance would plausibly produce. The null hypothesis states there is no difference or effect. The alternative states that there is. The p-value is the probability of seeing a result at least as extreme as the data if the null hypothesis were true.

Statistical versus practical significance. With very large samples, tiny differences become statistically significant. With small samples, large differences can fail to reach significance. Always ask whether the effect is large enough to matter for the CTQ, and whether the sample was large enough to detect an effect of that size. See the Hypothesis Testing guide for a full treatment and the Sample Size and Confidence Calculator for planning.

Relationships Between Variables: Correlation, Regression, and Experiments

When the factor and the outcome are both continuous, a scatter plot shows whether they move together. Regression fits a line (or a more complex model) and estimates how much the outcome changes per unit change in the factor.

Correlation is not causation. Two measures can move together because one causes the other, because a third factor drives both, because of reverse causation, or by coincidence. Historical (observational) data can suggest causes but rarely prove them.

Designed experiments establish cause. When you deliberately change factors in a planned pattern and randomize the runs, differences in the outcome can be attributed to the factors and their interactions. Use a designed experiment when historical data cannot separate causes, when factors interact, or when you need to know the effect of a change before making it. See the Design of Experiments guide, the DOE Quick Planner, and Design of Experiments.

Verifying a Cause Before You Act on It

Before a cause goes into the report, put it through several checks. The more of them it passes, the more confidence you can have.

Go and see. Observe the mechanism where it happens. A short visit to the workstation, with a camera or gauge, often turns a statistical result into an understanding. Test small. A confirming trial on one fixture or one station is cheap and decisive, and it is part of verification, not the Improve phase's full implementation.

Worked Example: Line 3 Final-Test Yield

This example continues the project from Define and Measure. The baseline was a first-pass yield of 91.2% against a goal of 96.0%. The Pareto chart showed that connector seating (40% of failures), firmware load errors (26%), and intermittent sensor failures (16%) accounted for 82% of the 8,448 failures in eight weeks. All figures are illustrative.

Hypotheses and tests. The team lists changes made around week 14 and builds a fishbone for each of the three failure types. It prioritizes the hypotheses that fit the timing and tests each in turn.

Hypothesis 1: contact pin wear on one fixture. Plotting connector-seating failures by fixture shows a clear outlier.

Inspection shows the contact pins on fixture 3 are beyond their wear limit, and maintenance records show the pin replacement interval was passed in week 13, when a preventive maintenance task was skipped during a holiday week. A trial replacing the pins on fixture 3 returns its failure rate to 2.4% within three days.

The shift puzzle. In Measure, shift 3 had the highest failure rate (11.0%). The fixture finding explains why: fixture 3 ran 45% of shift 3's volume, against 20% and 10% on shifts 2 and 1. The apparent shift effect was largely a fixture effect. This is a common example of confounding, and it shows why a stratified difference is a hypothesis and not a cause.

Hypothesis 2: the firmware change. Three of the six test stations moved to firmware v2.3 in week 14, and three remained on v2.2 for logistical reasons. Over the same weeks, shifts, and products, firmware load failures were about 4.1% on v2.3 stations and about 0.5% on v2.2 stations. The station logs show load timeouts, and rolling one station back to v2.2 reduces its rate to 0.6%.

Hypothesis 3: sensor lot. Traceability shows that 30,000 of the 96,000 units used sensors from a new supplier lot, introduced in week 14. Intermittent sensor failures were about 3.9% on lot B units and about 0.3% on all others. Incoming tests of lot B parts reproduce the intermittent behavior.

Quantifying How Much Each Cause Explains

Finding causes is not enough; the team must show that they are large enough to reach the goal. For each verified cause, estimate the excess defects it produces, which is the observed defects minus the number expected without it.

Update the business case. Each percentage point of yield at 600,000 units a year and $6.40 per reworked unit is worth about $38,400. The three causes are therefore worth about $160,000 a year, close to the $184,000 target in the charter; the remainder depends on the smaller causes. Review the figures with finance and decide with the sponsor whether to pursue the remaining gap in Improve.

Analytical Pitfalls to Avoid

Tollgate Review: Are We Ready for Improve?

The Analyze tollgate confirms that the causes are credible and large enough to justify solutions. Use the checklist before the review. Progress saves in this browser only, and nothing is sent anywhere.

Questions a sponsor should ask:

• What is the evidence for each cause, and how was it checked?
• How much of the gap does each cause explain, and how much remains?
• Could something else explain the same pattern?
• Have we seen the mechanism with our own eyes?
• What did we test that turned out not to be a cause?
• Do the findings change the goal or the business case?

Adapting Analyze to the Situation

Qualitative evidence counts. Interviews, observations, photographs, and failed-part examinations are legitimate evidence. Record them with dates and sources, and use them with the data, not instead of it.

Common Mistakes and Red Flags

Analyze Resources on This Site

Analyze Phase Frequently Asked Questions

Sources and Further Reading