PDCA: the task is closed, but is the problem solved?

The changeover cart stands next to the machine. The tools have their places. The work instruction has been updated, the operators trained, and the task on the board is marked "done".

One question remains: what has changed in the changeover itself?

Imagine we wanted to cut it from 60 to 45 minutes. After introducing a pre-prepared tool kit we got 53 minutes. There is an improvement, but the target was not reached. Should we lock in the solution, improve it, or look for another cause?

This is exactly the decision a well-run PDCA cycle should make possible. We need to know which mechanism we were testing, what the measurement showed and how the result will shape the next trial.

The starting point for this article is a conversation between John Dyer and Mohamed Saleh published in IndustryWeek on 27 October 2026. The authors warn against reducing PDCA to ticking off actions and stress the importance of learning from results. These are practitioners' views, not a study of implementation effectiveness. ^[1]

Below I develop this idea using a production example, drawing on materials from the Deming Institute, the Lean Enterprise Institute and the Institute for Healthcare Improvement. All changeover figures are an original teaching example by the author. They do not describe a real client or implementation. The proposed questions, review card and operational decisions are makeXcellence's practical interpretation.

01 Start with the question the experiment should answer

"Introduce a changeover cart" is a task. You can give it an owner, a budget and a deadline. To judge the value of that action, you also have to name the problem and the expected mechanism of improvement.

Let us assume they read as follows:

During the changeover the operator leaves the workstation to find tools and clamping parts. We suspect that preparing a complete kit in advance will reduce this part of the downtime.

A statement like this can be tested. We can observe the operator leaving the station, measure search time and establish whether the kit was actually complete. If the effect turns out smaller than predicted, we have a reference point for further analysis.

In a Lean Enterprise Institute piece, Judy Worth and Beau Keyte stress that before formulating a hypothesis you need to understand the actual situation: analyse the data and observe the work directly where it is done. ^[3]

That is why, before buying any equipment, I would suggest a joint observation with the operator. What was needed? What was missing? Why was it not prepared earlier? Was the tool unavailable, out of order, or did the information about the next order arrive too late?

Each answer may lead to a different test. A cart will not test the hypothesis about late information from planning if we still do not know which kit to prepare.

02 PDCA and PDSA: why the difference is worth knowing

PDCA stands for Plan–Do–Check–Act: plan, do, check and take action based on the result. In PDSA the third step is Study — studying and analysing the outcome.

The Deming Institute points out that W. Edwards Deming emphasised PDSA. What mattered to him was making a prediction, comparing it with the observation and, where needed, changing the theory that explains how the process works. So the two names should not be presented as fully interchangeable, nor should the popular understanding of PDCA be attributed to Deming without qualification. ^[2]

In a plant that uses the name PDCA, however, I would start with the quality of the conversation during "Check". Can the team explain the gap between expectation and result? Does the next test follow from the previous one? Do we allow ourselves to reject our own idea?

Changing a letter on a form will not settle these questions. You can keep the familiar name and consciously deepen the way results are analysed.

03 The process target and the experiment's prediction are two different things

This distinction matters a lot in our example.

The process target is 45 minutes. It describes the required level of performance. The experiment's prediction states what effect we expect from a specific change, and why.

We should not automatically assume that every trial must reach the target straight away. If searching takes a few minutes, preparing the tools in advance may be a useful step, but expecting an improvement of more than ten minutes requires additional justification.

A prediction written down before the test also protects against fitting the story to the result. Once you get 53 minutes, it is easy to say: "That is exactly what we expected." A record made before the trial lets you check whether that was really so.

I suggest a simple structure:

If we change X, we expect Y, because we assume Z. We will test it under conditions W, measuring M.

In our example: assembling the tools in advance should reduce search time during the downtime. The test will cover a selected changeover type, and the observation will separate searching, assembly, adjustment and waiting for approval. Only on the basis of baseline data will the team write down a realistic numerical forecast.

04 Example: 60 minutes before the change, 53 minutes after the trial

Let us take a simplified model of a changeover. For this example we measure the time from the last good part of the previous order to the approval of the first good part of the new order. We observe rate stabilisation after approval separately.

The values below are an illustration. We assume the categories do not overlap and can be added up. In a real process with parallel work you need to reconstruct a shared timeline instead of adding up each person's time.

If the original expectation was "the cart alone will get us down to 45 minutes", the data challenge the scope of that assumption. From eight minutes of searching we gained a seven-minute reduction. The other stages did not change.

This does not yet mean the cart definitely caused the whole improvement. We need to check that the trials were comparable. Was staffing similar? Did we change over the same product family? Was there extra help from a process engineer? Did the start and end points of the measurement stay the same?

At this stage I would record a cautious conclusion: the result is consistent with the hypothesis about searching, but it does not confirm that the target for the whole changeover has been reached. The next decision concerns repeating the test and examining the remaining stages.

05 How to run a small test that gives a useful answer

IHI recommends starting with small tests, writing down predictions, observing unexpected events and planning subsequent cycles based on results. The organisation also points to the need to test changes under different conditions. These are methodological guidelines originating in healthcare improvement; the application to manufacturing below is an adaptation. ^[4]

In our example I would limit the first trial to one machine and one specific product transition. Before the start, the team should agree:

• who assembles the kit and who confirms it is ready;
• which events mark the start and end of the measurement;
• who records times and deviations;
• which quality requirements and safety rules remain in force;
• when the trial review will take place and who will decide.

During the test it is also worth noting any help provided by people outside the standard crew. A result achieved thanks to the constant presence of an extra engineer describes different conditions from the shift's everyday work.

A small trial answers a limited question. I would not treat it as automatic approval for rollout on all machines. Extending to another shift, another product or another configuration should have its own question: what do we now want to confirm?

06 SMED: analyse the whole changeover, step by step

In the example with the tool-preparation cart we see only one part of the problem. If we want to bring the changeover down to 45 minutes, it is worth carrying out a SMED analysis of the real process rather than limiting ourselves to buying equipment or a general list of ideas.

SMED (Single-Minute Exchange of Die) is a way of systematically shortening changeovers. Its basic step is to distinguish internal activities, which require the machine to be stopped, from external ones, which can be done while the machine is still running. The team then looks for safe ways to move some internal activities to before the stop or after the restart. Only then does it improve the work that still has to take place during the downtime. ^[6][9]

In practice I would run the analysis in the following order:

1. Define the scope and measurement boundaries. Choose a specific machine and a transition between specific products or tools. In this example we measure from the last good part of the previous order to the first good part of the new order. Also record separately the moments the machine stops and restarts, the time to the first good part, start-up scrap and stabilisation of operation.
2. Observe a real changeover. Together with the operators, watch the whole sequence at the workplace. If the plant allows it, film it after agreeing the rules with the employees. Record the sequence of activities, who performs them, start and end, movements, searching, waiting, rework, transport and whether the machine is running or stopped. Do not judge people — you are analysing how the process is designed.
3. Lay the steps out on a timeline. Include every person and parallel activities. Do not mechanically add up several people's times: two activities performed in parallel may fall within the same downtime. Separate the calendar time of the downtime from the total labour input.
4. Mark each activity as internal or external. For an internal step ask: what, technically or for safety reasons, requires the machine to be stopped? Check whether its preparation, setting, transport, inspection or documentation can be done earlier. Do not reclassify work as external if it requires access to a hazardous zone or bypasses interlocks.
5. Move what you can outside the downtime. For example: prepare and check the complete set of tools, tooling, material, documentation and measuring instruments before the previous order ends. Decide who does this, using which checklist, and how they confirm the kit is ready.
6. Simplify the activities that remain internal. Together with the operator, look for unnecessary adjustments and movements, repeated clamping, ambiguous settings, hunting for reference points and waiting for decisions. Consider quick clamps, stops, presets, clear markings and safe parallel work. Assess every change in terms of quality, ergonomics and safety.
7. Run a trial and check the effect under comparable conditions. Record times before and after the change, crew, product, kit completeness and deviations. Check whether both the downtime and the total time to the first good part have shortened, whether work has merely been shifted to another person, and whether scrap, risk or the load on another workstation have increased. Repeat the trial on further comparable changeovers and shifts.
8. Lock in the proven way of working. Update the standard, the preparation checklist and responsibilities. Define the scope of validity, how the kit is replenished and how to react to missing items. After rollout keep tracking times and deviations, because the standard is meant to hold the result and make further improvement easier.

SMED is not about speeding up the operator. It is about redesigning the sequence and conditions of work. Nor is the goal to achieve a "single-digit" time at any cost: safety, quality and process stability remain the priorities.

SMED analysis form

The form below can be copied for a single changeover type. First fill in the observation part based on the real sequence, and only after jointly analysing the map add improvement ideas. If different changeover variants run differently, record them separately.

A. Scope and observation conditions

B. Log of the current process

Record in time order. In the "machine status" column enter running / stopped. For parallel work, assign activities to a person and mark overlaps on the same timeline.

// The full printable form has 20 log rows and more room for notes →Download the SMED form (PDF)

Current-state summary: machine downtime: ; time to first good part: ; total labour input: ; number of start-up parts/scrap: ; additional notes: .

C. Analysis and proposed changes

Safety and quality conditions to confirm: .

New preparation standard before the machine stops: .

Sequence and division of roles during downtime: .

D. Trial plan and verification

Conclusion: What improved? What did not work as predicted? What new problems arose? What do we still not know?

Decision: repeat the trial improve the solution extend the test implement and standardise reject the change

Next step / owner / deadline: .

How the SMED form connects with PDCA

The SMED form structures the analysis of a specific changeover: it shows the activities and how they actually run, and then helps prepare and assess the change. The PDCA card later in this article is for a broader record of the problem, hypothesis, measures, conclusions and decisions for the whole improvement cycle. A single SMED analysis can therefore include several small PDCA trials.

07 Measure the outcome, the execution of the change and its side effects

IHI distinguishes outcome, process and balancing measures. The last of these are used to check whether improving one area does not cause problems in another. ^[5]

For our example I would choose them as follows:

I would not start with an extensive set of indicators. I would choose the ones without which no honest decision can be made after the test. To the numerical data I would add short observations from operators: what was easier, where a new difficulty appeared, what was missing from the kit.

It is also worth separating equipment downtime from people's working time. SMED distinguishes internal activities, which require the machine to be stopped, from external ones, which can be done while it runs. Moving the right activities outside the downtime is one of the basic mechanisms for shortening changeovers. ^[6]

The fact that tool preparation took place earlier does not mean the work has disappeared. It can shorten machine downtime while keeping a similar labour input, or shift it to another person. In assessing such a change I would check both values.

08 A single good result and an average are not enough for every decision

Suppose that after the change we got times of 45, 52, 53, 55 and 60 minutes. Their average is 53 minutes. That is exactly the number from our example, but the individual trials tell us more: once the target was reached, and once the time went back to the baseline value.

I would not hide this difference in a single green box on a report. For each trial I would record the product, shift, crew, kit completeness and significant deviations. Only then can you examine what distinguished the shorter and longer changeovers.

IHI recommends tracking data over time, because the sequence of results helps identify patterns and changes in how the system performs. ^[5] In this case it is enough to start with a chart of successive times, marking when changes were introduced and commenting on deviations.

The five observations in this article illustrate a way of thinking; they are not a universally required sample. The number of measurements and the analysis method must be matched to variability, risk and the decision. From such a small example I would not conclude that there is a statistically confirmed, lasting improvement.

I would be similarly cautious about money. Seven recovered minutes are not automatically a cash saving. In the calculation I would check changeover frequency, how the recovered time is used, demand, and the effect on overtime or the need for an extra shift. It is worth presenting the operational result and its economic consequences separately.

09 What research tells us about using PDSA

A systematic review by Michael J. Taylor and co-authors, published in BMJ Quality & Safety in 2014, covered 73 articles on the use of PDSA in healthcare. Only 14 of them fully documented a sequence of iterative cycles. 47 publications were described sufficiently for a detailed assessment of all elements of the method. ^[7]

These figures should not be presented as a percentage of failed PDCA implementations in industry. The study concerned a different sector and assessed the use of the method on the basis of publications. Lack of a description of an action is not the same as proof that it was not carried out. Nor does the review give a simple percentage estimate of PDCA effectiveness.

For me it is an argument for a clear record of successive trials. In the documentation of a manufacturing project I would look for the link: which conclusion from the previous test changed the plan of the next one? If all you can see is a list of implemented ideas, it is hard to judge how the team arrived at the solution.

10 "Act" should end with a concrete decision

After a trial with a result of 53 minutes I would consider four options. The table below is a makeXcellence review proposal, not a quotation from a standard.

In our example I would not immediately buy more carts. First I would check whether kitting works repeatably. In parallel I would start observing adjustments and waiting for approval.

With waiting, it is worth checking when quality control learns that a measurement is needed, whether the instrument is available and whether the documentation defines the criteria unambiguously. Twelve minutes of waiting do not yet point to a single cause. The next trial should follow from what we observe.

11 How to lock in a solution without closing the door to further improvement

IHI distinguishes testing from implementation: implementation means permanently building the change into the way of working, documentation and relevant parts of the organisation. It also points to testing the solution under different conditions beforehand. ^[8]

For a changeover kit, this would mean for me defining responsibility for preparation, a list of required items, how gaps are replenished and how to react when the kit is not ready. You also need to provide time for this work and check whether the standard is feasible with the normal crew.

A signature on a work instruction alone would not yet show me whether a person can assemble the kit and recognise a deviation. I would ask them to do it under real conditions and to explain what they would do if an item were missing.

In the standard I would also record the scope: for which machine, product family and configuration it was tested. This helps avoid treating a local solution as automatically right for the whole plant.

12 The leader is responsible for the conditions for testing ideas honestly

Dyer and Saleh highlight the importance of learning and of being able to admit that a solution did not work as expected. ^[1] In practice I would translate this into a requirement for rigour, including when the idea comes from a manager.

After an unsuccessful trial I would ask: did we carry it out according to plan? Is the result reliable? Which assumption do we now need to change? At the same time I would expect an owner for the next step and a decision date.

The phrase "we learned a lot" needs substance. In our example a useful answer would be: "We reduced searching, but adjustments remained unchanged. In the next trial we will examine how they run and why they are repeated."

The situation is different when nobody took the measurement or the agreed conditions were skipped. Here the problem is the way the test was run. Separating these cases helps maintain accountability without forcing people to defend every earlier decision.

13 A PDCA review card for use on the shop floor

The card below is an original makeXcellence proposal. It fits on one page, with measurements attached as an appendix. Its purpose is to make decisions easier, not to increase the volume of documentation.

At a meeting you can go through the card with six sentences:

The problem was…
We suspected that…
After this change we expected…
Measurement and observation showed…
We still do not know…
So now we decide…

At your next review, pick one action marked as complete. Check whether its owner can complete these sentences and point to the data behind the answer. If a measurement is missing, plan it. If the result differs from the prediction, agree which assumption needs checking. That will be a concrete start to the next cycle.