What Is the PDCA Cycle? Phases, Examples, and How to Make It Stick (2026)

Most teams do not fail at improvement because they lack ideas. They fail because the ideas never come back around: a fix gets proposed in a meeting, everyone nods, and three weeks later nobody remembers what was decided or whether it worked. The PDCA cycle exists to close exactly that loop.

This guide covers what the PDCA cycle is, how each of the four phases works in practice, real examples from sales and product teams, the five reasons cycles stall, an honest look at the "PDCA is outdated" debate, how it compares to OODA and OKR, a template you can copy, and how AI meeting records take over the two phases teams most often drop: Check and Act.

⚠️ This article was independently compiled based on publicly available information and user feedback as of September 2026.

Table of Contents

1. What is the PDCA cycle?
2. The four phases in detail
3. PDCA examples from real teams
4. Why PDCA stalls: five common failure patterns
5. Is PDCA outdated?
6. PDCA vs. OODA, KPT, and OKR
7. A PDCA template you can copy
8. A checklist before your first cycle
9. Automating Check and Act with AI meeting records
10. Frequently asked questions
11. Conclusion

What is the PDCA cycle?

The PDCA cycle is a four-phase method for continuous improvement: Plan a change, Do it on a small scale, Check the results against what you expected, and Act on what you learned, then start the next cycle. It is deliberately a loop, not a checklist. One pass through the four phases is not the goal; the goal is that each pass leaves your process slightly better than the last one, and that the learning compounds.

The method has a longer history than most business frameworks. It grew out of the work of Walter Shewhart at Bell Labs in the 1930s and was popularized by W. Edwards Deming, who taught it to Japanese manufacturers in the 1950s. It became the backbone of Japanese quality management and later of lean manufacturing worldwide. Deming himself preferred the term PDSA, with "Study" instead of "Check," precisely because he worried teams would treat Check as a pass/fail inspection rather than a learning step. That worry, as we will see, was justified.

One framing question separates teams that benefit from PDCA from teams that just draw the circle on a slide: PDCA is a hypothesis test, not a to-do list. The Plan phase is not "list the tasks"; it is "state what change you expect to produce what result, by when, measured how." If your plan contains no prediction, your Check phase has nothing to check, and the cycle quietly degrades into plain task management.

The four phases in detail

• Plan: define the problem, the change, and the expected result. A usable plan answers four questions. What exactly is the problem, in numbers where possible? What change will we try? What result do we expect, by when? How will we measure it, and where does that data live? A plan like "improve response time" fails this test. A plan like "route all inbound demo requests to a shared queue; we expect first-response time to drop from 9 hours to under 2 within three weeks, measured in the helpdesk dashboard" passes it.
• Do: run the change small, and log what actually happened. The classic mistake is rolling a change out to the whole team before it has survived contact with reality. Run it with one squad, one region, or one week of traffic first. Just as important: record deviations as they happen. If the new process was skipped on busy days, that fact is Check-phase gold, and it will be forgotten by next month unless someone writes it down.
• Check: compare results against the prediction, not against vibes. This is the phase teams skip most, and skipping it converts PDCA into PD-PD-PD: an endless stream of changes with no idea which ones worked. A real Check answers three questions. Did the metric move as predicted? What went differently from the plan, and why? What did we learn that we did not know before? Note that "the metric did not move" is a successful Check; you have falsified a hypothesis cheaply.
• Act: standardize, adjust, or abandon, explicitly. Act has exactly three outcomes. Adopt: the change worked, so it becomes the new standard and gets documented and rolled out. Adjust: the idea seems right but the execution needs a modification, which becomes the next cycle's Plan. Abandon: the hypothesis was wrong, so retire the change and write down why. All three are legitimate. The only failure mode in Act is silence, where the pilot just continues indefinitely with no decision.

PDCA examples from real teams

Abstract cycles are hard to copy, so here are two concrete ones.

A sales team attacking a low follow-up rate.

• Plan: Only 40% of discovery calls receive a follow-up email within 24 hours. Hypothesis: if follow-ups are drafted from the meeting notes on the same day, the rate reaches 90% within one month, measured in the CRM.
• Do: For two weeks, one pod drafts follow-ups directly from AI meeting notes right after each call. Deviation log: two reps skipped the process during a conference week.
• Check: Follow-up rate for the pod hit 85% versus 42% for the control pods. Reply rates also rose. The 24-hour target was missed mainly on days with more than four calls.
• Act: Adopt for the whole team, with one adjustment queued as the next Plan: batch drafting at 4 p.m. daily instead of after each call.

A product team fighting recurring release-day incidents.

• Plan: Three of the last five releases caused hotfixes within 48 hours. Hypothesis: a 30-minute pre-release checklist review will cut release-week hotfixes to zero over the next two releases.
• Do: Run the review before the next two releases; log every checklist item that catches something.
• Check: One release was clean; one still needed a hotfix, caused by a config change that the checklist did not cover. The checklist caught four other issues pre-release.
• Act: Adjust, not adopt: add config diffs to the checklist and run the cycle again for two more releases.

Notice what makes both examples work: the plan contains a number and a deadline, the Do phase logs deviations, and Check compares against the original prediction rather than a general feeling that things improved.

Why PDCA stalls: five common failure patterns

• The plan has no prediction. "Try the new onboarding flow" is a task, not a hypothesis. Without an expected result and a metric, Check becomes an opinion exchange. Fix: refuse to start Do until the plan states "we expect X to change to Y by date Z."
• Check never happens. The pilot launches, attention moves on, and nobody books the review. Fix: schedule the Check meeting at the same time you approve the Plan, before the Do phase starts. A cycle without a Check date on the calendar is a cycle that will not close.
• The decisions evaporate. The team does review results, but the conclusions live in someone's memory. A month later the same debate replays from scratch. Fix: keep a written cycle log with the plan, results, and the Act decision, and open the next review by reading the last entry.
• Cycles are too long. A quarter-long cycle means four learning opportunities per year, and by review time nobody remembers the details. Fix: default to two-to-four-week cycles; reserve quarterly reviews for aggregating what the short cycles taught you.
• Check turns into blame. If a failed hypothesis is treated as someone's mistake, people stop proposing measurable plans, because a vague plan can never be proven wrong. Fix: judge the process, not the people, and celebrate cleanly falsified hypotheses as cheap learning.

Is PDCA outdated?

Search for PDCA and you will quickly meet the claim that it is old-fashioned, too slow for modern business, and superseded by OODA or agile methods. The criticism deserves a straight answer, because it is half right.

The valid half: PDCA fits poorly where conditions change faster than a cycle can complete. In a live incident, a fast-moving negotiation, or a competitive situation that shifts daily, you do not have three weeks to test a hypothesis; frameworks built for rapid orientation, like OODA, fit better there. PDCA is also frequently practiced badly, as an annual planning ritual with a perfunctory Check, and critics are right that this version produces paperwork instead of improvement.

The invalid half: for repeatable processes that you control, hypothesis-driven iteration has not aged at all. What modern product teams call build-measure-learn or growth experimentation is structurally PDCA with new vocabulary: state a hypothesis, ship a small change, measure against the prediction, decide. The framework is not outdated; long cycles and skipped Checks are. If your cycles run two to four weeks and every cycle ends with an explicit Act decision, you are doing exactly what the "modern" alternatives prescribe.

The practical conclusion: keep PDCA for processes you own and can measure, use OODA-style thinking for fast reactive situations, and treat any PDCA implementation with a cycle longer than a month as a design flaw rather than a reason to abandon the method.

PDCA vs. OODA, KPT, and OKR

These frameworks are often presented as rivals, but they answer different questions and combine well.

A combination that works in practice: OKRs define where you want to go this quarter. PDCA cycles are how you experiment your way toward those key results. KPT is the meeting format many teams use to run the Check and Act discussion. OODA is what you switch to when something is on fire and hypothesis testing is a luxury.

A PDCA template you can copy

Paste this into your team's shared workspace and duplicate it per cycle.

# PDCA Cycle ― [process/team] ― Cycle #[n]
Owner: [name]   Cycle period: [start] → [end]   Check meeting: [date, booked]

## Plan
- Problem (with numbers): [current state]
- Change we will try: [one sentence]
- Prediction: we expect [metric] to go from [X] to [Y] by [date]
- Data source for the metric: [dashboard/report]

## Do (fill during the cycle)
- Started: [date]   Scope: [team/segment piloting it]
- Deviation log: [what was skipped or changed, and when]

## Check (fill at the review)
- Result: [metric before → after, vs. prediction]
- What differed from the plan and why:
- What we learned:

## Act (choose one, explicitly)
- [ ] Adopt ― roll out as the new standard; documented at: [link]
- [ ] Adjust ― next cycle's plan: [one sentence]
- [ ] Abandon ― reason recorded: [one sentence]

Three usage notes. Book the Check meeting when you write the Plan, not after the Do phase. Keep the deviation log during Do, because those notes are what make Check honest. And force exactly one box in Act; an unticked Act section means the cycle never closed.

A checklist before your first cycle

• Is the problem stated with a number, not an adjective?
• Does the plan predict a specific result with a deadline?
• Is the metric's data source agreed before the pilot starts?
• Is the pilot scope small enough to fail safely?
• Is the Check meeting already on the calendar?
• Is one person named as the cycle owner?
• Is the cycle four weeks or shorter?
• Is there a written place where this cycle's log will live?

If you can tick all eight, your first cycle will already be ahead of most PDCA implementations.

Automating Check and Act with AI meeting records

Look back at the failure patterns above and a pattern emerges: PDCA rarely dies in Plan or Do. It dies in the connective tissue, where results are discussed in meetings, decisions are made verbally, and none of it is captured. The Check meeting happens; the record of it does not.

This is the part an AI meeting assistant removes cleanly. SuperIntern is a botless desktop app for Mac and Windows that records meetings directly from your device audio, with no bot joining the call. That means it works identically across Zoom, Google Meet, Microsoft Teams, and Webex, and in the conference room where many Check discussions actually happen.

For PDCA specifically:

• Teach the AI Canvas your cycle format once. Tell it "this is a PDCA review; capture results vs. prediction, deviations, learnings, and the Act decision with an owner," and every review meeting produces a structured cycle log in real time, while everyone stays in the discussion instead of taking notes.

• The Act decision is captured the moment it is spoken. "Let's adopt the queue and revisit the batching idea next cycle" lands in the notes as a decision with an owner, not as something someone hopefully remembers.
• Past cycles stay queryable. Before the next review, ask the cross-meeting AI chat "what did we decide in the last three PDCA reviews for the onboarding process, and what predictions are still open?" and open the meeting with the answer.
• Distributed teams check in one language. With real-time translation across 50+ languages, a Check meeting between offices does not need a shared native language, and each side reads the summary in their own.

To be honest about scope: SuperIntern is a live meeting recorder and note-taker, not a metrics dashboard or a project management tool. The numbers in your Check phase still come from your own analytics; many teams then push the resulting action items to tools like Linear or Jira through SuperIntern's MCP integration with agents such as Claude or ChatGPT. There is a free plan, so trying it on your next review meeting costs nothing.

Frequently asked questions

What does PDCA stand for?

Plan, Do, Check, Act: plan a change with a predicted result, run it on a small scale, check the outcome against the prediction, and act on the learning by adopting, adjusting, or abandoning the change.

What is the difference between PDCA and PDSA?

They are the same cycle with one renamed phase. W. Edwards Deming preferred "Study" over "Check" to stress that the third phase is about learning from results, not inspecting for pass/fail. If your Check phase asks "what did we learn?", the distinction is already covered.

How long should one PDCA cycle take?

Two to four weeks is a good default for business processes. Long enough for a metric to move, short enough that details are fresh at the review. Quarter-long cycles are the single most common self-inflicted reason PDCA feels slow.

Is PDCA still relevant, or has OODA replaced it?

They solve different problems. OODA is built for fast, reactive situations where orientation matters more than measurement. PDCA is built for deliberate improvement of processes you control. Modern experiment-driven product work is structurally PDCA regardless of what it is called.

Why do most PDCA efforts fail?

The two dominant causes are plans without predictions, which make Check impossible, and Check meetings that never get scheduled or recorded, which means learning evaporates. Both are fixable with process design rather than more effort.

Can one person use PDCA, or is it only for teams?

It works at any scale. A personal version, planning one change to your workweek, running it, and reviewing it on Friday, is a low-stakes way to build the habit before introducing it to a team.

Conclusion

PDCA has survived ninety years not because it is sophisticated but because it is the minimum honest structure for improvement: predict, try, compare, decide. Teams that struggle with it are almost never struggling with the concept; they are struggling with plans that predict nothing, Checks that never convene, and decisions that evaporate on the way out of the meeting room.

Fix those three, and the cycle starts compounding. State every plan as a prediction with a number and a date. Book the Check meeting before the Do phase begins. And let the meeting record write itself, so that Act decisions survive longer than the memory of the people who made them.

Try SuperIntern Free ― botless AI meeting notes that capture your Check results and Act decisions in real time, and keep every cycle searchable for the next review.