## Intro Plan-Do-Check-Act (PDCA) is a simple, iterative method for improving a known process using measured feedback. This guide compares PDCA with closely related frameworks used by technology leaders: PDSA, DMAIC, Kaizen, OODA, Lean experimentation, and OKRs. You will learn when each is appropriate, how they differ, where PDCA shines, and how to choose with confidence. A practical example, decision tree, comparison table, and ready-to-use templates are included. Practical takeaway: Use PDCA when you have a defined process, measurable outcomes, and the ability to try controlled changes in short cycles. Do not use PDCA as a substitute for strategy, discovery, or goal-setting. ## What PDCA is (and is not) - PDCA is best for: Improving an existing process with observable, timely feedback (for example, reducing deployment failures, shortening incident recovery time, or raising onboarding completion). - PDCA is not: A strategy framework, a goal-setting method, or a discovery process for unknown customer needs. - Prerequisites: A stable-enough process, baseline metrics, an instrumented environment, a clear owner, and the ability to run small changes safely. ## PDCA vs related frameworks at a glance

Framework	Primary problem type	Uncertainty	Baseline required	Typical cycle length	Statistical rigor	Typical outputs	Strengths	Limitations
PDCA	Continuous improvement of a known process	Low to moderate	Yes	Days to weeks	Moderate (before/after checks, control limits)	Standard work updates, control plan, next experiment	Simple, fast, broad applicability	Not a strategy or discovery tool; can chase noise without discipline
PDSA (Plan-Do-Study-Act)	Same as PDCA with stronger emphasis on learning	Low to moderate	Yes	Days to weeks	Moderate to high (explicit learning review)	Learning record, updated theory, next test	Elevates learning over mere checking	Similar scope as PDCA; can feel slower if over-documented
DMAIC (Define-Measure-Analyze-Improve-Control)	Reducing defects/variation in critical processes	Low	Strong, rigorous baseline	Weeks to months	High (statistical analysis, capability)	Validated root causes, improved capability, control plan	Deep root-cause rigor and sustainment	Heavier overhead; slower than PDCA for small bets
Kaizen (continuous improvement culture; Kaizen events)	Many small improvements and standardization	Low	Helpful but not always required	Daily micro-changes; 2–5 day events	Low to moderate	Standard work, 5S, quick wins	Empowers teams; builds improvement habit	Can miss systemic or data-heavy issues
OODA (Observe-Orient-Decide-Act)	Rapid decision in dynamic, adversarial, or high-tempo contexts	High	Situational, not always quantitative	Seconds to days	Low	Timely decisions and actions	Speed and adaptability	Limited depth; not designed for process capability work
Lean experimentation (Build-Measure-Learn)	Product uncertainty; hypothesis testing for value/viability	High	Helpful but discovery often starts with weak baselines	Days to weeks	Moderate (A/B tests, cohort analyses)	Validated learning, product changes	Excellent for product discovery	Not a replacement for operational process improvement
OKRs (Objectives and Key Results)	Direction, alignment, and focus	N/A	Yes for KRs	Quarterly	N/A	Objectives, measurable KRs	Clarifies what matters	Does not tell you how to achieve outcomes; pair with PDCA/DMAIC

Notes: - PDSA is a learning-forward variant of PDCA; many organizations treat them as interchangeable but PDSA explicitly emphasizes the Study step. - DMAIC is heavier but essential when risk, compliance, or cost of defects warrant deep statistical control. - Lean experimentation fits discovery; PDCA fits delivery/process improvement. Use both in their respective domains. ## How to choose: a simple decision tree - Do you need direction and focus before improving anything? - No clear outcomes? Use OKRs first to set Objectives and measurable Key Results. - Is the problem a known process with measurable outputs and quick feedback? - Yes, and stakes are routine: Use PDCA or PDSA. - Yes, and stakes are high with significant variation/defects: Use DMAIC. - Is the problem product uncertainty (what customers value, which feature works)? - Use Lean experimentation (Build-Measure-Learn). - Is the environment fast-moving, adversarial, or ambiguous (e.g., incident command, security response)? - Use OODA for rapid decisions; later stabilize with PDCA/DMAIC. - Is the goal to build a daily habit of small, team-driven improvements? - Use Kaizen (and run PDCA mini-cycles inside it). ## Running PDCA well: a concrete example Scenario (illustrative): A mid-size SaaS company wants to reduce incident mean time to restore (MTTR) for a critical API. Context and assumptions: - Baseline (last 8 weeks): median MTTR 50 minutes; P95 MTTR 6 hours; 8 incidents/week; change failure rate 7%. - Constraints: No extra headcount; must not increase customer-visible error rates during tests. - Owner: SRE lead. Stakeholders: Platform, Security, Product Ops. Plan - Problem statement: MTTR variability is too high at the 95th percentile (6 hours), impacting enterprise SLAs. - Hypothesis: Introducing service-specific runbooks, automated canary rollback, and on-call drills will cut P95 MTTR from 6h to <=4h without raising change failure rate above 8%. - Metrics: - Lagging: P95 MTTR (minutes), SLA breaches (count). - Leading: Runbook coverage (% of top 10 failure modes documented); drill frequency (per team per month). - Diagnostic: Detection time, diagnosis time, rollback execution time. - Guardrail: Change failure rate (%), error budget burn. - Vanity (avoid): Number of wiki pages created. - Scope: Apply to one high-traffic service (Service A) for 4 weeks. - Success threshold: P95 MTTR decrease >= 2 hours vs. baseline for Service A, with guardrails not breached. - Check method: Compare 4-week pilot to 8-week baseline using control charts and non-overlapping confidence intervals for P95 estimate; review incident postmortems for qualitative confirmation. Do - Create runbooks for top 10 failure modes; implement automated canary rollback; run two on-call drills. - Enable change for 100% of Service A; leave other services unchanged (implicit control group). Check - After 4 weeks: Service A P95 MTTR improved to 3.8 hours; median 40 minutes; incidents/week unchanged; change failure rate 7.5% (within guardrail). Postmortems attribute gains mainly to faster rollback. Act - Decision: Standardize canary rollback across all services; keep runbook work-in-progress; schedule monthly drills. Queue next cycle to reduce detection time via better alert thresholds and SLO-based alerts. Next cycle focus - New hypothesis: Tuning SLO-based alerts will cut detection time by 30% without increasing alert fatigue (guardrail: pages/engineer/week <= 5). Why this works - Clear baseline, explicit hypothesis, small safe scope, predefined guardrails, and concrete decision criteria make PDCA fast and trustworthy. ## PDCA templates you can copy PDCA one-pager - Problem statement: - Current baseline (with dates and data source): - Hypothesis (change, expected impact, by when): - Metrics: leading, lagging, diagnostic, guardrails, vanity-to-avoid - Plan (who, what, where, when): - Do (scope, rollout plan, safeguards): - Check (method, timebox, thresholds): - Act (standardize, iterate, or revert): - Owner and review date: Metric definitions - Leading: Moves before the outcome (e.g., runbook coverage). - Lagging: The ultimate outcome (e.g., P95 MTTR). - Diagnostic: Helps localize cause (e.g., diagnosis time). - Guardrail: Ensures no harm while optimizing (e.g., change failure rate). - Vanity: Looks impressive but weakly linked to value (e.g., page count). ## Common failure modes (and fixes) - No baseline or weak instrumentation - Fix: Collect at least 2–4 weeks of stable data; define operational definitions for each metric. - Oversized changes that hide the signal - Fix: Make changes small and isolated; pilot on one service or segment. - Skipping the Check step or changing targets mid-cycle - Fix: Timebox checks; pre-commit thresholds and analysis method. - Optimizing vanity metrics - Fix: Tie metrics to business/customer value and guardrails; drop metrics that do not drive decisions. - Treating discovery as PDCA - Fix: Use Lean experimentation for product unknowns; return to PDCA once a repeatable process exists. - No standardization in Act - Fix: Update standard work, runbooks, dashboards, and training; add a control plan. - Overreacting to random variation - Fix: Use control charts; require minimum effect sizes and sustained changes before rollout. ## When to prefer PDCA, DMAIC, or Lean experimentation - Choose PDCA when you have a stable-enough process, can measure before/after, and need fast, incremental improvements. - Choose DMAIC when defects, cost of failure, or compliance risk demand rigorous root-cause analysis and proven capability gains. - Choose Lean experimentation when the core uncertainty is customer value, problem-solution fit, or which option to build. ## Putting it together with OKRs - OKRs set direction (e.g., Reduce customer-impacting downtime by 50% this quarter). - PDCA runs the improvement cycles that move the Key Results (e.g., P95 MTTR, change failure rate). - Review PDCA results in OKR check-ins; promote successful pilots to standardized practices. ## Conclusion PDCA is your execution engine for continuous improvement on known processes. Use it when you have observable feedback, a defined baseline, and the ability to run small, safe experiments. Reach for DMAIC when you need heavyweight rigor, Lean experimentation when you face product uncertainty, OODA for high-tempo decisions, Kaizen to build daily improvement habits, and OKRs to set direction. Start with a clear hypothesis and guardrails, measure meaningfully, decide decisively, and standardize what works.