PDCA Cycle (Plan Do Check Act): Steps, Examples and PDCA vs DMAIC

PDCA Cycle (Plan Do Check Act): Steps, Examples, and PDCA vs. DMAIC

The PDCA cycle (Plan Do Check Act) is a simple, repeatable method of improving a process without jumping in and making changes that might not work. First, a team identifies a problem, proposes a possible solution, tests the results, and then decides whether or not to keep the change or try something else. PDCA is also known as the Deming cycle and is used in manufacturing, healthcare, software development, and quality management. It helps teams to make evidence-based decisions, learn from mistakes, and gradually improve their way of working.

Key Highlights of PDCA Cycle (Plan Do Check Act)

• PDCA stands for Plan, Do, Check, and Act.
• The PDCA cycle means it centers on testing changes, reviewing results, and using what you learn to improve a process.
• Walter Shewhart laid the groundwork for systematic quality improvement, while W. Edwards Deming helped popularize related approaches.
• PDSA stands for Plan, Do, Study, and Act and places greater emphasis on learning from experiments.
• PDCA is useful for smaller improvements, while DMAIC provides a more structured approach to complex quality problems.
• Organizations use PDCA in total quality management, lean management, and quality management systems such as ISO 9001.

Introduction

Think about the last time a problem kept coming back at work. Maybe a customer order was delayed, a machine produced another batch of defective items, or a software team spent a sprint fixing bugs that could have been caught earlier.

Normally, the response is to fix the immediate issue and move on. Someone adds another round of inspection, introduces a new rule, or asks the team to be more careful. The problem disappears for a while, only to show up again a few weeks later.

The difficulty isn't always a lack of effort. Sometimes, the team is treating the symptom without understanding what's causing it.

This is where the PDCA cycle comes in. Instead of jumping straight to a permanent solution, the team takes a step back, looks at the problem, and tests a possible fix on a smaller scale. It then checks whether the change actually helped before deciding what to do next.

The concept is simple: you don't have to get everything right on the first attempt. But you do need to learn from what happens.

That makes PDCA useful for everyday improvements, whether you're trying to reduce production defects, make customer service more efficient, or help a software team deliver more reliably.

What Is the PDCA Cycle?

The PDCA cycle is a four step process for identifying problems, testing solutions, reviewing results and making improvements. There are 4 steps: Plan-Do-Check-Act. Once they have completed them, a team can go through another cycle to address any outstanding issues or look for more improvements.

A practical definition of PDCA is a formalized way of testing if a change works before it is added to the regular process.

Here is a simple example. A warehouse keeps sending out the wrong items to customers. Management is looking at adding another inspection before shipping, but this could make every order slower. Instead of changing the whole operation, the team decides to find out where the mistakes are made.

It identifies two product categories with similar packaging that are often placed on the same shelf. The team tries out clearer shelf labels in an aisle, counts errors during picking, and compares the results to its former error rate.

If the labels help employees pick the right products without slowing down their work, the team has a good reason to extend the change. If they don't, they can try another solution.

That's the value of PDCA. It allows people to make decisions based on what they see instead of just what they think might work.

The method can support small workplace changes or bigger process improvement initiatives. It is also complementary to Lean and Six Sigma and can be applied to many types of organizations.

History: Shewhart and Deming

PDCA's history is closely connected to two important names in quality management: Walter Shewhart and W. Edwards Deming.

Walter Shewhart, an American statistician, helped establish the foundations of statistical quality control. His work explored how businesses could understand variation in their processes and use data to improve consistency. Rather than treating every defect as an isolated incident, his approach encouraged organizations to look at how their processes were performing.

W. Edwards Deming later helped spread related quality management ideas, particularly through his work with Japanese industry after the Second World War. He argued that organizations needed to understand and improve their systems instead of simply blaming employees whenever something went wrong.

PDCA is often called the Deming cycle because of Deming's influence on modern quality management. However, its development is also closely linked to Shewhart's earlier work, and the improvement cycle evolved through different interpretations over time.

For further reading, see ASQ's PDCA cycle and the Lean Enterprise Institute's explanation of PDCA.

PDCA vs. PDSA

PDCA and PDSA are identical in terms of the basic four-step process but differ in their approach to the third step.

PDCA stands for Plan, Do, Check, and Act. PDSA stands for Plan, Do, Study, Act.

The difference between check and study might seem minor, but it changes the emphasis of the exercise. Checking usually is comparing what has happened to what was expected to happen. Studying asks a more general question: what can we learn from these results, and why did the change cause them?

The Deming Institute emphasizes PDSA as a way to build knowledge by predicting, trying things out, and reflecting. The goal isn’t just to determine if a target was met. “It is to understand what happened and to use that knowledge to inform the next experiment.”

Both approaches are conducive to continuous improvement. The PDCA cycle is widely used for operational quality improvement, while PDSA is associated with learning through experimentation, as in healthcare improvement initiatives.

You can explore The Deming Institute's PDSA cycle or read the PDCA overview on Wikipedia

The Four Steps of Plan Do Check Act

The four stages of Plan Do Check Act are easy to remember, but each has a different purpose. A team might have a great idea during planning, for example, but that idea won't mean much if nobody checks whether it worked.

Let's look at what each stage involves and how it plays out in a real workplace situation.

Plan

But first you need to understand the problem before you can determine how to solve it.

Think of a customer support team that has bumped its average response time up from four hours to seven. The team leader may think that the department needs more people. But is that the issue?

Ticket volumes might be higher. Maybe requests are being assigned to the wrong people. Or some sorts of queries take much longer to solve than others.

This gives the team time to investigate these possibilities, understand the current situation and decide what to test.

A useful plan will identify:

• Problem: What is not working as expected
• Baseline: What do the numbers tell you?
• Target: What constitutes a meaningful improvement?
• Hypothesis: What could help and why?
• Test: What is the team going to try, and for how long?
• Measurements: How will the team measure the results?

Tools such as process mapping and root cause analysis can help teams understand what happens beneath the surface.

For the support team, the plan could be to pilot a new process to route tickets for one type of request for two weeks. The aim may be to cut the average response time from seven hours to five, without compromising customer satisfaction.

The plan does not need to predict every possible outcome. It just needs to give the team a clear direction and a sensible way to measure progress.

Do

As soon as the plan is ready, the team puts it into action.

The Do stage tests the proposed change, ideally on a small scale.This means the team can spot any unexpected issues before rolling out the change to the whole organization.

For instance, in customer support, the team could apply the updated routing process for one ticket category. During the trial, employees would learn the new procedure, and the team would record the response times.

It is just as important to pay attention to what does not go as planned. The new process may reduce wait times, but it could also confuse employees about who should be processing certain tickets.It may also do well on quieter days but struggle when demand picks up.

In this stage, the team is recommended to:

• Test the change to the agreed scope.
• Collect the data identified in the planning.
• Record all unexpected problems or deviations
• Collect feedback from employees who participated in the trial.
• Avoiding changes that are unrelated to the task and make results harder to understand.

The 'Do' stage is not about proving the team had the right idea. It's about finding out what happens when that idea meets the reality of everyday work.

Check

This is the stage where the team looks at the results and asks whether the change made a difference.

Suppose the support team wanted to bring average response time down from seven hours to five. After two weeks, the average falls to 4.8 hours. That's a promising result, but there's more to examine.

Did customer satisfaction remain the same? Are the tickets being worked right or are employees just responding fast to close them? Has the improvement been maintained through days and ticket types?

A useful review considers:

• Whether the original goal was met.
• How the results compare with the baseline.
• Whether the improvement was consistent.
• Whether the change created new problems.
• Whether the results support the original hypothesis.

For a small experiment, a before-and-after comparison may be all that is needed. More complex problems may require trend charts, control charts, or statistical analysis to distinguish real improvement from normal process variation.

And what if the results are not encouraging?

It doesn’t mean the experiment was a waste of time. The problem could be something else than the team thinks, or the suggested solution might only work in some situations.

The check is about truly understanding the results even when they’re opposite to what the team originally assumed.

Act

The last step is to decide what to do with what the team has learned.

If the change is successful, the team can use it and integrate it into the normal process. If it helps but needs some adjustment the team can adjust it and run it again. If not, the team can try a different way.

Let's take the example of the support team again. The new routing process leads to an average response time of 4.8 hours with no impact to customer satisfaction.The team decides to roll it out for other ticket categories, document the new workflow and train the employees using it.

But what if the improvement vanishes when ticket volumes increase. The team might make adjustments to the routing rules and do a second trial, instead of immediately rolling the process out.

At the Act stage, one of three decisions is usually made:

• Adopt: The change is good enough to roll out wider.
• Adapt: The change is good, but could use a little polish.
• Abandon: The change doesn't provide the benefit desired.

A successful trial also requires follow-through.Updating standard operating procedures, assigning responsibility and monitoring performance can help to ensure that the improvement is sustained beyond the initial experiment.

Once a decision has been made, the team can begin another cycle. Perhaps it addresses a new problem, improves the existing solution, or strives for a loftier goal.

That is what makes PDCA a continuous improvement method rather than a one-time checklist.

PDCA Cycle Examples

The PDCA cycle isn't limited to manufacturing or quality control. Any team dealing with a process problem can use it, provided the proposed change can be tested and its results evaluated.

The following examples show how the same four steps work across different industries.

Manufacturing Example

A manufacturing plant finds that 8% of its finished products are rejected because their labels are incorrectly positioned. The problem creates extra rework and delays shipments.

Plan: Team reviews rejection records and watches the packaging line in action. It believes the faults are caused by misalignment of the sensors. The aim is to get the rejection rate down to below 3%.

Do: The team adjusts a sensor on one packaging machine and observes the next five production shifts. Operators refusals. Machine stoppages.

Check: The rejection rate drops from 8% to 2.5%. The team also checks for any effect on the speed of packaging or any downtime.

Act: The trial meets the goal with no significant unfavorable effects, and the plant documents the calibration process and trains the operators. The new process is then rolled out slowly to other suitable machines, and the rejection rates are monitored.

This PDCA example shows that even a small change can improve quality without the plant having to redesign its whole production line.

Healthcare Example

A hospital wants to reduce waiting times in its outpatient department. Patients are waiting longer than expected before consultations, and staff suspect that delays in registration and uneven scheduling are compounding the problem.

Plan: The hospital looks at waiting-time data and suspects that registration is a bottleneck. It looks to reduce median waiting time by 20% while keeping patient safety and registration accuracy intact.

Do: Test a simplified registration form and revised schedule for staff allocation in outpatient department for 2 weeks.

Check. The team compares the waiting times with the baseline and collects feedback from patients and staff. It also checks for registration errors to ensure the faster process hasn’t introduced new risks.

Act: If waiting times improve, and accuracy remains the same, the hospital can change the approach and think about a rollout to other departments. If the errors increase, the team will change the form or staffing arrangement and try the experiment again.

This example points to an important point: we should not improve a metric at the expense of another. Shorter waiting times matter but so does patient safety and quality of care.

Software Team Example

A software team regularly misses sprint commitments because bugs discovered late in development create unplanned rework. The team wants to be able to deliver more predictably without compromising software quality.

Plan: The team looks at the data from the last sprint and finds that a number of defects could have been discovered earlier. The aim is to reduce the escaped defects by 25% in the next three sprints.

Do: The team sets up peer code reviews and a focused automated test suite for one high-risk component. It shows the number of reviews performed, the number of defects found before release, and the number of defects reported after release.

Check: At the end of three sprints, the team reviews defect rates and delivery data relative to its baseline. It also looks to see if the reviews are slowing down development unnecessarily or if the tests are catching meaningful issues.

Act: Early defect detection is improved without creating unnecessary delays. The team adopts the new practices in its workflow. It changes the test coverage or the review process and runs an experiment again when the results are mixed.

PDCA works well for software teams because a workflow change can often be tested over just a few sprints. It also fits nicely with Agile practices, with teams often inspecting feedback and adapting how they work.

PDCA Template

A PDCA template gives teams a simple way to keep track of their improvement efforts. You don't have to write a complicated document for every little problem. A spreadsheet or shared worksheet is often enough, provided it captures the problem, proposed change, measurements, results, and next steps.

Before starting, answer four questions:

• Plan: What needs to improve, and what change do we expect to help?
• Do: What did we test, and what happened during the trial?
• Check: What do the results tell us compared with the baseline and target?
• Act: Should we adopt, adapt, or abandon the change?

Sample PDCA Worksheet Table

The figures in this worksheet are illustrative. They aren't results from an actual manufacturing study.

For larger improvement projects, the worksheet can include the project owner, timeline, data sources, costs, risks, and follow-up review dates. A control plan in Six Sigma can help teams manage improvements that need more detailed monitoring after implementation.

Benefits and Limitations of PDCA

PDCA is popular because it’s easy and can be used in different kinds of work. However, the method is only as useful as the way a team uses it. Good measurements, bad decisions, and lack of follow-through can ruin even the best-planned improvement.

Benefits

1. Makes continuous improvement more manageable

Not every problem requires a big project. PDCA allows a team to start off with a small change and observe the results, then build on them. It makes improvement feel like part of the day-to-day work, not an occasional organizational initiative.

2. Supports teams in making evidence-based decisions

Teams don’t just take opinions about what might work; they set a target and look at the actual results. This makes it easier to see if a change helped and if further action is required.

3. Reduces the chance of major changes

A small trial can highlight problems before an organization commits to a wider rollout. This is particularly helpful if the changes could impact productivity, cost, customer experience, or quality of service.

4. Get employees involved in problem solving

People who work with a process every day often see things that are not obvious to management. PDCA gives them a framework to share their observations, test ideas and help improve.

5. Compatible with other improvement methods

PDCA can be used with Kaizen, lean management, and total quality management. The kaizen PDCA cycle is about teams working on regular incremental improvements, rather than waiting for a major transformation.

Understanding the wider Lean Six Sigma principles helps explain how PDCA fits into a broader approach to improving quality and efficiency.

Limitations

1. Wrong data can lead to misleading conclusions.

If a team starts with the wrong baseline or measures the wrong metrics, they may believe a change to be successful when it isn’t. You have to make sure that the measures are reliable.

2. Deeper analysis might be needed for complex problems.

PDCA is a flexible framework, but it doesn’t tell you what analytical tools you need to dig into hard problems. If there are multiple causes that interact, you may need to use statistical methods or a more detailed approach like DMAIC.

3. Results might not be instant.

The first time doesn’t always work. Teams might need a few rounds of testing to get it right. That can be frustrating when the stakeholders want the problem fixed right then and there.

4. Improvements can be lost without follow-up.

What works in a short trial may not continue to work over time. When ownership is not clear, procedures are not up to date, and monitoring is not regular, employees may gradually go back to their old habits.

5. It is not enough to repeat the cycle.

The PDCA is only valuable if teams learn from iteration to iteration. You can run the same experiment without looking at the previous results and waste time. And the original problem is not solved.

PDCA vs DMAIC: Comparison Table

PDCA and DMAIC both help teams solve problems and improve processes, but they differ in how much structure and analysis they typically require.

DMAIC stands for Define, Measure, Analyze, Improve, and Control. It's a core Six Sigma methodology used to investigate persistent process problems, particularly those involving defects, variation, or performance gaps.

When should you choose PDCA?

PDCA is good for problems that are controllable, where you can test a possible solution quickly and the results are largely easy to understand.

For example, a customer support team that wants to improve ticket assignment may experiment with a new routing rule for a certain type of request. The team can test the change to see if it actually reduces delays before rolling it out to other categories.

When should you choose DMAIC?

DMAIC is better when the problem has still remained despite previous attempts to fix it, the underlying causes are not clear, or detailed analysis is needed to understand process variation.

So, a manufacturer that has repeated defects in several production lines might have to look into equipment settings, materials, operator practices, and other possible causes before deciding on a remedy.

The DMAIC process provides a more structured framework for investigating and resolving such problems.

The two methods can also be used together. A team uses DMAIC to solve a big quality problem. PDCA can then be used to refine the improved process.

PDCA in ISO Standards and Quality Management

Quality management is not only about checking the finished products and finding mistakes. It’s also about building strong processes, tracking performance, and finding ways to make sure problems don’t happen again.

PDCA fits well into total quality management here.  Rather than leaving improvement to a dedicated quality department, organizations can tap employees, managers, and process owners to uncover issues and test practical solutions.

A team might, for example, apply PDCA to cut down on rework, boost customer satisfaction, or streamline an approval process. The same approach can support Lean management, where teams look for activities that consume time or resources without adding value.

If you'd like to understand that approach in more detail, explore what is the lean process.

PDCA in ISO 9001

ISO 9001 is an international standard for quality management systems. It helps organizations establish processes that consistently meet customer and applicable regulatory requirements while supporting continual improvement.

PDCA is a good way to view how the activities of a quality management system fit together.

• Plan: Establish quality objectives, assess risks and opportunities, and determine the required processes and resources.
• Do: Implement the planned procedures and controls.
• Check: Look at performance, compare to goals, and see if goals are being achieved.
• Act: problems and improve the system as necessary.

The model helps to link planning, implementation, evaluation, and corrective action. But PDCA alone is not enough to ensure ISO 9001 conformance. Organizations still need to comply with the specific requirements of the standard.

Quality management goe beyond preventing defects. It also has process consistency, customer satisfaction, risk management, and the ability to deliver products and services reliably. Knowing more about project quality management can help connect these ideas with project delivery.

For further reading, ASQ's resource on continuous improvement explains how ongoing improvement can become part of everyday organizational practice.

PDCA in the Green Belt Curriculum

For professionals learning Lean Six Sigma, PDCA provides a useful introduction to structured improvement. It brings together a number of activities that are often taught in isolation. These include defining a problem, gathering data, testing a solution, evaluating the results, and deciding what to do next.

The typical Green Belt curriculum includes process mapping, data collection, root cause analysis, and performance measurement. PDCA helps students see how these tools fit into a larger improvement effort.

It also gives you context to the relationship between Lean and Six Sigma. Lean is about maximizing flow and minimizing waste; Six Sigma is about reducing defects and variation. Both benefit from a systematic way to test changes and sustain results.

Professionals preparing for a Lean Six Sigma Green Belt certification should understand not only how PDCA works but also when a more detailed methodology is needed. A Lean Six Sigma Green Belt practice test can help reinforce important concepts and terminology.

When Green Belts Choose PDCA Over DMAIC

A Green Belt may choose PDCA when the problem is clearly defined, the proposed change is relatively straightforward, and the team can evaluate the outcome using practical measurements.

Consider a warehouse where employees spend too much time walking between shelves to collect orders. The team could test a revised shelf layout in one section, measure picking times, and check whether order accuracy remains stable. If the change works, it can be extended to other sections.

DMAIC would generally be more appropriate if the problem involved multiple interacting causes, unclear process variation, or a need for extensive data analysis.

Understanding what is Six Sigma helps explain why the choice of improvement method should depend on the problem being solved.

Green Belts should also consider the cost of poor quality, including rework, scrap, delays, and customer complaints. These costs help determine whether a small PDCA experiment is enough or whether a larger improvement project is justified.

Conclusion

The PDCA cycle gives teams a practical way to improve processes without assuming they already know the answer. They can use Plan, Do, Check and Act to trial an idea, see what actually happens, and decide whether the change is worth keeping.

The advantage of the method is that it makes improvement tractable. A team doesn't need to redesign an entire process to start making progress. It can start with a single well-defined problem, try a sensible change, and build on the results.

PDCA can be applied to help with day-to-day operational improvements, Kaizen initiatives, and larger quality management efforts, including those aligned with ISO 9001. DMAIC might offer the deeper analysis to identify and address root causes for more complex problems.

It’s not a matter of going through four steps and checking a box at the end. It is to understand a problem a little better, make a better-informed decision, and take that learning into the next improvement.