What is the PDCA Cycle and How to Test Process Changes Without Breaking Your Operations?
A big part of a good leader’s job is to make sure their team is operating at the best possible capacity. Now, these are very generic-sounding words, and in reality, behind “operating at the best possible capacity,” we have a plethora of elements, all of them building up this image: great quality control, fair workload distribution, outstanding operating procedures, a zero-waste framework, good and balanced feedback and coaching, and room for growth and development. At a glance, this might look like something that is very hard to achieve, or at least appear as some sort of “ideal situation.”
It’s not!
People and processes need constant maintenance and constant tweaking to make sure things run exactly as they should. Because of this, we need to always invest in them. But how can we make this investment in the best possible way? How can I make sure whatever tweaks I am making are the best? A very simple way to do this is by using the PDCA cycle. In this article, we will talk about the following topics:
- The Lesser-Known Hero vs. The Mighty and Brave One
- The Plan: How to Set Up Your Experiments
- The Do: The Mini-Test
- The Check: Looking at the Results
- The Act: Pivoting
The Lesser-Known Hero vs. The Mighty and Brave One
All around the world, from the moment we are little, we are told about the Great Hero – the one that goes out and fights dragons, saves the princess, makes the world a better place, etc. We don’t have as many stories about the ones doing the smaller things: helping a poor farmer, giving food to people in need, doing the small things that also need to be done. In this exact context, we also have leaders. Many of them go straight for these really big and impactful changes, thinking that “one dragon” will trump any small and not-so-meaningful task. What they don’t realize, however, is this: while you spend 3 months trying to take down the dragon (and might end up failing), others can use those 3 months to do at least 30 different and smaller tasks that, in the end, will do way more than your dragon will.
This hero complex is very common in the corporate environment these days, and it seems like every leader we see has it: they all want to make these big changes and showcase to the team, customer, upper management, or the company that they are the best possible person for this job. Because of this, many of them fail because one big change is not as impactful as many smaller and easier-to-implement changes. Continuous improvement and leadership, at the end of the day, is a game of strategy and patience. Those that master the concept are the ones that succeed.
Instead of going for the big change, just do the smaller ones. They are significantly easier to implement, like a controlled experiment project for your team. Here is where PDCA really shines, because it’s a framework specifically created for this.
The PDCA story begins in 1920 at Bell Telephone Labs with a guy named Walter Shewhart. He realized that errors were actually treated like lightning, meaning people reacted to them once things broke. He saw the need to have processes fixed before disaster hit, so he designed a 3-step process: Specification, Production, and Inspection. In 1940–1950, Mr. W. Edwards Deming enters the story. As a former student of Mr. Shewhart, Deming worked during the war with American factories, using statistical models to help them streamline production. After the war, Japan was looking to rebuild their country, and this required a significant effort and a great focus on continuous improvement. They invited Deming to Tokyo, and there he took this 3-step approach of his teacher (Specification, Production, and Inspection) and transformed it into Design, Make, Sell, and Test. Japanese executives and engineers took his concept and adapted it into what we know today as Plan-Do-Check-Act, or the Deming Wheel. Companies like Toyota took the PDCA cycle, embedded it into every level of their frontline operations, and pioneered the Kaizen (continuous improvement) movement. By the 1970s and ’80s, Japanese cars and electronics were dominating global markets due to their unmatched reliability. Surprised American executives flew to Japan to study their secret, only to discover it was the very framework Deming had tried to sell them decades earlier.
To make things easier for everyone, we will go over each of the PDCA stages using a made-up situation, and based on it, we will see what we must do in each step.
The Situation Scenario: The Messy Handover
You just took over as manager of a team that handles customer escalations. Every day at 5:00 PM, the day shift is supposed to hand off unresolved tickets to the evening shift. Right now, it is a mess. Notes are scattered, important details get lost, and frustrated customers are calling back the next morning because nobody followed up. Your instinct might be to write a brand-new 10-page handover policy and force all 15 team members to use it starting Monday. Instead, you decide to run a low-risk PDCA cycle with just two volunteers.
The Plan: How to Set Up Your Experiments
This is all about setting up your hypothesis. The theory here is rooted in root-cause analysis rather than symptom-masking. Most operational fixes fail because teams jump to solutions before fully understanding the problem. In this stage, you define the gap between current performance and target performance, identify the root cause, and formulate a clear, testable hypothesis.
- Core Question: “What is the exact problem, and what small change will fix it?”
- Key Output: A test plan with defined success metrics and a low-risk testing environment.
Going back to our scenario, Plan would look a bit like this:
- The Problem: Unstructured handovers lead to missed ticket details and customer complaints.
- The Goal: Reduce missed details on evening handovers to zero for one week.
- The Plan: Instead of long email updates, you create a simple 4-question digital form (Ticket ID, Core Issue, Next Step Needed, Urgency Level).
- The Sandbox: You ask two representative reps (one from the day shift, one from the evening shift) to test this form for five days.
The Do: The Mini-Test
This one is all about executing your plan. The theoretical focus shifts to risk mitigation and controlled observation. “Do” does not mean rolling out a company-wide change; it means running a small-scale pilot. By isolating the trial to a single team, shift, or process step, you limit operational exposure while gathering real-world data.
- Core Question: “How do we test this change with minimal operational risk?”
- Key Output: Unvarnished trial data and qualitative feedback from the frontline.
Now for the practical example of Do, based on our scenario:
- Execution: For one week, your two test reps use the 4-question form for every handed-over ticket. The rest of the team keeps doing what they normally do.
- Observation: You resist the urge to step in or change the form mid-week. You simply observe and write down what happens:
- Filling out the form takes the day-shift rep less than two minutes per ticket.
- On Wednesday, the evening rep notes that “Next Step Needed” was a bit vague for a complex technical issue.
The Check: Looking at the Results
Check is all about evaluating the results. This phase is governed by empirical validation. Human instinct biases us to see success where we put in effort, but the “Check” phase forces an objective comparison between your predicted outcomes (from Plan) and your actual numbers (from Do). It reveals unpredicted side effects and validates whether your hypothesis held true.
- Core Question: “Did the data prove our hypothesis right, or did something unexpected happen?”
- Key Output: A clear gap analysis separating hard facts from assumptions.
As for our simulation, it would go like this:
- The Review: At the end of the week, you sit down with your two volunteers for 15 minutes to review the numbers and their feedback.
- The Results:
- 100% of the test tickets were handed over with zero missing information.
- Evening resolution time for those specific tickets dropped by 20%.
- Feedback: The team loved the speed, but agreed the “Next Step Needed” field needed a simple dropdown menu (e.g., Customer Call Back, Tech Escalation, Refund Pending) to make it even clearer.
The Act: Pivoting
Act is all about what you do next: will you implement or not? The underlying principle here is standardization and continuous iteration (Kaizen). A test is useless unless it changes long-term behavior. If the pilot succeeded, you update standard operating procedures so the gain is permanently locked in. If it failed or yielded mixed results, you refine the approach and feed those learnings directly into the next Plan stage.
- Core Question: “Do we standardize this new way of working, tweak it, or throw it out?”
- Key Output: An updated standard process or a refined hypothesis for the next cycle.
And the example goes like this:
- The Outcome: The test was a success, but it needs one small tweak.
- Standardization: You add the suggested dropdown menu to the form, spend 10 minutes demoing it in your next team meeting, and roll it out to all 15 team members as the official new process.
- Next Loop: Because you tested it on a small scale first, the team isn’t resistant – they already know it works because their peers helped design it.
If you need something a bit more visual to help you grasp the concept, this picture should help. It has the basic principles and will allow you a quick and easy way to view the entire thing every time you need a small refresh.
As a closing note here, PDCA is just one of the multiple ways we, as leaders, can help processes improve, make our team’s life easier, and get closer to that Successful Team Goal we all want to achieve. More articles will come in the Optimize Pillar exploring other ways to implement continuous improvement.
Until next time, stay safe, healthy, and happy!