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

What the Improve Phase Is For

Analyze identified why the problem occurs. Improve changes the process so that it stops. The phase is not complete when a solution has been chosen, or even implemented: it is complete when the team has shown with data that performance improved, that the improvement is attributable to the change, and that the process owner can run the new process.

The Improve Process, Step by Step

1. 1

   Review the verified causes and write the solution brief

   List each verified cause, how much of the gap it explains, and the requirements any solution must meet, such as cost limits, safety, regulatory constraints, and customer requirements.

   • Link each solution area to a verified cause
   • Record constraints and must-haves
   • Include the people who will use or maintain the solution

   Output: A solution brief for each cause

   Watch for: Looking for solutions to causes that were never verified

2. 2

   Generate solution options

   Develop several options per cause. Use structured creativity and look at what others have done, then fill the options in enough to compare them.

   • Brainstorm, then challenge assumptions
   • Look at lean and mistake-proofing tools
   • Benchmark inside and outside the organization
   • Capture ideas from Analyze that were parked

   Output: At least two or three options per cause, described clearly

   Watch for: A single idea presented as the only option

3. 3

   Select the solutions

   Compare the options against criteria the sponsor and process owner agree: effect on the CTQ, sustainability, cost, time, risk, and effect on people.

   • Weight the criteria before scoring
   • Use a Pugh or weighted matrix
   • Test the ranking for sensitivity
   • Record the reasons for the choice

   Output: Selected solutions with a documented rationale

   Watch for: Scoring after the preferred option is already known

4. 4

   Assess the risk of the solutions

   Ask how each solution could fail or cause harm, and what would prevent or detect it. Update risk mitigation and the control approach.

   • Run an FMEA on the new process or change
   • Plan actions for the highest risks
   • Agree rollback criteria

   Output: A solution risk assessment and mitigation actions

   Watch for: Assuming that because a solution addresses a cause, it is safe

5. 5

   Pilot the solution

   Test on a limited scale under real conditions, with a plan for what will be measured and what result counts as success.

   • Define scope, duration, and measures
   • Train the pilot users
   • Compare with the baseline or a comparison group
   • Record problems and what users say

   Output: Pilot results, user feedback, and a decision to scale, adjust, or stop

   Watch for: A pilot run by the best people with unusual attention, which does not predict full-scale results

6. 6

   Verify the improvement and the benefit

   Use data to show the improvement and its size, and compare the results with predictions. Recalculate the benefit using actual results.

   • Plot data over time with changes marked
   • Compare before and after with an appropriate test and an interval
   • Check across shifts, products, and conditions
   • Agree the benefit with finance

   Output: Verified improvement and a validated benefit estimate

   Watch for: Reporting a short run of good results as proof

7. 7

   Implement with the people affected

   Roll out the solution with a plan covering training, documentation, communication, support, and rollback. Hand over to the process owner.

   • Update procedures and work instructions
   • Train everyone who will use the solution
   • Communicate the reason and the results
   • Monitor early results closely

   Output: Implemented solution, updated documentation, and trained staff

   Watch for: Implementation treated as an announcement

8. 8

   Hold the tollgate

   Present the solutions, evidence, benefit, and implementation to the sponsor and process owner. Confirm that the team can move to Control.

   • Use the tollgate checklist in this tab
   • Record decisions and any conditions

   Output: A recorded tollgate decision

   Watch for: Moving on before the process owner has accepted the new process

Generating Solution Options

Good solutions come from understanding the cause and then looking widely. Start with each verified cause and ask how the process could be changed so that the cause could not occur, would be detected immediately, or would have little effect.

Address each verified cause directly. For the Line 3 example, the options include replacing the worn contact pins on fixture 3, adding a pin-life counter that blocks use past a limit, redesigning the fixture contact, adding a maintenance check, rolling back or patching the firmware, and quarantining sensor lot B with incoming inspection. Some options address one cause; others address several.

Solution Strength: Build It Into the Process

The same cause can be addressed in ways that differ greatly in how long the improvement lasts. Solutions that depend on people remembering are weak, because attention fades and people change. Solutions that are built into the process are strong.

Mistake-proofing levels. Mistake-proofing devices are often ranked as elimination (remove the possibility of the error), replacement (a more reliable process), facilitation (make the right action easier), detection (flag the error as it happens), and mitigation (reduce the harm). See Mistake-Proofing Levels, Poka-Yoke, and the Poka-Yoke Effectiveness Estimator.

Selecting Solutions with Criteria

Compare options openly. Agree the criteria and their weights before scoring, so that the discussion is about the options and not about defending a favorite.

A weighted scoring matrix for the fixture 3 options (scores from 1 to 5, higher is better; the maximum possible total is 85):

Option A scores highest. B is close, and the team decides to include B's checklist item as a backup. Training alone (D) scores lowest because it depends on people remembering. A sensitivity check (changing the weights to see whether the ranking changes) shows A and B swap places if cost is weighted much more heavily, and the sponsor confirms that sustainability should carry more weight here. The scoring is a way to structure the decision, not to replace judgment.

Use the Pugh Matrix Builder to compare options against a baseline, the Project Prioritization Matrix for weighted scoring, and the Impact-Effort Matrix Builder for a quick view. See Prioritization Matrix and PICK Chart.

Assessing the Risk of the Solutions

New solutions create new ways to fail. Before piloting, ask what could go wrong with each selected solution, how likely it is, how serious, and whether it would be noticed. A failure mode and effects analysis (FMEA) structures the answers and ranks the risks by severity, occurrence, and detection.

RPN is severity × occurrence × detection. Treat it as a ranking aid; severity and the plausible consequence deserve attention on their own. The example numbers are illustrative. See the FMEA RPN and Action Priority Tool, the PFMEA Template, and the FMEA guide.

Plan the response. For each high-ranked risk, define prevention, detection, and a contingency. Agree rollback criteria in advance: what result in the pilot would cause the team to stop, adjust, or revert. See Risk Mitigation Strategies and the Risk Matrix Builder.

Optimizing Settings with a Designed Experiment

Some solutions involve settings, such as temperatures, times, speeds, or software parameters. When several factors may matter and may interact, testing them one at a time is slow and can miss the best combination. A designed experiment tests combinations systematically and estimates each factor's effect and the interactions.

Example. The team fixes the firmware load problem by changing two settings: the load timeout (30 or 45 seconds) and an automatic retry (off or on). A 2×2 factorial with the same number of runs in each combination gives these illustrative results.

Randomize the run order, replicate the runs, and confirm the best settings with a trial at those settings. Where curvature is expected, follow a screening design with a response surface design to find the optimum. See the Design of Experiments guide, the DOE Quick Planner, Response Surface Methodology, and Taguchi Methods.

Piloting the Solution

A pilot is a planned test at limited scale, under real conditions, with measures and criteria defined in advance. It uses the plan-do-study-act (PDSA) cycle: predict the result, try the change, study what happened against the prediction, and decide to adopt, adapt, or abandon. See the PDCA Cycle guide and the Model for Improvement guide.

• Choose a representative pilot. A pilot on the quietest line with the best operators may overstate success.
• Make a prediction first. Compare the result with the prediction. A result better or worse than predicted is information to follow up.
• Change one thing at a time where possible, or stagger the changes, so that the effect of each can be seen.
• Watch for side effects with balancing measures such as downtime, rework, and operator workload.
• Listen to the users. Their comments often reveal problems the data cannot.
• Decide in advance what result leads to adopt, adapt, or abandon.

Verifying That the Improvement Is Real

The pilot shows whether the solution works. Verification shows how much, with how much confidence, and whether it was the change that caused it. Plot the data over time with each change marked, then confirm with a statistical comparison.

Compare with the goal. The goal was a first-pass yield of at least 96.0%, sustained for eight consecutive weeks. The data so far show five weeks near the goal. Sustaining the gain is the work of the Control phase, and the full verification closes there.

Use the Hypothesis Testing Quick Tester for the comparison, the Control Chart Selector for the chart, and the Process Capability Helper if the Y is a measurement.

Implementing with the People Who Use It

A good solution that people do not adopt delivers nothing. Implementation is a project in its own right, with a plan, owners, dates, and attention to people.

• Explain the reason with data. People follow changes they understand.
• Train at the point of work. Practice on the real equipment, and confirm that each person can perform the task.
• Update the documents. Procedures, work instructions, training records, control plans, and, where relevant, controlled change records. In regulated environments, follow your change control and validation procedures.
• Anticipate resistance. Use a stakeholder analysis and a force field analysis to understand who gains, who loses, and what might block the change; see the Change Management guide, the Force Field Analysis Builder, and ADKAR.
• Support the first weeks. Be visible on the floor, answer questions, and fix problems quickly.
• Know the rollback. Define how to revert and who decides.

For a management-of-change record, use the Management of Change Register; for standard work, the Lean Standard Work Template.

Validating the Benefit

The business case in Define was an estimate. At the end of Improve, replace it with a validated figure based on actual results, calculated with the method agreed with finance.

This is close to the $184,000 estimate in the charter. Use the Project ROI Calculator and the Kaizen Savings ROI Calculator for the investment view.

Tollgate Review: Are We Ready for Control?

The Improve tollgate confirms that the improvement is proven, the benefit is real, and the process owner can run the new process. Use the checklist before the review. Progress saves in this browser only, and nothing is sent anywhere.

Questions a sponsor should ask:

• How do you know the improvement was caused by your changes?
• How large is the improvement, and how sure are you?
• What could make it fail, and what have you done about it?
• Do the people who run the process agree this is better?
• What would we see if the gain started to slip?
• Has finance agreed the benefit?

Adapting Improve to the Situation

Cost and time matter. Choose solutions the organization can afford and sustain. A modest solution that is adopted and works is better than an elegant one that stalls.

Common Mistakes and Red Flags

Improve Resources on This Site

Improve Phase Frequently Asked Questions

Sources and Further Reading

What the Control Phase Is For

Most processes that were improved drift back unless something holds them in place. People change jobs, equipment wears, suppliers change, attention moves on, and shortcuts reappear. Control is the phase that builds the mechanisms, owners, and habits that keep the new performance in place after the project team goes.

The Control Process, Step by Step

1. 1

   Confirm the improvement is stable

   Use the post-implementation data to show that the process is performing at the new level and is statistically stable. Investigate any signals before setting limits.

   • Plot data in time order and check for special causes
   • Recalculate the baseline and capability
   • Confirm results across shifts, products, and conditions

   Output: Evidence of stable, improved performance

   Watch for: Setting limits from data that include unexplained shifts

2. 2

   Standardize the new process

   Make the improved method the documented, trained, and visible standard. Strengthen it with prevention built into equipment and systems.

   • Update SOPs, work instructions, and standard work
   • Train and verify competence for everyone affected
   • Add visual controls and mistake-proofing
   • Retire the old documents and methods

   Output: Documented, trained standard work with built-in prevention

   Watch for: A new procedure that exists on paper but not at the workstation

3. 3

   Build the control plan

   For each critical input and output, define the specification, how it is measured, the sample and frequency, the control method, the reaction plan, and the owner.

   • Start from the vital few Xs and the primary Y
   • Link to the PFMEA and the solution risk assessment
   • Keep it short and usable

   Output: A control plan that the process owner can run

   Watch for: A control plan listing everything, so that nothing is controlled well

4. 4

   Set up monitoring and reaction plans

   Put charts, audits, and dashboards in place, with clear signals and defined responses, and decide who looks at what and when.

   • Calculate control limits from stable data
   • Define the rules for signals and the response to each
   • Set review cadences from the shift to the management level

   Output: Working charts and checks, with reaction plans

   Watch for: Monitoring set up by the project team and not by the process owner

5. 5

   Hand over to the process owner

   Walk the process owner and the team through the controls, the data, and the history of the problem. Confirm who owns what, and agree what support remains.

   • Run a joint review of the control plan
   • Agree responsibilities with a RACI
   • Provide access to data, charts, and documents

   Output: Documented handover and the process owner's acceptance

   Watch for: Handover by email with no discussion

6. 6

   Validate and track the benefits

   Confirm the benefit with finance using actual results, and agree how it will be tracked over the following months.

   • Compare actual savings with the business case
   • Separate hard savings from soft benefits
   • Schedule follow-up reviews

   Output: Finance-confirmed benefit and a tracking schedule

   Watch for: Reporting the projected annual saving as if it were realized

7. 7

   Close the project and share what was learned

   Prepare the closure report, record lessons learned, store the documents, consider where else the improvement applies, and release and recognize the team.

   • Hold the closure review with the sponsor
   • Record lessons in a shared place
   • Plan replication and follow-up projects
   • Recognize the team

   Output: Closure report, lessons learned, replication plan, and team release

   Watch for: Closing quietly, so that nobody learns from the project

Why Gains Fade, and What Prevents It

Most backsliding has predictable causes. Anticipating them shapes the controls.

Design the controls to be as automatic as possible. Prevention built into equipment, software, or fixtures does not depend on memory or attention. See the strength of solutions discussed in the Improve tab and the Mistake-Proofing guide.

Standardizing the New Process

Standardization turns the pilot into the way of working. It is a set of documents, skills, and visual cues that make the right method the easy one.

In certified or regulated environments, follow your quality management system's document and record control, change control, and training requirements. Use the Lean Standard Work Template and the Job Breakdown Sheet to document the method.

The Control Plan

A control plan is a living document that lists what is controlled, how, and what to do when it goes wrong. It links the process failure modes analyzed earlier to the controls that address them. Keep it focused on the few characteristics that matter.

Principles. Control the inputs that cause the outcome as well as the outcome itself, because inputs give earlier warning. Specify the sample size and the frequency so that the monitoring is practical. Give each control an owner. Write the reaction plan in the plan itself, in plain language. Link the plan to the process FMEA, and review it whenever the process changes. See the PFMEA and Control Plan template, the PFMEA Template, and Control Plan, Control Plan Development, and Control and Sustainment.

Control Charts: Seeing Change Early

A control chart separates normal variation from signals that the process has changed. It is the main tool for monitoring a process after improvement, because it tells the owner when to act and, just as important, when not to.

Use the Control Chart Selector to choose a chart, the Control Limits Generator to calculate limits, the p-Chart Calculator for proportions, and the SPC Control Chart Data Sheet to record data.

Common rules for signals. Organizations adopt a set of rules, and the same rules should be used consistently. Widely used rules include:

• One point beyond a control limit (three standard deviations from the center line)
• A run of eight or nine points in a row on the same side of the center line
• A trend of six points steadily increasing or decreasing
• Two of three points beyond two standard deviations on the same side
• Fourteen points alternating up and down

Set limits from stable data. Calculate limits from a period when the process was stable at the new level. Do not recalculate after each signal, and do not use specification limits as control limits. Recalculate only after a deliberate, lasting change in the process. See the SPC Control Charts guide.

Monitoring, Audits, and Review Cadence

Charts show the numbers. Audits and reviews show whether the method is followed and whether the numbers are acted on. A monitoring system combines them at different levels and frequencies.

• Layered process audits check that the controls and standards are followed at the workstation, by people at different levels; see the Layered Process Audits guide.
• Dashboards and visual boards keep the Y, the key Xs, and open actions visible; see the Multi-Metric Manufacturing Dashboard.
• Leading indicators (such as the pin-life counter and fixture checks) warn before the outcome measure moves; see the Leading and Lagging Indicators guide.
• Gemba walks let leaders see the process and ask about the controls; see the Gemba Walk guide.
• Metric governance keeps definitions and data sources stable; see Metric Governance.

Reaction Plans: What to Do When a Signal Appears

A reaction plan, often called an out-of-control action plan (OCAP), tells people what to do when a chart or check signals a problem. It turns a signal into a response so that the response does not depend on who happens to be on shift.

Apply the plan to the example. In week 17 the chart shows 95.1%. The technician follows the plan: contain the week's units, check the fixtures, firmware versions, and sensor lots. The cause is a new sensor lot (lot C) with a slightly different tolerance that had not been communicated. The team quarantines the lot, agrees an incoming test, adds change notification to the supplier agreement, and records the lesson. Yield returns to the center line in week 18.

Practice it. Run through a reaction plan with the team in a simple drill, so that the first real signal is not the first time anyone has used it. See Reaction Plan and the 5 Whys guide for investigating a signal.

Confirming the New Baseline and Capability

After the process has run stably at the new level, recalculate the baseline and capability so that the improvement is documented in the same terms as the original problem. This also provides the reference for future comparison.

Use the same definitions and method as in Measure so that the comparison is valid, and state the period and the sample size. Use the Sigma Level and DPMO Suite and, for measurement data, the Process Capability Helper. If the performance is still short of a customer or business requirement, the project may be followed by a further cycle, which is normal.

Handover and Ownership

The project leader and team will move on. If the people who run the process have not taken ownership, the controls will lapse. The handover is a deliberate event and not a document sent by email.

• Walk through it together. Review the control plan, the charts, the reaction plan, and the history of the problem with the process owner and the team, on the floor.
• Check understanding. Ask the process owner to explain the controls. Gaps in the explanation are gaps in the handover.
• Build the habit. Put the review of the charts into an existing meeting and make the process owner the chair.
• Align goals and recognition. If the metric is not in anyone's goals, it will fade. Include it in the dashboard and in performance conversations.
• Plan the support. Agree who the process owner can call, and for how long, when questions arise.

Build the RACI with the RACI Matrix Builder. For the people side of sustaining change, see the Change Management guide, Sustaining Continuous Improvement, and Continuous Improvement Culture.

Tracking Benefits After Closure

The savings estimated at the start of the project become real only when they appear in the financial results. Finance should confirm them, and the process owner should keep tracking them for the agreed period.

• Report hard and soft benefits separately. Savings that change the budget are hard. Capacity, avoided cost, and risk reduction are real but are reported separately.
• Show actual versus plan. If results fall short of the business case, find out why, and act.
• Update the baseline in budgets. Savings that are not reflected in budgets and plans can be spent on something else.
• Watch for costs that moved. Check that a saving in one area did not simply move to another.

See the Project ROI Calculator and the Kaizen Savings ROI Calculator.

Closing the Project, Sharing Lessons, and Replicating

A project is closed formally, with a review, a report, and the lessons recorded. Closure is also the moment to ask where else the improvement could apply.

• Lessons learned. Hold a short, honest review with the team, record the findings in a shared place, and act on them. See Lessons Learned Process.
• Replication. Consider other lines, sites, and similar processes. Check that the same causes exist there, adapt the solution, and pilot it. This practice is known as horizontal deployment or yokoten; see Yokoten.
• Knowledge management. File the report, data, and tools where others can find them, and tag them with the problem type and the methods used.
• Recognition and release. Thank the team, share the result with the people who made it work, and release the team members back to their roles or to the next project.
• Next steps. Identify the remaining gap (in the example, about 0.6 points to other minor causes) and decide whether to start a follow-up project.

The Line 3 Project from Start to Finish

The worked example in this toolbox follows one project through all five phases. All figures are illustrative.

Closure Review: Is the Gain Secure?

The closure review confirms that the improvement is stable, the controls are working, and the process owner owns the result. Use the checklist before the review. Progress saves in this browser only, and nothing is sent anywhere.

Questions a sponsor should ask:

• How long has the process held the new level, and how do you know it is stable?
• What will tell us first if it starts to slip, and what will happen then?
• Who owns this now, and do they agree?
• What happens when the people trained on this move on?
• Has finance confirmed the benefit, and how will we track it?
• Where else could this apply, and what did we learn?

Adapting Control to the Situation

Scale the controls to the improvement. A small change may need only an updated work instruction and a weekly check. A large change may need a full control plan, charts, audits, and a reaction plan. Match the effort to the risk of backsliding and the value at stake.

Common Mistakes and Red Flags

Control Resources on This Site

Control Phase Frequently Asked Questions

Sources and Further Reading