Most teams that run a PDCA cycle are genuinely good at three quarters of it. They plan something, they do it, and they check what happened. Then the cycle just stops. Nobody circles back to the 'act' step, the loop quietly dies, and six months later the same problem turns up again wearing a different disguise.
That's not really a Plan-Do-Check-Act problem. It's an operating cadence problem, and it's the same one that kills change management rollouts, quarterly plans, and more than a few OKR programmes. The PDCA cycle itself is almost embarrassingly simple. The hard part is turning it into something a team keeps running, rather than a diagram left over from a training deck.
This article covers what the PDCA cycle actually means, why it stalls in practice, and a straightforward way to run it on a cadence that survives past the first attempt.
What the PDCA cycle actually means
If you've landed here searching for the PDCA meaning in one line: PDCA stands for Plan, Do, Check, Act. It's a four-step method for making a change, seeing whether it worked, and deciding what to do next, then doing the whole thing again. It's sometimes called the Deming cycle, after the statistician W. Edwards Deming, who popularised it during Japan's post-war manufacturing boom. Deming himself credited the idea to his mentor Walter Shewhart, which is why you'll also see it called the Shewhart cycle.
The four steps, in short:
- Plan: define the problem, form a hypothesis about what will fix it, and decide upfront how you'll know if it worked.
- Do: run the change, ideally on a small scale first, before you commit the whole team to it.
- Check: compare what actually happened against what the plan predicted, not against a general sense of how it went.
- Act: decide what to do with what you learned. Standardise it, adjust it, or drop it and try a different plan.
Then you go around again. That last part, the 'again', is the bit almost everyone skips, and it's the whole point of the cycle. A PDCA cycle that only ever runs once is just a pilot project with an acronym attached.
Why the cycle stalls after 'check'
Plan, Do and Check all produce something you can point to: a plan document, a completed pilot, a review meeting. Act doesn't produce an artefact on its own. It needs someone who's already in the room, with the authority to say 'let's roll this out' or 'let's kill it', and a reason to keep the topic on the agenda instead of letting it quietly slide off.
Without that, most PDCA cycles turn into a single loop that never repeats. The difference between a cycle that dies after one lap and one that actually compounds usually comes down to whether these four things are decided in advance, not worked out after the fact:
PDCA and the change model you're already running
If you're already using a formal change management model, whether that's Kotter's eight steps, ADKAR, or Lewin's unfreeze-change-refreeze, PDCA isn't a competing framework you need to pick instead. It's the operating loop that sits underneath whichever model you've chosen: the mechanism that actually checks whether the change took, rather than just whether the rollout happened on schedule. Most change programmes have a plan and a launch date. Far fewer have a fixed point where someone checks the result against the original prediction and decides what happens next, which is exactly the gap PDCA is built to close.
How to turn PDCA into a cadence, not a poster
None of this needs new software or a formal quality programme. It needs four decisions made before you start the first loop, not after it stalls:
- Name one owner for the whole loop, not just the 'do' step. Whoever owns 'act' owns the cycle.
- Decide what 'act' means before you start: what result would make you standardise this, and what result would make you kill it.
- Put 'check' on a date that already exists on the calendar, your weekly or fortnightly check-in, instead of inventing a new meeting nobody will protect.
- Treat the output of 'act' as the input to the next 'plan', and tie that handoff into whatever cadence already runs your goals, whether that's an OKR cycle or a broader operating rhythm.
.png)
This is really a StratOps problem dressed up as a quality-improvement one. Strategic operations, the function that owns the cadence connecting strategy to execution, is exactly the layer that stops a PDCA cycle (or any improvement loop) from dying quietly after one round. If nobody owns that cadence, PDCA joins the long list of frameworks that worked once and then vanished.
A worked example
Say a 30-person support team wants to cut first-response time. Plan: the hypothesis is that triaging tickets by urgency before assigning them will cut average first response from four hours to two. Do: they trial it on one queue for two weeks. Check: at the fixed fortnightly review, which is the same slot as their existing check-in, average first response on that queue drops to 2.3 hours, close enough to count as a win. Act: they decide to roll triage out to the other three queues, and before the meeting ends they schedule the next check: the same metric, across all four queues, in four weeks.
Rolling that decision straight into next quarter's OKR framework is what actually made the follow-up happen. It wasn't optional homework sitting in someone's notes. It was already on the goal-tracking board with an owner and a date attached, the same way the original pilot was.
Common mistakes
- Treating 'check' as a status update instead of a real comparison against the number the plan predicted.
- Running Plan-Do-Check on repeat without ever doing 'act' properly, the classic 'we ran another pilot' loop.
- Making the cycle so big that 'do' takes a full quarter, by which point nobody remembers what 'plan' actually predicted.
- Letting 'act' become one person's private judgement call instead of a decision made and recorded in front of the team.
Where Tability fits
You don't need new software to run a single PDCA cycle. You do need somewhere for the 'act' decision to land so it doesn't just live in someone's head, and somewhere the next cycle gets scheduled before this one closes. That's what Tability is for: a shared home for the goals, check-ins, and decisions that come out of each Plan-Do-Check-Act loop. Sign up free or book 30 minutes with us and we'll help you work out what a cadence like this looks like for your team.
.png)
.jpg)
