PDCA: the Plan-Do-Check-Act cycle

In one line

PDCA (Plan, Do, Check, Act) is a four-step method for solving a problem or testing an improvement in a short, controlled cycle, checking with data whether it worked before accepting it as good.

What it is

Its origin lies in the statistical process control work of Walter A. Shewhart, who worked at Bell Laboratories and in 1939 formalized a cycle for applying the scientific method to the improvement of production processes. W. Edwards Deming, a student of Shewhart, picked up that idea and took it to postwar Japan, where the Union of Japanese Scientists and Engineers (JUSE) ended up naming it the "Deming Cycle" in his honor — although Deming himself always acknowledged that the foundation was Shewhart's work. That is why the cycle is cited interchangeably as PDCA, the Deming cycle or the Shewhart cycle.

The logic of the four stages is always the same:

• Plan: define the problem, analyze its data and build an action plan with a measurable objective.
• Do: carry out that plan, preferably on a limited scale, recording the data on what happens along the way.
• Check: compare the results obtained against the stated objective — was the expected outcome achieved?
• Act: if the result was as expected, standardize the change as the new way of working; if not, correct the plan and go through the cycle again.

INTI stresses a key point: completing one turn of the cycle is not "finishing" the process, but leaving a more solid base (a new standard) from which to start again. PDCA is not a one-time project — it is a spiral that repeats.

What it is for

It is used to lower the risk of an improvement before committing large resources to it. Instead of implementing a change across the whole plant and only then finding out whether it worked, PDCA forces you to: think before acting (Plan), test on a small scale (Do), confirm with data whether something really improved (Check), and only then decide whether it is worth generalizing (Act). It is the underlying structure behind any improvement event, even if that event uses a different name or a different template.

How to apply it

In a maintenance context, one turn of PDCA on a typical problem looks like this:

1. Plan: choose a specific, limited problem (a recurring failure, a repair time that seems high, a deviation in a checklist), gather the available data about it, propose a probable cause and define which concrete action will be tested and what result is expected.
2. Do: apply that action within a controlled scope — one machine, one shift, a short period — and write down the data while the test is running, not just at the end.
3. Check: compare the data from after against the data from before and against the objective that was set. If the improvement cannot be measured, this stage cannot be done seriously.
4. Act: if the result confirms the improvement, turn it into the new standard (procedure, checklist, training) and extend it to other similar machines or shifts. If it does not confirm it, adjust the plan — or the cause that had been assumed — and start a new cycle with what was learned.

Many improvement event formats used on the plant floor under other names (identify the problem, analyze the cause, act with a solution, verify the result) follow exactly this same four-step logic, even if they do not call it PDCA or cite Deming or Shewhart. Recognizing the pattern helps you understand that these are not different methods competing with each other, but the same basic structure under a different label.

Real example

Illustrative (made-up) example: the sources consulted explain the origin and structure of the cycle, but they do not provide an industrial maintenance case with their own data — the following case is illustrative, built to show how the method would be applied.

A line has repeated stoppages of a conveyor belt motor due to thermal trip, about 6 times per month, with an average of 40 minutes of downtime each time.

• Plan: the team reviews the history and finds that the trip always happens at the same bearing, after several hours of continuous operation. Hypothesis: the bearing is poorly lubricated. The objective is set to reduce stoppages from thermal trip to fewer than 2 per month, and it is decided to test a change in the relubrication frequency.
• Do: for one month, that bearing is relubricated every 15 days instead of every 30, on that conveyor only, and every thermal trip that occurs is recorded.
• Check: at the end of the month, stoppages from thermal trip dropped from 6 to 1. The objective was met.
• Act: the new relubrication frequency (every 15 days) is standardized for that motor model and added to the preventive maintenance plan for the similar conveyors in the plant.

How to build it

A simple table with these four rows and their guiding questions is enough to start any PDCA cycle — you fill it out once for each turn of the cycle:

Stage	Guiding questions
Plan	What is the specific problem, and with what data? What is the probable cause? Which action will be tested and what result is expected?
Do	Where and for how long will it be tested (machine, shift, period)? What data will be recorded while the test runs?
Check	Do the results obtained match the stated objective? How much did it improve, in numbers?
Act	If it worked: how is it standardized (procedure, checklist, training) and to which other machines is it extended? If it did not work: what is adjusted before starting a new cycle?

Benefits

• Reduces the risk of an improvement: you test on a small scale before committing time and resources to something bigger
• Forces you to decide with data in the Check stage, instead of assuming a change worked because it "looks better"
• Builds up accumulated learning: each turn of the cycle ends in a better standard than the previous one, not in an isolated attempt
• Adapts to any scale, from adjusting a specific procedure to organizing a large improvement project

Limitations to keep in mind

• PDCA is a change management framework, not a diagnostic method: it does not replace root cause analysis tools such as Ishikawa, 5 Whys or RCA — it is combined with them in the Plan stage
• If the Plan stage is rushed or done without data, the rest of the cycle loses its meaning: you end up "doing" without being clear about which hypothesis is being tested
• If nobody forces the Check stage to use concrete numbers, the cycle becomes an excuse to say "we already did something" without confirming whether it really improved
• Cycles that are too long (months for a single turn) lose the method's central advantage, which is to iterate quickly and cheaply

In summary

PDCA is the four-step structure —Plan, Do, Check, Act— behind almost any orderly improvement method, originating in Shewhart's statistical control and spread by Deming in postwar Japan. Its value lies not in the name or the acronym: it lies in forcing you to test on a small scale, measure with real data, and only then standardize or correct. The same logic appears, under other names, in most of the problem-solving formats used on the plant floor.