{"id":143,"date":"2026-06-17T13:17:27","date_gmt":"2026-06-17T13:17:27","guid":{"rendered":"https:\/\/sigmadesk.app\/blog\/?p=143"},"modified":"2026-06-17T13:17:28","modified_gmt":"2026-06-17T13:17:28","slug":"pdca-cycle","status":"publish","type":"post","link":"https:\/\/sigmadesk.app\/blog\/pdca-cycle\/","title":{"rendered":"PDCA Cycle (Plan-Do-Check-Act) Explained"},"content":{"rendered":"\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<figure class=\"wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio\"><div class=\"wp-block-embed__wrapper\">\n<iframe loading=\"lazy\" title=\"PDCA (Plan-Do-Check-Act) Cycle Explained | Real World Example\" width=\"500\" height=\"281\" src=\"https:\/\/www.youtube.com\/embed\/fDfpsCZyIdA?feature=oembed\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen><\/iframe>\n<\/div><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Most problem-solving fails in one of two ways. Either a team rushes straight to a solution before it understands the problem, or it installs a fix and never checks whether the fix actually worked. Both feel like progress. Neither is.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The <strong>PDCA cycle<\/strong> closes both of those gaps. It&#8217;s a structured, four-step method \u2014 <strong>Plan, Do, Check, Act<\/strong> \u2014 that takes you from a problem, to a tested change, to a verified solution. Its simplicity is exactly why it endures. And because the four steps close into a loop, the same method that solves one problem also drives ongoing improvement, with each pass teaching you something that feeds the next.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This guide walks through what PDCA is, why it works, each of the four stages and the tools that power them, a complete real-world example, and how to know when PDCA is the right choice \u2014 and when you should reach for a heavier methodology instead.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What Is the PDCA Cycle?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">PDCA is a disciplined sequence for solving problems and improving processes. You <strong>Plan<\/strong> a change, <strong>Do<\/strong> it on a small scale, <strong>Check<\/strong> the results against what you expected, and <strong>Act<\/strong> on what you learned \u2014 either standardizing the win or refining your approach and going around again.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">It&#8217;s often called the <strong>Deming cycle<\/strong>, after William Edwards Deming, who popularized it. Deming himself credited his mentor, <strong>Walter Shewhart<\/strong>, which is why you&#8217;ll also see it called the <strong>Shewhart cycle<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The power of PDCA comes from a single discipline it imposes: it forces you to plan <em>before<\/em> acting, and to verify <em>before<\/em> declaring victory. Just as importantly, because it loops, a &#8220;failed&#8221; cycle is never wasted effort. A change that didn&#8217;t work is simply data for the next round.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">The Four Stages of PDCA at a Glance<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Stage<\/th><th>Core question<\/th><th>Common tools<\/th><\/tr><\/thead><tbody><tr><td><strong>Plan<\/strong><\/td><td>What is the real problem, and what change should we test?<\/td><td>Fishbone diagram, Five Whys, Pareto analysis, SIPOC, process mapping<\/td><\/tr><tr><td><strong>Do<\/strong><\/td><td>What happens when we try the change on a small scale?<\/td><td>Standard work instructions, check sheets, pilot trials<\/td><\/tr><tr><td><strong>Check<\/strong><\/td><td>Did the change actually work, and was it significant?<\/td><td>Control charts, run charts, histograms, hypothesis testing<\/td><\/tr><tr><td><strong>Act<\/strong><\/td><td>Do we standardize the win or refine and loop again?<\/td><td>Standardized work, control plans, poka-yoke<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Plan: Define the Problem and Its Root Cause<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Plan is the foundation of the entire cycle, and it&#8217;s where most of the thinking happens. Here you clearly define the problem and dig down to its <strong>root cause<\/strong> rather than its symptoms.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This is where the analytical Lean and Six Sigma toolkit earns its keep. A <a href=\"https:\/\/claude.ai\/blog\/fishbone-diagram-ishikawa-root-cause-analysis\/\" target=\"_blank\" rel=\"noopener\">Fishbone (Ishikawa) diagram<\/a> organizes possible causes, the Five Whys drills past surface explanations, Pareto analysis points you to the vital few causes that drive most of the pain, and SIPOC and process mapping show how the work actually flows.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Once the root cause is understood, you decide on a <strong>countermeasure<\/strong> \u2014 the specific change you believe will fix the issue or remove a process weakness \u2014 and prepare to test it in the next stage. Setting a <strong>measurable target<\/strong> here is essential, because it gives you a clear benchmark to judge success against later.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Do: Test the Change on a Controlled Scale<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Do is about implementing the planned change on a deliberately small scale \u2014 a pilot project, a trial on a single production line, or a test during one shift. <strong>Standard work instructions<\/strong> and <strong>check sheets<\/strong> keep the trial consistent and make sure you collect clean, accurate data throughout.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The objective at this stage is not a full rollout. It&#8217;s to gather evidence under real operating conditions while keeping risk low. Document exactly what was done, including any deviations from the original plan \u2014 those details become essential when you interpret the results in the next stage.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Check: Compare Results Against Expectations<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Check is where you hold the actual results up against your target. Tools such as <strong>control charts<\/strong>, <strong>run charts<\/strong>, <strong>histograms<\/strong>, and <strong>hypothesis testing<\/strong> turn raw numbers into meaningful insight.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This stage answers a few key questions:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Did the performance metric actually improve?<\/li>\n\n\n\n<li>Was the improvement large enough to matter?<\/li>\n\n\n\n<li>Were there any unintended consequences or surprises?<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Control charts are particularly valuable here, because they separate a genuine, sustained improvement from ordinary day-to-day variation \u2014 the difference between a real win and a lucky week. <em>(This is exactly the kind of analysis you can run in <a href=\"https:\/\/sigmadesk.app\/\">SigmaDesk<\/a>, which builds control charts, capability studies, and SPC tools straight from your data.)<\/em><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Act: Standardize the Win or Refine and Loop<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Act decides what happens next based on what the Check stage revealed.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If the change worked, you <strong>standardize<\/strong> it: update procedures, train the people who do the work, and make the new method the default way of working. <strong>Standardized work<\/strong>, <strong>control plans<\/strong>, and <strong>poka-yoke<\/strong> (mistake-proofing) keep the improvement from quietly slipping back over time.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If the results were unsatisfactory, the findings feed back into a refined hypothesis and a fresh PDCA cycle. Either way the loop continues \u2014 there is almost always another opportunity to improve or optimize a little further.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">When to Use PDCA (and When to Use DMAIC)<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">PDCA is at its best on <strong>fast, contained problems<\/strong>. It suits daily operational issues, quick experimentation, and any situation where you learn the most by testing a small change and watching what happens. Its light structure lets a team finish a complete cycle in days or weeks \u2014 which is precisely what day-to-day continuous improvement needs.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For larger or more complex problems \u2014 where the root cause is genuinely unclear and the analysis demands heavier statistical tools \u2014 a more rigorous methodology like <a href=\"https:\/\/sigmadesk.app\/blog\/lean-six-sigma-and-dmaic\/\">DMAIC<\/a> is the better fit.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The two aren&#8217;t rivals. <strong>PDCA handles the steady stream of small, fast improvements, while DMAIC tackles the chronic, high-stakes problems that need deeper investigation.<\/strong> Mature improvement cultures run both.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Most problem-solving fails in one of two ways. Either a team rushes straight to a solution before it understands the problem, or it installs a fix and never checks whether the fix actually worked. Both feel like progress. Neither is. The PDCA cycle closes both of those gaps. It&#8217;s a structured, four-step method \u2014 Plan, [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-143","post","type-post","status-publish","format-standard","hentry","category-educational"],"_links":{"self":[{"href":"https:\/\/sigmadesk.app\/blog\/wp-json\/wp\/v2\/posts\/143","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sigmadesk.app\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sigmadesk.app\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sigmadesk.app\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sigmadesk.app\/blog\/wp-json\/wp\/v2\/comments?post=143"}],"version-history":[{"count":1,"href":"https:\/\/sigmadesk.app\/blog\/wp-json\/wp\/v2\/posts\/143\/revisions"}],"predecessor-version":[{"id":144,"href":"https:\/\/sigmadesk.app\/blog\/wp-json\/wp\/v2\/posts\/143\/revisions\/144"}],"wp:attachment":[{"href":"https:\/\/sigmadesk.app\/blog\/wp-json\/wp\/v2\/media?parent=143"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sigmadesk.app\/blog\/wp-json\/wp\/v2\/categories?post=143"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sigmadesk.app\/blog\/wp-json\/wp\/v2\/tags?post=143"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}