Guides / Six Sigma / PDCA Toolbox
One place for each step of the plan-do-check-act cycle: what it is for, the steps, the tools, the checklist, and the mistakes to avoid.
Choose a step tab below. Each tab opens with an overview, then covers the details needed to run that step well, with links to the calculators, templates, and guides on this site. All four steps are available: Plan, Do, Check, and Act.
PDCA is a repeating cycle of learning: plan a change and predict its effect, test it on a small scale, study what happened, and act on what you learned. Each pass makes the next one better informed. A single example runs through all four tabs: a pack-out station where 3.1% of shipments left with the wrong label. All figures in the examples are illustrative.
| Step | Key question | Main outputs | Gate decision |
|---|---|---|---|
| P · Plan | What are we trying to improve, and what change do we expect to work? | Problem and target, facts, cause theory, prediction, test plan | Owner confirms the plan is clear, safe, and ready to test |
| D · Do | Can we run the test as planned and record what happens? | A small test, data, observations, deviations, and surprises | Owner confirms the test is complete and the data are enough to study |
| C · Check | What happened, and how does it compare with what we predicted? | Results against the prediction, side effects, and what was learned | Owner decides whether the evidence supports adopting, adapting, or abandoning the change |
| A · Act | What will we do with what we learned? | A standard method or the next cycle, a spread plan, updated controls, lessons recorded | The change is adopted and owned, or the next cycle is planned |
PDCA (plan-do-check-act) and PDSA (plan-do-study-act) describe the same cycle; PDSA stresses studying the results against a prediction. PDCA was developed from the work of Walter Shewhart and popularized by W. Edwards Deming. It is the base of many methods and is also the structure behind ISO management system standards.
| Method | Best for | Typical size |
|---|---|---|
| PDCA / PDSA | Testing a change quickly, learning, and improving step by step | Hours to weeks; one team or area |
| A3 problem solving | Structured thinking on one page, with coaching, using PDCA as the backbone | Weeks; one problem owner |
| Kaizen event | A focused improvement by a cross-functional team in a few days | A few days, with follow-up |
| DMAIC | Complex problems that need measurement, statistics, and a control plan | Months; cross-functional project |
See the DMAIC Toolbox for projects that need more depth. Inside a DMAIC project, every pilot is a PDCA cycle.
Step 1 of 4
What are we trying to improve, why is it happening, and what change do we expect to work? Plan turns a vague concern into a clear problem, a target, a theory about the cause, a change to test, and a prediction of what will happen. It also designs the test, so that when the team acts, they will learn something, whatever the result.
Plan is where the learning is designed. A change tried without a plan can show that something happened, but not why. A change tried with a plan shows whether the team’s understanding of the problem was right, and that understanding is what makes the next improvement faster.
Pick one problem that matters to a customer, to safety, or to the cost or flow of the work, and that the team can influence. Choose an opportunity small enough for a first cycle.
Go to where the work happens. Watch it, talk to the people, and collect simple facts. Replace opinions with observations and counts.
Write the problem as a gap between actual and expected performance, with numbers and a time period. Set a target that uses the same measure and a date.
Break the problem down to where it happens most, then ask why. Use data and observation to separate likely causes from guesses.
State the theory in the form: if we make this change, then this result will occur, because of this cause. Say how much improvement you expect.
List possible changes, compare them on impact, effort, and risk, and pick one to test first. Prefer changes that act on the cause directly and that are easy to reverse.
Decide who will test the change, where, for how long, and how it will be measured. Write the plan so that it can be run without you.
Brief the people who will be involved, confirm that they understand and agree, and check that materials, time, and permissions are in place.
PDCA is flexible. A cycle can last an afternoon or several months. The first planning decision is whether PDCA is the right size of tool for the problem, or whether a structured project such as DMAIC is needed.
| Situation | PDCA cycle | Larger project (DMAIC, A3, or kaizen event) |
|---|---|---|
| Cause | Suspected or partly known; can be tested directly | Unknown, complex, or involves several interacting factors |
| Scope | One team, area, or process step | Several departments or a whole value stream |
| Data | Simple counts, times, and run charts are enough | Needs measurement system checks, capability, or advanced analysis |
| Risk of a wrong change | Low or easily reversed | High cost, safety, regulatory, or customer impact |
| Time and resource | Hours to weeks; the team’s own time | Weeks to months; dedicated leader and sponsor |
| Typical outcome | A better method, a standard, or the next question | A verified solution with a control plan and a financial result |
PDCA and DMAIC are not rivals. A DMAIC project is made of many PDCA cycles, especially in Improve, where each pilot is a PDCA cycle. A problem that starts as a PDCA cycle may reveal that it needs a project, and the learning from the cycle is the start of the Define phase. See the DMAIC Toolbox, the A3 Problem Solving guide, and the Kaizen Event guide.
PDCA at several levels. The same cycle runs at the level of the individual task, the team’s daily improvement, a project, and a company’s annual plan. Policy deployment systems such as Hoshin Kanri use PDCA at the management level.
Teams often have more problems than time. A simple way to choose is to ask which problem is the most important, can be influenced, and can be measured.
| Question | Why it matters | Where to look |
|---|---|---|
| Does it affect a customer, safety, quality, delivery, or cost? | Work that matters earns support and shows value | Complaints, returns, incident reports, schedule and cost data |
| How big is the gap? | Large, frequent problems pay back faster | Counts and rates over a recent period |
| Can the team influence the cause? | Problems outside the team’s control stall | Process boundaries and decision rights |
| Can we measure it? | Without a measure, learning is guesswork | Existing data or an easy check sheet |
| Is it ready now? | Timing and people matter | Workload, other projects, planned changes |
Use the Project Prioritization Matrix or the Impact and Effort Matrix Builder to compare candidate problems. If the daily management system shows a measure outside its target, that gap is a ready-made starting point.
The current condition is what really happens today, not what the procedure says. Direct observation is the most reliable source. Most teams find that what people do differs from the documented method, and that the difference holds clues to the problem.
| Method | What it reveals | How to do it |
|---|---|---|
| Go to the place (gemba) | How the work is really done, and what gets in the way | Observe for long enough to see normal and abnormal conditions; take notes, not opinions; see the Gemba Walk guide |
| Process map | Steps, handoffs, waits, and decision points | Draw the process as it is, with the people who do it; see the Process Map Builder |
| Check sheet | How often and where problems occur | A simple form filled in as events happen |
| Time and count data | Cycle times, waits, and error rates | Stopwatch observations, system timestamps, or counts by period |
| Run chart | How the measure changes over time | Plot the measure in time order; look for patterns before testing |
| Conversation with the people doing the work | Causes that are not visible | Ask open questions, listen, and do not defend the current method |
Capture the facts on a one-page A3 or in the PDCA Learning Workbook, so the whole team can see them.
A good problem statement describes a gap with numbers. It says what is wrong, where, how much, and over what period. It does not name a cause or propose a solution.
| Weak statement | Better statement |
|---|---|
| We have too many shipping errors. | In the last four weeks, 149 of 4,800 shipments (3.1%) left Station 2 with a label that did not match the packed order, against a goal of under 1%. |
| We need a new labeling system. | Mislabeled shipments rose from 1.8% to 3.1% over the past quarter, costing about $27 per error in reshipping, carrier fees, and customer contact. |
| Operators do not follow the procedure. | In 20 observed orders, the packer had two orders open at once on 9 (45%); errors with two orders open account for 29% of mislabels in the last four weeks. |
The examples are illustrative.
The target should use the same measure as the problem statement, give the baseline and the goal, and set a date. It can be stepped: a goal for the first cycle and a longer-term goal for the series of cycles. For the Station 2 example, the overall target is under 1.0% within six weeks, with an interim prediction for each cycle.
Once the problem is stated, look for where it happens most. A Pareto chart ranks causes, places, or times, and shows where effort will pay back most. Then ask why, and test the answers against the facts.
| Tool | Use it to | Tips |
|---|---|---|
| Pareto chart | Find the few categories that account for most of the problem | Stratify by cause, place, time, product, or person; see Pareto Analysis and the Pareto Chart Builder |
| 5 Whys | Follow a chain of causes from the symptom to a cause you can act on | Ask why until you reach something you can change; check each answer with facts; see 5 Why Root Cause Analysis |
| Fishbone diagram | Organize many possible causes by category | Use for broad problems, then verify the likely causes; see Fishbone Analysis |
| Is and is-not comparison | Narrow the cause by comparing where the problem occurs with where it does not | Compare shifts, stations, products, and times |
| Brainstorming | Generate ideas with the team | Collect ideas first and evaluate later; see Brainstorming Methods |
A 5 Whys chain from the example. Why was the wrong label on the box? The packer applied a label that belonged to a different order. Why? Labels come out of the printer in a batch, in a different sequence from the one in which the packer works, and sometimes two orders are open at once. Why are two orders open? The packer starts the next order while waiting for the label to print. Why is there a wait? Labels print every couple of minutes in a batch, not when the order is ready. Why does that matter? Nothing ties a label to the order in front of the packer. The team now has two causes it can act on: the label sequence from the batch printer (stack and tray), and the habit of holding two orders open.
Verify before you build on a cause. Ask whether the cause explains the pattern: where, when, and how often. If a cause is plausible but not yet checked, the first cycle can be a test of that cause. Use the 5 Why Root Cause Tool and the Fishbone Builder to document the analysis.
A hypothesis links a change to a result through a cause. The prediction states how big the result will be. Writing both before the test is what makes the cycle a learning cycle, because the result will either confirm the theory or challenge it.
| Part | Form | Example (Station 2) |
|---|---|---|
| Cause | We believe the problem is caused by … | Packers keep two orders open at once to cover the wait for labels, so a label is applied to the wrong box |
| Change | If we … | allow only one order to be open at the station at a time, marked by an order-in-progress tote |
| Prediction | Then … will happen, by about … | mislabels will fall from 3.1% to about 2.2%, because errors with two orders open caused 29% of the total |
| Reasoning | Because … | With one order open, there is no second box to put the label on |
| What would surprise us | If we see …, our theory is wrong | No change in the rate, or a large rise in waiting time |
This approach is the core of the Model for Improvement; see the Model for Improvement and PDSA guide.
Generate several candidate changes, then choose by evidence. Compare options on the size of the expected effect, the effort and cost, the risk, and how directly the change acts on a verified cause.
| Option | Acts on | Expected impact | Effort and risk | Decision |
|---|---|---|---|---|
| One order open at a time, with a marker tote | Two orders open at once (29%) | Medium | Low; no equipment; easy to reverse; may add some waiting | Test first |
| Print label on scan at the station | Wrong-stack pulls (41%) and leftover labels (14%) | High | Medium; needs printer setup and a short trial | Test second |
| Color-coded label stacks | Wrong-stack pulls | Low to medium | Low; depends on attention | Hold |
| Retrain the packers | Two orders open at once | Low and temporary | Low cost; effect fades | Do not rely on it |
Prefer changes that prevent the problem. A change that makes the error impossible or immediately visible is stronger than a reminder or training. For more on the ranking of solutions, see Mistake-Proofing. The Pugh Matrix Builder and the Impact and Effort Matrix Builder help compare options.
Test one change at a time when you can. If two changes are tested together, the result cannot say which one worked. When speed matters, test them in sequence in successive cycles, as the example does.
A test plan answers the questions that anyone running it will ask: what exactly are we changing, who will do it, where and when, what will we measure, how will we record it, and when do we stop.
| Element | Decide | Example (Cycle 1) |
|---|---|---|
| Change | Exactly what is different from the current method | One order open at a time; the order-in-progress tote marks the active order; the next order is pulled only after the box is closed and labeled |
| Scope | Who, where, which products, how many | Station 2, all packers, all products |
| Duration | How long the test runs before the Check step | Five working days (about 1,250 shipments) |
| Comparison | What the result will be compared with | Baseline of 3.1% from four weeks (4,800 shipments) |
| Measures | Outcome, process, and balancing measures | Mislabeled shipments per day; orders handled with one open (observed); seconds per shipment |
| Data collection | Who records what, on which form, and how often | Station lead tallies errors at the end of each day; the scanner logs time stamps; a supervisor observes 20 orders per shift |
| Prediction | The expected result | About 2.2% mislabeled; pack time up by 5 to 10 seconds |
| Stop and rollback | Conditions that end the test early | Any safety concern, any increase above baseline, or a backlog of more than 30 minutes |
| Owner and roles | Who leads, who observes, who decides | Station lead runs the test; the supervisor reviews at the end of each shift |
Use the PDCA Learning Workbook to document the cycle, and the Data Collection Plan Builder for the data plan.
One measure rarely tells the whole story. Use a small family of measures: one for the outcome you want to change, a few for the process that should change, and at least one that shows whether the change caused a problem elsewhere.
| Type | Purpose | Example |
|---|---|---|
| Outcome measure | Shows whether the result improved | Percent of shipments with a mislabel |
| Process measure | Shows whether the change was carried out as planned | Percent of observed orders handled with only one order open |
| Balancing measure | Shows whether the change made something else worse | Seconds per shipment; packer overtime; backlog at the end of the shift |
| Leading indicator | Gives an early signal before the outcome moves | Orders open at the same time, per observation round |
See Data Collection Plan, SPC Control Charts, and the Model for Improvement for more on measurement choices. If the decision is costly, use the Sample Size and Confidence Calculator to check that the test can detect the effect that matters.
A change is carried out by people. A plan that ignores them will meet resistance, and a plan that ignores risks may cause harm. Spend a little planning time on both.
| Topic | Questions | Action |
|---|---|---|
| Who is affected | Who does the work, who receives it, who supports it? | List them; use the Stakeholder Analysis Builder for a larger change |
| Their concerns | What worries them: time, quality, safety, jobs? | Ask them, and change the plan where it makes sense |
| Risks of the test | What could go wrong, and how bad would it be? | Think through it as a team before starting; see the Risk Matrix Builder |
| Safety and compliance | Does the change affect safety, regulations, or customer requirements? | Check with the safety, quality, and compliance owners before starting |
| Support | Do people have time, materials, and authority? | Confirm with the supervisor and the sponsor |
| Communication | Do all affected people know what, why, and when? | Brief the team and post the plan where the work happens |
Try a pre-mortem. Before the test, ask the team: imagine it is next week and the test failed. What went wrong? The answers reveal risks that a plan review often misses, and each one can be prevented or monitored. See Change Management for Improvement for the people side of change.
A distribution center ships about 4,800 orders in a typical four-week period. A team at pack-out Station 2 followed the Plan step for one week. All figures are illustrative, and the same example continues through the other three tabs.
| Plan element | What the team wrote |
|---|---|
| Focus | Mislabeled shipments at Station 2, the largest source of customer complaints about wrong or missing delivery information |
| Current condition | Three shifts observed over five days; labels print in a batch while orders are packed in a different order; two orders were open at once on 9 of 20 observed orders |
| Problem | 149 of 4,800 shipments (3.10%) left Station 2 with the wrong label in four weeks, up from 1.8% the previous quarter; each error costs about $27 |
| Target | Under 1.0% within six weeks, for an annual saving of roughly $35,000 |
| Causes | Wrong label from the batch stack (41%) and two orders open at once (29%) account for 70% of errors; old labels left in the tray add 14% |
| Hypothesis (Cycle 1) | If only one order is open at a time, then mislabels fall from 3.1% to about 2.2%, because errors with two orders open cause 29% of the total |
| Test plan | Station 2, five working days, about 1,250 shipments; measures: mislabels per day, one-order compliance, seconds per shipment; stop if the rate rises above baseline |
| Next cycle idea | Print the label only when the order is scanned at the station, to remove the stack and tray problems (to be planned after Check) |
Annual value of the target. Annual shipments are about 62,400 (13 periods of 4,800). At 3.1% there are about 1,934 errors a year; at 1.0%, 624. The reduction of 1,310 errors at $27 is about $35,400 a year.
Before starting the Do step, the cycle owner confirms that the plan is complete. Use this checklist; progress saves in this browser only, and nothing is sent anywhere.
Questions a cycle owner or a coach can ask:
| Outcome | Meaning | Next step |
|---|---|---|
| Ready | The plan is clear, safe, and predicts a result | Start the Do step |
| Ready with conditions | Minor gaps in the data plan or the briefing | Fix them before the start date |
| Not ready | No baseline, an unclear change, or an unsafe test | Revise the plan |
| Wrong size | The problem is too big for one cycle, or the cause is unknown and complex | Break it down, or move to a DMAIC project or an A3 |
| Situation | How Plan changes |
|---|---|
| Manufacturing line | Use cycle time, defect counts, and downtime data; observe at the machine; involve the operators and maintenance |
| Service and transactional work | Map the handoffs and queues; use time stamps and error counts; observe a sample of cases; see the finance and accounting hub |
| Healthcare | Follow the Model for Improvement, with small tests on one patient or one clinic session; protect safety first; see the healthcare hub |
| Software and IT | Treat the change as an experiment, with feature flags or staged releases and monitoring; see the Software and IT hub |
| Construction and field work | Plan around site conditions, weather, and crews; test on one area or one crew; see the construction hub |
| Public service | Define the customer outcome, test on one office or one service channel, and involve front-line staff; see the government hub |
| Safety-critical or regulated processes | Involve quality, safety, and regulatory owners in the plan; follow change control; test in a controlled setting |
| Personal or team habits | Use a simple form: what I will try, what I expect, how I will know; start with a short test |
Scale the planning to the risk. A low-risk, reversible test needs a short plan. A test that affects safety, customers, or regulated product needs review and approval before it starts.
| Mistake | What it looks like | How to correct it |
|---|---|---|
| Jumping to a solution | The plan starts with the fix and the problem is described afterwards | State the problem and verify the cause first |
| No baseline | No one knows what “better” means in numbers | Collect a short baseline before the test |
| Vague problem statement | “Quality is not good enough” | Use numbers, place, and time |
| Relying on opinion | Causes come from the meeting room and not the workplace | Go and see; use data |
| No prediction | The team cannot say what they expect | Write a numeric prediction and a reason |
| Testing too much at once | Several changes are tested together | Test one change at a time where possible |
| Test too large | A full rollout labeled as a test | Start small and increase the scale |
| Over-planning | Months of analysis before any test | Plan enough to test safely and learn |
| Leaving out the people | The team is surprised on the first day | Brief and involve them in planning |
| No data plan | Nobody knows who records the results | Assign collection and design the form |
Match it to the size of the problem. For a small, local cycle, planning can take a few hours to a few days: go and see, collect a little data, agree the target, and write down the test. For a larger problem it can take a few weeks. If planning drags on for months, the problem is probably too big for one cycle, or the team is trying to remove all uncertainty before testing. The purpose of the cycle is to learn, so plan enough to run a safe and informative test, and no more.
The steps are the same: plan, do, study or check, and act. W. Edwards Deming later preferred “Study” to “Check” because “check” can suggest simple inspection, while “study” stresses learning from the results by comparing them with the prediction. Healthcare improvement work tends to use PDSA, and manufacturing and ISO management system language tends to use PDCA. Use the term your organization uses, and keep the learning intent.
A prediction turns a trial into an experiment. If you state in advance what you expect and why, the results either support your understanding or show that it is wrong, and both outcomes teach you something. Without a prediction, it is easy to explain any result afterwards and learn nothing. The prediction also forces the team to say which cause they think matters and how much of the problem it explains.
Small enough that if it fails, little is lost, and large enough to give a clear answer to the question. Many cycles begin with one person, one shift, one station, or one customer, and run for a day or a week. Increase the scale in later cycles as the evidence builds and as confidence in the change grows. Small tests are also faster, so the team can learn more in the same time.
Not always. For a quick, low-risk test, a run chart of frequent measurements is often enough. When the decision is costly or the effect is small compared with the variation, plan the sample size so that the test can detect the difference that matters. State the minimum change you would treat as an improvement, and use the sample size calculator on this site if needed.
Test a hypothesis about it. Plan a small cycle whose purpose is to learn about the cause, such as comparing two conditions, observing at a different time, or collecting data that you do not yet have. PDCA does not require certainty about the cause before testing a change. It requires a reasoned theory, a prediction, and a safe way to find out whether the theory is right.
This content is educational. The example data and results are illustrative. Follow your organization's quality system, change control, and safety requirements.
Step 2 of 4
Can we run the test as planned and record what happens? Do carries out the plan on a small scale. The team makes the change as designed, collects the data it planned to collect, watches what happens, and records what went differently from the plan. The aim is to bring back good information, whatever the result.
Do is where the plan meets the real work. It is also the step where plans most often drift: people adjust the change to fit the situation, data collection slips when the work gets busy, and surprises go unrecorded. The discipline of Do is to carry out the test as designed and to record honestly what happened.
Walk through the plan with the people who will carry out the change: what is changing, why, for how long, and what they are asked to record. Confirm that they know the stop rules and who to call.
Have everything in place before the start: equipment, labels, work instructions, check sheets, and any signage. Test the data collection method itself.
Make the change, in the planned scope, for the planned period. Hold the method steady so that the results can be traced to it.
Be there, especially at the start. Watch how the new method works in practice, and ask the people what they notice. Observation catches what data cannot.
Collect the outcome, process, and balancing measures using the method and the definitions in the plan, at the time events happen.
Write down everything that differed from the plan, everything that surprised the team, and every idea for improving the change. Date each entry.
At the end of the planned period, stop the test or return to the old method as the plan says. Collect the records, check them for completeness, and store them where the team can use them.
Most of the problems in Do can be prevented by preparation. A short briefing and a ready workplace make the difference between a clean test and a messy one.
| Item | What to check | Who |
|---|---|---|
| Briefing | Everyone in scope understands what changes, why, for how long, and what to record; every shift is covered | Cycle owner |
| Method | The new method is written down, short, and visible at the workplace | Cycle owner and team lead |
| Materials and equipment | Everything needed is available, working, and tested (for example, totes, markers, labels, scanners) | Team lead |
| Data method | Check sheet, tally, or automatic data capture is ready and tried out | Data owner |
| Stop rules and rollback | People know the stop criteria and how to return to the old method | Cycle owner |
| Escalation | Everyone knows whom to call with a problem and how to reach them | Cycle owner |
| Observer | Someone is assigned to watch the start and to be available during the test | Cycle owner |
Brief for understanding and not only for compliance. People who understand why the change is being tested notice more, record better, and are more likely to raise problems. A useful briefing covers the problem in numbers, what the team believes causes it, what the change is, what the prediction is, and what is asked of each person.
Use the Gemba Walk Checklist to structure observation, the PDCA Learning Workbook to keep the record, and the Lean Standard Work Template to write the method for the test.
The value of a test depends on how faithfully it follows the plan. People often adapt the change because they want it to work, or because the situation is different from what the plan assumed. Both are understandable, and both need to be handled openly.
| Situation | What to do | Why |
|---|---|---|
| The method is not working as expected, but nobody is harmed | Continue; record what happens and what people notice | A failed prediction is information; changing the method midway removes it |
| A person adapts the method to cope with a problem | Record what they changed and why; ask whether to include it in the next cycle | Workarounds reveal gaps in the design |
| An unexpected condition arises (equipment failure, staff shortage, a rush order) | Note it with the time; flag the affected data | The data may need to be treated separately in Check |
| A safety, quality, or customer risk appears | Stop the test; make the situation safe; escalate; decide with the owner | Protecting people and customers comes before learning |
| A better idea occurs to someone | Write it in the learning log for the next cycle | Testing two methods at once confuses the result |
| The change is clearly causing harm | Apply the rollback in the plan and record the evidence | A stop is a valid result of a test |
| Someone wants to stop early because it is going well | Continue to the end of the planned period unless the stop criteria apply | Early success can be chance |
The way the test is arranged determines how much the result can be trusted. The plan chose one of these; Do carries it out. Each has strengths and limits, and the simplest one that answers the question is usually the best.
| Test style | How it works | Strength | Limit |
|---|---|---|---|
| Before and after | Measure the baseline, make the change, measure again | Simple; needs no extra capacity | Other changes over time can be mistaken for the effect of the change |
| Side by side | One group uses the new method while a similar group keeps the old one | Compares under the same conditions at the same time | Needs two similar groups; groups may differ in other ways |
| Alternating | Switch between old and new method by day or by shift | Reduces the effect of trends | Needs a method that is easy to switch; can confuse people |
| Stepped | Introduce the change to one area at a time and watch each | Shows the effect at each step; lowers risk | Takes longer |
| Dry run or simulation | Practice the method without live work | Finds problems before real work is affected | May not show real conditions |
| Pilot area | Full method in one area for a defined period | Realistic; builds evidence for wider use | Larger and slower than a small test |
For the Station 2 example, the first cycle used a before-and-after comparison over five working days, because the station was the only one with the problem pattern, and the baseline was well documented. Later cycles can compare Station 2 with another station that is not yet using the change. See the Model for Improvement and PDSA guide and the Design of Experiments guide for more rigorous comparisons.
Data show what happened. Observation shows why. A few minutes at the workplace during the first uses of a change often reveal more than a week of data.
| Look for | Questions to ask | What it may reveal |
|---|---|---|
| Is the method followed? | Do people do each step as designed? | Steps that are unclear or skipped |
| Where is the effort? | What takes longer, or feels awkward? | Side effects on time and workload |
| Where do people work around it? | What did they do instead, and why? | A gap in the design or a hidden cause |
| What surprises you? | What did you not expect? | Wrong assumptions in the theory |
| What do people say? | What would you change? What works well? | Ideas for the next cycle; acceptance |
| What is happening around the change? | What else changed this week (staff, volume, product, equipment)? | Other influences to consider in Check |
See the Gemba Walk guide for observation technique.
Collect exactly what the plan says, in the way the plan says, so that the test data can be compared with the baseline. Record at the time events happen, using the simplest method that works.
| Method | Good for | Tips |
|---|---|---|
| Tally or check sheet | Counts of events and defects | A simple form at the workplace; one mark per event; totals at set times |
| Automatic data (scanner logs, system time stamps) | Times, counts, and compliance | Cheapest and least biased; check that the data are captured |
| Observation record | How the method is carried out | Short, structured notes with times |
| Sample inspection | Quality characteristics | Use a defined sample and inspect in the same way each time |
| Short feedback question | Opinions and ease of use | One or two questions; same wording for everyone |
Look, but do not decide. It is natural to look at results during the test, and useful for spotting problems. The temptation is to draw a conclusion from a few points. Leave the decision to the Check step, with the full data and the prediction in front of the team. Use the SPC Control Chart Data Sheet for time-ordered data, and see Data Collection Plan.
A short log kept during the test is what makes the Check step possible. Without it, the team has numbers and no explanation. Keep it simple: a page on a clipboard or a shared sheet that anyone can add to.
| Date and time | Type | Entry (example from Cycle 1) |
|---|---|---|
| Day 1, 07:00 | Observation | Packers asked how to cover the wait for a label; the order-in-progress tote was in use from the first order |
| Day 2, 10:15 | Deviation | A rush order arrived and the supervisor allowed two open orders for 35 minutes on one shift; 12 orders flagged |
| Day 2, 14:00 | Surprise | Two labels came out of the printer stuck together; with only one box open, the packer noticed before applying either |
| Day 3, 09:30 | Idea | A packer suggested printing the label when the order is scanned, so labels cannot get out of sequence; logged for the next cycle |
| Day 4, 16:00 | Observation | Two of the six errors were address data errors; the change could not affect them |
| Day 5, 15:00 | Data note | Average pack time for the week: 101 seconds, against a baseline of 94 seconds |
Keep ideas separate. The idea on day 3 became the Cycle 2 hypothesis. It was written in the log and not tried during Cycle 1, so the result of Cycle 1 stayed clean.
A test is a controlled risk. The plan sets the limits; Do respects them. Stopping a test that is causing harm is a correct and valuable result.
| Condition | Action | Who decides |
|---|---|---|
| A safety hazard appears | Stop the test immediately, make the area safe, and report | Anyone; the cycle owner confirms |
| A defect or error could reach a customer | Stop; contain the product; investigate | Cycle owner, with quality |
| The measure moves clearly in the wrong direction against the stop rule | Return to the previous method; record the evidence | Cycle owner |
| A key person or piece of equipment is unavailable | Pause or adjust; record the deviation | Cycle owner |
| The test is affecting service or output beyond the agreed limit | Apply the rollback; decide whether to retry | Cycle owner and supervisor |
The test is carried out by people, and their experience of it matters. A change that is imposed will be followed less well than one that people understand and have helped design.
| Do | Avoid |
|---|---|
| Explain the purpose and the prediction | Presenting the test as a way of checking up on people |
| Ask for their observations and ideas | Defending the change when it meets problems |
| Respond quickly to problems and questions | Leaving people alone with an unclear method |
| Share the results as they come in | Keeping the data away from the people who produce it |
| Thank people and recognize contributions | Taking the credit for the learning |
| Accept that a failed test is a result | Treating a failed prediction as someone’s fault |
Remember that observation changes behavior. People work differently when they know they are being watched. Observe long enough that the effect fades, use data that the process generates by itself where you can, and be honest in the log when observers were present. See Change Management for Improvement, Resistance to Change, and Training Reinforcement and Knowledge Transfer.
The test ran for five working days on all three shifts, with about 250 shipments a day. The change was a rule of one order open at a time, with an order-in-progress tote marking the active order; the next order is pulled only after the box is closed and labeled.
| Day | Shipments | Mislabels | Rate | Notes from the log |
|---|---|---|---|---|
| 1 | 250 | 6 | 2.4% | Start-up questions; all packers used the tote from the first order |
| 2 | 250 | 5 | 2.0% | Rush order: two open orders allowed for 35 minutes on one shift; 12 orders flagged |
| 3 | 250 | 5 | 2.0% | Idea from a packer: print the label when the order is scanned |
| 4 | 250 | 6 | 2.4% | Two of the six errors were address data errors, which this change cannot affect |
| 5 | 250 | 5 | 2.0% | Pack time averaged 101 seconds for the week, against 94 seconds at baseline |
| Total | 1,250 | 27 | 2.16% | Baseline 3.10% (149 of 4,800); prediction was about 2.2% |
The test was closed on the afternoon of day 5, the records were collected, and the team moved to the Check step.
Before starting the Check step, the cycle owner confirms that the test is complete and the information is ready to study. Use the checklist; progress saves in this browser only, and nothing is sent anywhere.
Questions a cycle owner or a coach can ask:
| Outcome | Meaning | Next step |
|---|---|---|
| Complete | Test ran as planned and the data are sufficient | Start the Check step |
| Complete with gaps | Minor deviations or missing data that can be explained | Note the limits and go to Check |
| Incomplete | The test did not run as planned or the data cannot answer the question | Fix the problem and repeat the test, or revise the plan |
| Stopped early | A stop criterion was met | Record why; go to Check to learn from what was gathered |
| Situation | How Do changes |
|---|---|
| Manufacturing line | Run the test on one line, shift, or machine; use machine data and a check sheet; protect product quality; involve the operators and maintenance |
| Service and transactional work | Test with a small set of cases or one team; use time stamps and sample audits; protect customer service levels; see the finance and accounting hub |
| Healthcare | Test with one patient, one clinician, or one clinic session; protect safety; follow the PDSA approach; see the healthcare hub |
| Software and IT | Use a feature flag, a staged release, or a canary group; monitor automatically; keep a quick rollback; see the Software and IT hub |
| Construction and field work | Test on one crew or one work area; adapt to weather and site conditions; record the conditions; see the construction hub |
| Public service | Test in one office or one channel; track service standards; involve front-line staff; see the government hub |
| Regulated or safety-critical processes | Run the test under change control, with approvals and documented records; involve quality and regulatory owners |
| Personal or team habits | Try the new habit for a short, defined period; record what happens each day in a simple log |
Scale the formality to the risk. A low-risk test may need only a tally and a note. A test that touches safety, regulated product, or customers needs documented approval, records, and a controlled rollback.
| Mistake | What it looks like | How to correct it |
|---|---|---|
| Changing the method mid-test | The change differs from day to day | Hold it steady; log ideas for the next cycle |
| Not briefing every shift | Night shift learns about the test from the day shift | Brief all shifts before the start |
| Data collected from memory | Counts are filled in at the end of the week | Record at the time, using a form or automatic data |
| Changing the definitions | What counts as an error shifts during the test | Use the written operational definition |
| Ignoring balancing measures | Only the outcome is tracked | Track the side effects from the plan |
| Deciding early | The test is called a success after two days | Run to the planned end unless a stop rule applies |
| Hiding deviations | The record shows a perfect test | Log every deviation; they explain the data |
| Blaming people | Failures are attributed to operators | Look for the cause in the method and the conditions |
| Scaling up too soon | A good first day leads to rollout | Increase scale only after the Check step |
| No record of the learning | Insights stay in people’s heads | Keep the learning log and share it |
Write it down and keep running the test as planned. Changing the method in the middle makes the results impossible to interpret, because you will not know which version produced which result. Put the idea in the learning log and use it in the next cycle. The exception is a safety or customer risk, where you stop the test, make things safe, and then decide how to proceed.
Keep collecting data to the end of the planned period unless a stop criterion has been met. Early results are noisy, and a few good days can disappear, while a few bad days can be chance. Looking at the data is fine and often useful; making decisions from partial data is the problem. Agree in the plan what would cause an early stop, and follow that rule.
You cannot remove the effect, but you can reduce and account for it. Observe for long enough that people return to their normal way of working, use data that the process produces by itself (such as scanner logs) in addition to observation, and make clear that the purpose is to test the change and not to judge the people. Note in the log when observers were present.
Preferably the people who do the work, using a simple method that fits into the work, supported by automatic data where it exists. An independent observer is useful for checking that the method is followed and for noting what the data do not show. Avoid data collection that adds so much work that it changes the process being tested.
Record what happened and why, decide whether the data that you have can still answer the question, and either adjust the plan and restart, or continue and note the limits. A test that did not run as planned is still a source of learning, because the reasons often reveal practical barriers that the plan missed. Do not describe it as complete if it was not.
Long enough to give enough data to answer the question, and to cover the normal variation in the work, such as different shifts, products, and days of the week. The plan sets the period. If the effect is large and the data are frequent, a few days can be enough. If the events are rare, the test needs to run longer or the measure needs to change.
This content is educational. The example data and results are illustrative. Follow your organization's quality system, change control, and safety requirements.
Step 3 of 4
What happened, and how does it compare with what we predicted? Check is where the team studies the results of the test. It compares the data with the baseline and with the prediction, looks for side effects and other explanations, and decides what was learned. Done well, Check turns a test into knowledge, whether the change worked or not.
Check closes the learning loop. The team asks whether the change did what the theory said it would do, how much, and how sure it can be. It is also the step that is most often skipped or rushed: teams run a test, see that the numbers look better, and move straight to rollout. The result of that shortcut is changes that were not understood and that fail when the conditions change.
Compare the record from Do with the plan. List every difference, and decide how much each one could have affected the result.
Collect the data from every source, check them for gaps and errors, and annotate flagged values. Use the same definitions as the baseline.
Plot the measure as a run chart, with the baseline before the change, and mark when the change was made. Look for shifts, trends, and unusual points before calculating anything.
Set the result beside the baseline and beside what was predicted. A result that matches the prediction supports the theory. A result that does not is the most useful kind of data.
State the size of the change and how sure you can be, with a confidence interval or a statistical test if the decision justifies it.
Check the balancing measures. Then ask what else could explain the result: other changes, the time period, a different mix of work, or the effect of being observed.
State what the team now knows that it did not know before, whether the theory held, and what the evidence supports: adopt, adapt, or abandon. Record the reasoning.
Before looking at the results, check what was tested. A change that was only partly carried out cannot be fairly judged, and a change that was altered during the test may not be the one the team thinks it tested.
| Question | Where the answer is | Why it matters |
|---|---|---|
| Was the change made as described? | Observation notes; process measure | Low compliance may explain a poor result |
| Was the scope and period as planned? | Learning log; dates | A shorter or smaller test gives less evidence |
| Were the data collected as planned, with the same definitions? | Data records; data plan | Different definitions make comparison invalid |
| What deviations happened, and how large were they? | Learning log | Some can be ignored; some change the conclusion |
| What else changed at the same time? | Observations; supervisors; calendar | Other changes can be mistaken for the effect |
Test the conclusion against the deviations. If part of the data came from a period when the method was not followed, compare the result with and without that part. If the conclusion does not change, it is robust to the deviation; if it does, say so.
Good analysis starts with clean, comparable data. A short time spent here avoids false conclusions.
| Task | What to do | Example (Cycle 1) |
|---|---|---|
| Compile | Bring together all sources: tallies, system data, observation notes | Daily tally sheets, the shipment count from the system, and the supervisor observations |
| Check the denominators | Make sure each count has the right base | 250 shipments a day for five days: 1,250 in total |
| Check the definitions | Confirm the counting rule matches the baseline | A mislabel is a shipment whose label does not match the packed order, as in the baseline |
| Annotate flagged data | Mark deviations and unusual values | Day 2: 12 orders handled with two orders open during a rush |
| Run a sensitivity check | Compare the result with and without flagged data | With day 2 removed: 22 of 1,000 shipments, 2.2%, against 2.16% with it |
| Prepare the baseline | Use a comparable baseline, as long as the test where possible | Four weeks: 149 of 4,800 shipments (3.10%), plotted by day |
Keep the raw data. Anyone should be able to see how the result was calculated. Use the SPC Control Chart Data Sheet and the PDCA Learning Workbook to hold the data and the analysis together.
A run chart plots the measure in time order. It is the most useful tool in Check, because it shows the baseline, the moment of the change, and the pattern afterwards in one picture, and it needs no statistics.
| Run chart rule | Signal | What it suggests |
|---|---|---|
| Shift | Six or more consecutive points all above, or all below, the median (points on the median are skipped) | The process has moved to a new level |
| Trend | Five or more consecutive points all rising or all falling | A gradual change |
| Too many or too few runs | The number of times the line crosses the median is outside the expected range | Non-random patterns such as cycles or mixtures |
| Astronomical point | A value that is clearly different from all the others | A special event worth investigating |
Reading the example. In Cycle 1 alone, five points sit below the baseline median: one short of the six needed to signal a shift, so the run chart alone could not confirm the change. After Cycle 2, ten consecutive points are below the median and the rule is met. The chart also shows that Cycle 2 moved the rate much further than Cycle 1.
Two comparisons matter. The comparison with the baseline shows whether things improved. The comparison with the prediction shows whether the team’s understanding was right.
| Measure | Baseline | Prediction | Result | Reading |
|---|---|---|---|---|
| Cycle 1: mislabel rate | 3.10% | About 2.2% | 2.16% | Matches the prediction |
| Cycle 1: pack time | 94 s | +5 to +10 s | 101 s (+7 s) | Within the predicted range |
| Cycle 1: one-order compliance | Not applicable | High | 94% of observed orders | Good; the exception was the rush period |
| Cycle 2: mislabel rate | 3.10% | About 0.8% | 0.85% | Close to the prediction |
| Cycle 2: pack time | 94 s | Back close to baseline | 96 s | As predicted; the stack handling is gone |
What a match tells you. When the result matches a numeric prediction that was made in advance, the theory behind the prediction gains support. In Cycle 1 the prediction followed from the cause analysis: the cause explained 29% of errors, and removing it moved the rate from 3.10% to about 2.2%. That the observed rate was 2.16% supports the cause analysis, but does not prove it, as chance could also produce it.
What a mismatch tells you. If the result had been 3.0% in Cycle 1, the team would have asked: was the change carried out, was the cause analysis wrong, or did something else worsen it? Each answer leads to a different next step. A wrong prediction is a prompt to look harder, not a failure.
A difference between a baseline and a test can come from the change, or from chance variation. A confidence interval shows the range of values consistent with the data; a significance test asks whether chance alone could plausibly produce the difference.
| Comparison | Difference | 95% confidence interval | Test result | Reading |
|---|---|---|---|---|
| Cycle 1 against baseline (27 of 1,250 against 149 of 4,800) | 0.94 points lower | 0.0 to 1.9 points | z = 1.77, p = 0.08 | Consistent with the prediction; not conclusive on its own |
| Cycle 2 against baseline (11 of 1,300 against 149 of 4,800) | 2.26 points lower | 1.6 to 3.0 points | z = 4.52, p < 0.0001 | Strong evidence of improvement |
| Cycle 2 against Cycle 1 | 1.31 points lower | 0.4 to 2.3 points | z = 2.74, p = 0.006 | Print-on-scan did better than the one-order rule alone |
| Cycle 1 with day 2 removed (22 of 1,000) | 0.90 points lower | −0.1 to 1.9 points | z = 1.54, p = 0.12 | Same picture without the flagged day |
Use the Hypothesis Testing Quick Tester for the calculation, the Sample Size and Confidence Calculator to size the next test, and the Standard Deviation Calculator for measurement data.
An improvement in one measure is not a success if it makes another worse. The balancing measures from the plan are there to show the cost of the change.
| Balancing measure | Baseline | Cycle 1 | Cycle 2 | Reading |
|---|---|---|---|---|
| Pack time per shipment | 94 s | 101 s | 96 s | Cycle 1 added 7 seconds; Cycle 2 removed most of it |
| Backlog at the end of the shift | Under 10 minutes | Under 15 minutes | Under 10 minutes | Within the limit of 30 minutes |
| Packer comments | Not recorded | Waiting for labels is frustrating | Prefer the new method | Supports adopting Cycle 2 |
| Residual error causes | Stack 41%, two open 29%, tray 14%, address 9%, other 7% | Stack, tray, address, other | Address 4, other 3, stack 2, tray 2 (of 11) | Address data is now the largest remaining cause |
A change followed by an improvement does not prove the change caused it. Other things may have happened at the same time. How much effort to spend checking depends on the cost of being wrong.
| Alternative explanation | How to check | In the example |
|---|---|---|
| Something else changed at the same time | Ask supervisors and check the calendar; compare with a similar area | No staffing, product, or system change in the five days |
| Normal variation (chance) | Run chart rules; confidence interval; longer test | Cycle 1 alone was inconclusive; Cycle 2 repeated and extended the evidence |
| Regression to the mean (the baseline was unusually bad) | Check a longer baseline; compare with earlier periods | The rate had been 1.8% the previous quarter, so the baseline period was high, and 3.1% was not the usual level; the final result is below both |
| Different mix of work or volume | Compare volumes and products in the baseline and the test | Daily volumes were within 10% of the baseline |
| Measurement or definition changed | Compare the counting method and the people counting | Same definition and the same station lead |
| The effect of being observed | Use data the process generates by itself; observe for longer | Mislabels come from audit and customer data, not only from observers |
| The mechanism was not the one predicted | Check that the cause that was removed accounts for the improvement | Errors from stacked labels fell, as predicted |
Five questions that strengthen a claim of cause: Did the improvement follow the change in time? Is the size of the effect consistent with the size of the change? Does a mechanism explain it, and was that mechanism observed? Was it repeated in a second test or a second place? Did a comparison group that did not change stay the same?
Where the stakes are high, plan a stronger design in the next cycle: a comparison group, alternating the change on and off, or a replicate. See the Design of Experiments guide.
The purpose of Check is learning. The team should write down what it now knows, how that differs from what it believed before, and what it does not yet know.
| Question | Cycle 1 answer | Cycle 2 answer |
|---|---|---|
| Did the result match the prediction? | Yes: 2.16% against about 2.2% | Approximately: 0.85% against about 0.8% |
| Was the theory right? | Partly: the two-orders-open cause was real and explained about a third of errors | Yes: batch stack and tray errors were removed, with some residual |
| What surprised us? | Labels stuck together in the printer; waiting for the batch printer was the main complaint | Address data errors are now the largest cause; staff preferred the new method |
| What are the side effects? | Pack time +7 s | Pack time +2 s against baseline |
| How sure are we? | Moderate; the interval includes no effect | Strong; repeated, with a clear interval and a mechanism |
| What do we still not know? | Whether the one-order rule matters once printing is fixed | Whether the result holds at other stations and at peak volume |
Capture the analysis in the PDCA Learning Workbook or on an A3. See Lessons Learned Process.
Check ends with a recommendation for the Act step. The evidence and the size of the effect together point to the likely decision.
| Conclusion | What the evidence shows | Typical recommendation |
|---|---|---|
| The change worked as predicted | Result matches the prediction, evidence is strong, side effects are acceptable | Adopt: standardize and plan the spread |
| The change worked, but not enough | Real improvement short of the target | Adapt: strengthen the change or add a second change, then run another cycle |
| The change worked in some conditions | Result depends on shift, product, or place | Adapt: modify for the conditions or limit the scope |
| The evidence is unclear | Interval is wide; the run chart is inconclusive | Extend or repeat the test |
| The change did not work | No improvement, or worse, with sound data | Abandon: record the learning; try a different change |
| The change caused harm | A balancing measure worsened beyond the limit | Stop; revert; revise the theory |
The Station 2 team held a Check meeting after each cycle, with the data, the learning log, and the prediction on the table.
| Check after Cycle 1 | Check after Cycle 2 | |
|---|---|---|
| What was tested | One order open at a time, with an order-in-progress tote | Print the label when the order is scanned at the station, keeping the one-order rule |
| Run as planned? | Yes, apart from a 35-minute rush period on day 2 | Yes; no deviations of note |
| Result | 27 of 1,250 (2.16%) against a baseline of 3.10% | 11 of 1,300 (0.85%) against a baseline of 3.10% |
| Prediction | About 2.2% | About 0.8% |
| Evidence | Run chart: five points below the median; interval 0.0 to 1.9 points; sample too small to be conclusive | Run chart: ten points below the median; interval 1.6 to 3.0 points; repeat of the direction seen in Cycle 1 |
| Side effects | Pack time +7 s, as predicted | Pack time +2 s against baseline |
| Learning | The cause was real but only a third of the problem; batch printing was the larger problem | Print-on-scan removed most stack and tray errors; address data is the largest remaining cause |
| Recommendation | Adapt: keep the rule and run Cycle 2 on the batch printing | Adopt: standardize at Station 2, then spread; plan a cycle for address data |
The Cycle 1 result was close to the prediction, which gave the team confidence in its cause analysis. Because the sample was small, the team did not adopt the change on that evidence alone. They moved on to the more promising change, using what they had learned.
Before the Act step, the cycle owner confirms that the team understands the result well enough to decide. Use the checklist; progress saves in this browser only, and nothing is sent anywhere.
Questions a cycle owner or a coach can ask:
| Outcome | Meaning | Next step |
|---|---|---|
| Ready for Act | Result understood; recommendation is supported by the evidence | Start the Act step |
| Needs more data | Evidence is too weak to decide | Extend or repeat the test |
| Needs a better explanation | The result is not understood | Observe, interview, and revise the theory before deciding |
| Wrong question | The measure or the test did not address the problem | Revise the plan and run a new cycle |
| Situation | How Check changes |
|---|---|
| Manufacturing line | Run charts and control charts of defect rates and cycle times; compare machines and shifts; use capability data for measurements |
| Service and transactional work | Run charts of turnaround and error rates; sample audits; check effects on workload; see the finance and accounting hub |
| Healthcare | Run charts with the standard rules; track balancing measures such as time and patient experience; protect safety in the review; see the healthcare hub |
| Software and IT | Compare metrics before and after, or between a canary and a control group; watch error rates and performance; see the Software and IT hub |
| Construction and field work | Compare crews, areas, or periods; allow for weather and site conditions; see the construction hub |
| Public service | Check against service standards; use front-line feedback; see the government hub |
| Small samples or rare events | Use time-between-events charts, longer test periods, and case review; avoid conclusions from a few events |
| Personal or team habits | Review a simple log after a short trial: what happened, what I expected, what I learned |
Scale the rigor to the decision. A cheap, reversible change can be judged on a run chart and a conversation. A change with safety, regulatory, or large cost implications needs a stronger design, a formal analysis, and review by the people responsible.
| Mistake | What it looks like | How to correct it |
|---|---|---|
| Comparing only with the baseline | Success means “better than before” | Compare with the prediction as well |
| Declaring success from two numbers | A before and after average is the whole analysis | Plot the data in time order and apply the rules |
| Treating a p-value as the answer | “It is significant, so adopt it” | Report the size, the interval, and the practical importance |
| Treating no significance as no effect | “It did not work” after a small test | Look at the interval; extend or repeat the test |
| Ignoring the balancing measures | The outcome improved while time or cost rose | Review every measure from the plan |
| Crediting the change for everything | Other changes are not considered | List what else changed; use a comparison group |
| Deleting awkward data | Outliers vanish from the chart | Keep and annotate; test the sensitivity |
| Hiding a failed prediction | The theory is defended, not tested | Treat a miss as the most useful result |
| Using control limits to judge a change | Limits too wide to see the effect | Use run chart rules to judge change |
| No written conclusion | The learning stays in the meeting | Document the result and the reasoning |
At least 10 to 15 points to start to see patterns, and more is better. The rules for detecting a shift or a trend need runs of five or six points, so a chart with fewer than that cannot show them. If the test is short, include the baseline data before the change so that there are enough points on the chart, and mark where the change was made.
It means the data do not rule out chance as an explanation at the chosen risk level, not that the change did nothing. Look at the size of the difference and its confidence interval, the pattern in the run chart, and whether the mechanism was observed. Often the right response is a longer or repeated test. A small test with a large difference can be a good reason to continue, and a large test with no difference is a good reason to stop.
That is valuable learning, and it also means the theory needs to be revised before the change is spread. The result may have come from a different cause or an unplanned side effect, and a change that works for the wrong reason may fail somewhere else. Go back to the observations and the log to understand why, and adjust the next hypothesis.
No. For a quick, low-risk test, a run chart and the prediction are often enough. Use a formal test when the decision is costly, when the effect is small compared with the variation, or when others will need convincing. A confidence interval is usually more informative than a p-value because it shows the range of plausible effects.
A worse result is still a result. Check that the test was run as planned and that the data are sound. Then study why the prediction was wrong: the cause may be different from the theory, the change may have had a side effect, or the conditions may have changed. Record the learning, stop the change if the plan says so, and plan a different cycle.
Keep them, mark them, and test whether the conclusion depends on them. Compare the result with and without the flagged data, and report both if they differ. Do not delete a value only because it spoils the picture. If a value is clearly an error, such as a recording mistake, correct it and say so in the record.
This content is educational. The example data and results are illustrative. Follow your organization's quality system, change control, and safety requirements.
Step 4 of 4
What will we do with what we learned? Act turns learning into action. The team decides whether to adopt the change, adapt it, or abandon it. It standardizes what works, spreads it carefully, puts controls in place so it lasts, records the lessons, and uses what it learned to plan the next cycle.
Without Act, a PDCA cycle is only an experiment. Act is the step that makes the learning count: a change that worked becomes the way of working, a change that almost worked is improved, and a change that failed is put aside with the lesson recorded. It is also where the cycle closes into a loop, because the findings of one cycle become the starting point of the next.
Use the evidence and the learning from Check to decide, with the process owner and the people who can approve the standard. Record the reasons.
Change the standard method so the improvement is the normal way of working. Strengthen it with prevention built into equipment or systems.
Make sure everyone who does the work knows the new method and why it changed, on every shift, including new and temporary staff.
Extend the change to other people, places, or products step by step. Check at each stage that the causes and conditions are similar, and adapt where they are not.
Monitor the measure, define what counts as a signal, and agree what happens when one appears. Give someone ownership.
Write down what was done, what was found, and what was learned, including what did not work. Store it where others will find it.
Use what the cycle revealed: the largest remaining cause, an open question, a new problem. Decide whether to continue, and begin the next Plan step.
The decision follows from the evidence in Check, and it should be made openly, with the reasons written down. All three outcomes are legitimate and all produce learning.
| Decision | When the evidence says | What happens next | What to record |
|---|---|---|---|
| Adopt | The result matches or beats the prediction, is large enough to matter, and the evidence is strong with acceptable side effects | Standardize, train, spread, and sustain | What was adopted, the evidence, the owner, the date |
| Adapt | The change helps but not enough, works only in some conditions, or has a side effect that needs fixing | Modify the change or combine it with another, and run another cycle | What will change, the new hypothesis and prediction |
| Abandon | No improvement, or harm, with sound data and a well-run test | Stop the change and return to the earlier method if needed; try a different idea | What was tested, why it did not work, what was learned |
| Extend the test | The evidence is too weak to decide | Collect more data, repeat the test, or make the comparison stronger | Why it was inconclusive and what will be added |
Standardizing makes the improved method the normal way of working. A change that is not written into the standard will drift back to the old way, usually within weeks.
| Element | What to do | Check |
|---|---|---|
| Standard operating procedure and work instruction | Update to the new method; keep it short, visual, and written with the people who do the work | Users agree it matches what they do |
| Standard work | Document the sequence, time, and key points; see the Standard Work guide | Observed at the workplace |
| Built-in prevention | Change equipment, software, or layout so the error is hard to make; see Mistake-Proofing | The old error cannot occur, or shows at once |
| Visual management | Make the standard visible: markers, boards, limits; see Visual Management | A new person can see what normal looks like |
| Workplace organization | Keep tools and materials in place with 5S | Audits show it is kept |
| Settings and configuration | Lock or control the settings that the change depends on | Only the owner can change them; changes are logged |
| Document and change control | Retire old versions; route future changes through change control; see the Management of Change Register | Only the current version is in use |
Use the Lean Standard Work Template and the Standard Work Combination Chart to document the method. In certified or regulated environments, follow your quality management system’s document control, change control, and training requirements.
A standard is only as good as the people who follow it. Training and communication make sure that everyone knows the method, understands the reason, and can do it.
| Audience | What they need | How |
|---|---|---|
| People who do the work | The method, the reason for it, and practice | Train on the real task; use the test team as coaches; verify competence |
| New and temporary staff | The method on arrival | Include it in onboarding and the skills matrix |
| Supervisors and leaders | What to look for and how to respond to a signal | Brief on the standard, the measure, and the reaction plan |
| Other areas affected | What changes at the handoffs | Brief the neighbors before the change reaches them |
| The sponsor and the wider organization | The result and the learning | Share a short summary; recognize the team |
See Train-the-Trainer Programs, Training Reinforcement and Knowledge Transfer, Competency and Training Effectiveness, the Skills Training Matrix, and Change Management for Improvement.
A change that works in one place does not always work in another. Spreading in stages lets the team check each new setting and adapt the change as needed. In lean practice, spreading a proven improvement to other areas is known as horizontal deployment, or yokoten.
| Question for each new area | Why it matters |
|---|---|
| Does the same cause exist there? | A solution for one cause does not help a different one |
| Are the equipment, product, and volume similar? | Differences may need changes to the method |
| Who owns the process there, and are they ready? | A change without an owner will not last |
| What does the team there need to learn or adapt? | They may have ideas that improve the change |
| How will we measure it, and what do we predict? | Each stage should be a test, not an assumption |
See Yokoten (Horizontal Deployment), Continuous Improvement Programs at Scale, and Kaizen Continuous Improvement.
Gains fade when nobody is watching. A small set of controls keeps the improvement in place and shows quickly when something changes.
| Control | What it does | Example (Station 2) |
|---|---|---|
| Measure and chart | Shows the outcome in time order, with limits from stable data | Weekly p chart of mislabels; limits 0.08% to 1.72% |
| Leading indicator | Warns before the outcome moves | Start-of-shift check that the printer is in print-on-scan mode |
| Reaction plan | Says what to do when a signal appears | Contain the shipments of the week, check settings, labels, and tote use, then escalate |
| Audit | Checks that the method is followed | Supervisor observes ten orders a week for a month, then monthly |
| Owner and review routine | Someone looks at the data and responds | Station lead reviews daily; supervisor weekly; manager monthly |
| Spare capacity for the next cycle | Time for further improvement | A monthly 30-minute slot for the team to review the data and choose the next problem |
Apply the plan to the signal. In week 11 the rate rose to 1.9%. The station lead followed the plan: contained the week’s shipments, checked the settings, and found that a printer driver update had reset the printer to batch mode. The team restored print-on-scan, locked the configuration so that only the supervisor can change it, added the setting to the start-of-shift check, and recorded the lesson. The rate returned to 0.9% in week 12.
Choose a chart with the Control Chart Selector and see the SPC Control Charts guide. When the improvement is part of a larger project, the Control tab of the DMAIC Toolbox describes control plans, ownership handover, and benefit tracking in more depth.
The learning is the lasting product of the cycle. A record turns it from a memory into something the organization can use.
| Section | What to include | Example (Station 2) |
|---|---|---|
| Problem and target | The gap, the baseline, and the goal | 3.10% mislabeled; target under 1.0% |
| Theory and prediction | What the team believed and what it predicted | Two orders open (29%): about 2.2%; batch stack and tray (55%): about 0.8% |
| What was tested | The changes, scope, and period | One order at a time; print-on-scan; five days each |
| Results | Data against the baseline and the prediction, with the evidence | 2.16% and 0.85%; intervals and run chart |
| What was learned | Findings, surprises, and revisions to the theory | Batch printing was the main driver; address data is the largest remaining cause |
| Decision | Adopt, adapt, or abandon, and why | Adopt both at Station 2; spread in stages |
| Open questions | What is still unknown | Does the one-order rule matter now that printing is fixed? Does it hold at peak volume? |
| Next steps | Owners, dates, and the next cycle | Spread to Stations 3, 1, and 4; Cycle 3 on address data |
Use the PDCA Learning Workbook or an A3 (see the A3 Problem Solving Builder). See Lessons Learned Process and Sustaining Continuous Improvement.
The end of Act is the beginning of the next Plan. The findings of the cycle show what the largest remaining problem is, and the team can decide whether to continue.
| Question | How to answer it | Example |
|---|---|---|
| What is the largest remaining cause? | A Pareto chart of the remaining problem | Address data errors: 4 of the 11 errors in Cycle 2, the largest share of what remains |
| What is the value of the next improvement? | Remaining gap × volume × cost | About 0.3 points × 62,400 shipments × $27 = about $5,000 a year |
| What does it cost, and what is the risk? | Effort, time, and equipment | Address validation requires a change in the order system |
| Is it the best use of the team’s time? | Compare with other opportunities | Station 4 and the spread to other stations come first |
| Should we stop? | The target is met and has held; the next gain is small | Continue monitoring, and plan Cycle 3 when capacity allows |
A seed for Cycle 3. If the order system checks each address against the carrier database when the order is entered, address-related mislabels should fall by about 70%, from about 0.3 points to 0.1 point, and the overall rate from about 0.9% to about 0.6%. That is the start of the next hypothesis and prediction. See the Plan tab for how to build it.
The same cycle works at every level. The Act step also includes a judgment about whether the problem has outgrown a simple cycle.
| Sign that the problem is bigger than a cycle | What to do |
|---|---|
| Several cycles have not moved the measure | Step back: the cause may not be understood; consider a structured investigation |
| The cause is unknown, or several factors interact | Start a DMAIC project; see the DMAIC Toolbox |
| The process crosses several departments | Charter a project with a sponsor and a cross-functional team |
| Safety, regulatory, or high customer risk is involved | Use formal risk assessment and change control; see CAPA Process Effectiveness |
| The measurement system is in doubt | Study the measurement system first; see Measurement System Analysis |
| The problem needs structured coaching and a one-page record | Use an A3; see A3 Problem Solving |
See Hoshin Kanri and Continuous Improvement Programs at Scale for how organizations coordinate cycles at different levels.
The Station 2 team acted twice: after Cycle 1, and after Cycle 2. The path from the first test to the standard is shown below.
| Step | After Cycle 1 | After Cycle 2 |
|---|---|---|
| Decision | Adapt: keep the one-order rule, add a second change for the batch printing | Adopt: both changes become the standard at Station 2 |
| Standardize | Rule continued during the next cycle | SOP and work instruction updated; printer set to print-on-scan and locked; order-in-progress tote kept; old batch method removed |
| Train | Briefing for the three shifts | 14 packers trained on the real task over two weeks; competence checked; onboarding updated |
| Sustain | Daily tally continued | Weekly p chart; start-of-shift printer check; supervisor audit of ten orders a week; reaction plan posted |
| Spread | None | Station 3 first (similar product), then Stations 1 and 4, with each treated as a mini-test |
| Record | Learning log filed | One-page summary in the cycle workbook, shared at the team meeting |
| Next | Plan Cycle 2 on batch printing | Plan Cycle 3 on address data when capacity allows |
The team met its target, kept the gain through a real disturbance, and finished with a record and a plan for the next cycle.
Before closing the cycle, the cycle owner confirms that the decision is made, the change is standardized, and the learning is recorded. Use the checklist; progress saves in this browser only, and nothing is sent anywhere.
Questions a cycle owner or a coach can ask:
| Outcome | Meaning | Next step |
|---|---|---|
| Closed and standardized | Adopted, trained, monitored, and recorded | Keep monitoring; plan the next cycle |
| Closed with conditions | Minor gaps in training, documents, or monitoring | Record owners and dates; confirm at the next review |
| Looping | The decision was adapt or extend | Start the next Plan with what was learned |
| Escalated | The problem needs a larger approach | Charter a DMAIC project or an A3, carrying forward the data |
| Stopped | Abandoned or target met and held | Record the lessons and the reason |
| Situation | How Act changes |
|---|---|
| Manufacturing line | Update standard work and the control plan; add mistake-proofing and preventive maintenance tasks; run layered audits |
| Service and transactional work | Update checklists, templates, and system rules; sample audits; see the finance and accounting hub |
| Healthcare | Update protocols and order sets; spread unit by unit; keep measuring; see the healthcare hub |
| Software and IT | Make the change permanent through code, configuration, and automated checks; roll out in stages; see the Software and IT hub |
| Construction and field work | Update the method statement and crew briefings; carry the change to the next project; see the construction hub |
| Public service | Update procedures and service standards; spread by office or channel; see the government hub |
| Regulated or safety-critical processes | Use formal change control, validation, and records; involve quality and regulatory owners |
| Personal or team habits | Make the habit part of the routine; set a cue; review after a month |
Scale the controls to the improvement. A small change may need an updated work instruction and a weekly check. A larger change may need a full control plan, charts, audits, and a reaction plan.
| Mistake | What it looks like | How to correct it |
|---|---|---|
| Rolling out on the first success | A small test leads straight to full rollout | Spread in stages and test each stage |
| No change to the standard | The result is announced and the SOP stays the same | Update the documents and remove the old ones |
| Relying on reminders | Signs and memos are the only control | Build prevention in; use standard work and training |
| Training only one shift | Nights and temporary staff are missed | Cover every shift and onboarding |
| No owner or review | Nobody looks at the measure after a month | Assign an owner; set a review routine and a reaction plan |
| Copying without checking | The change is moved to a place with a different cause | Check conditions; treat each stage as a test |
| Using the wrong limits | Specification limits used to judge control | Calculate control limits from stable data |
| No record of what was learned | The next team starts from scratch | Write a short record and share it |
| Abandoning without learning | A failed idea is dropped and forgotten | Record why it did not work |
| Stopping the habit | No next cycle after the target is met | Pick the next problem, or schedule a review |
They have the same purpose, which is to make a proven improvement last, but they differ in scale and formality. Act covers the decision (adopt, adapt, or abandon), the standardization, the spread, and the start of the next cycle, and it can be done in days. DMAIC Control is a formal phase of a larger project, with a control plan, charts, ownership transfer, benefit validation, and closure. A PDCA cycle that grows into a project may use the Control tab of the DMAIC Toolbox for its sustaining controls.
Adopt means the evidence supports the change as tested, so it becomes the standard. Adapt means the change shows promise but needs to be modified or combined with another change, so it goes into another cycle. Abandon means the evidence shows the change does not work or does harm, so the team stops it and tries a different idea. All three are legitimate outcomes, and each produces learning.
When the target is met and has held, or when the value of the next improvement no longer justifies the effort. Compare the expected benefit of the next cycle with its cost and with other opportunities. Keep monitoring after you stop, because performance can slip. Stopping on one problem does not end the habit of improvement: the team can take the next problem.
That is useful information. Compare the conditions: the causes of the problem, the equipment, the product, the people, and the volume. The change may need adapting, or the problem there may have a different cause. Treat the second location as a new test, with its own prediction and measures, and do not assume that a success will transfer.
Make the new way the easy way: build prevention into equipment or systems where possible, update the standard work and the training, make the measure visible, assign an owner, and set a review routine with a defined reaction when the measure moves. Gains that depend on people remembering are the ones that fade first.
No. A well-run test that shows a change does not work has saved the organization from rolling it out, and it has taught the team something about the cause. The waste is a change that is rolled out without a test, or a test whose result is not recorded. Write down what was learned so that the same idea is not tried again without new information.
This content is educational. The example data and results are illustrative. Follow your organization's quality system, change control, and safety requirements.