Tag Archives: PDCA

Plan Do Check Act (PDCA) vs. Plan Do Study Act (PDSA): What’s the Difference?

Waiting for a session to begin at the Agile 2011 conference a couple weeks ago, the guy next to me struck up a conversation. What’s your name? What do you do? When he found out I was a college professor with a specialization in quality and quality management he smiled.

“Hey! I have a quality question that’s been on my mind for ages. Maybe you can answer it.”

Side Note: At first I thought he asked whether I liked kickball. I have nerve damage in one of my ears and have hearing problems, especially in large conference rooms with a lot of crowd chatter. I told him I LOVED kickball. After some awkwardness we got back on track.

Should I use PDCA or PDSA?

“So here’s my question,” he said:

“Some people use PDCA (Plan-Do-Check-Act) to structure continuous improvement, but then other people use PDSA (Plan-Do-Study-Act). Are they different? Should you use one instead of the other under different circumstances? Or are some people just getting it wrong?”

Check vs. Study

I was intrigued by this question, because I assumed they were both valid – that PDCA was to be used for straightforward improvement scenarios, and PDSA in more complex scenarios. PDSA should be used when the metrics that you were CHECK-ing required more extensive REFLECTION. I hadn’t thought that the distinction would not be intuitively obvious.

  • CHECK implies that you’re asking the question “How does the state of the system compare to what you were expecting?”
  • STUDY, in contrast, requires you to ask the question “What can we learn from how the state of the system compares to what we were expecting?” The STUDY aspect of PDSA also suggests, albeit a little subtly, that you take what you learned about the system and use that new information to better achieve the goals of the product or process in question.

(Dan Strongin seems to agree, in “PDCA… PDSA, is it as simple as a C or an S?”)

Chicken vs. Egg

But this question also made me realize that I had no idea which came first, PDCA or PDSA? Which was the chicken and which was the egg?

I found the answers I was looking for in Moen & Norman’s November 2010 Quality Progress article entitled “Circling Back.” PDCA emerged from a lecture given by Deming in Japan in 1950. In that presentation, Deming described the continuous improvement cycle proposed by Shewhart in the 1939 book, “Statistical Method from the Viewpoint of Quality Control,” which was based on the scientific method that had emerged much earlier in the 1600’s. It was the Japanese attendees who drew out “PDCA” from Deming’s lecture.

In 1986, Deming amended the description of PDCA. He wanted to emphasize the importance of reflecting on the meaning of whatever metrics you’re checking… and it was here that PDSA emerged. Deming was emphatic about the importance of not just “checking” the state of a system, but using that knowledge to better understand the product or process being improved – hence his recommendation to use PDSA as a natural evolution of PDCA.

Also check out John Hunter’s comments on PDCA, PDSA, and friends.

DMAIC Demystified

The DMAIC (Define-Measure-Analyze-Improve-Control) methodology is one of the cornerstones of a Six Sigma project. It provides a useful heuristic that can remind you how to structure your project when you apply Six Sigma. This is important for two reasons. First, by reminding you to DEFINE your project’s goals, its deliverables to external customers, its deliverables to internal customers, and most important – your definition of a defect – you establish the solid foundation for actually delivering process improvements that meet tangible goals. Second, DMAIC provides a common language for Six Sigma practitioners so that new teams can spend time solving problems instead of searching for their own standard operating procedures.

If you’re familiar with Deming’s PDCA (Plan-Do-Check-Act) cycle, DMAIC is essentially equivalent, but with a very important addition at the end:

  • Planning = Defining
  • Doing = Measuring
  • Checking = Analyzing
  • Acting = Improving
  • (Sustaining/Continually Learning) = Controlling

There’s nothing magical about DMAIC – it’s just a helpful reminder to guide you as you structure a Six Sigma project. And remember that a Six Sigma project is hopefully not the end of the improvement – ideally, a process team will leave behind a new foundation for identifying more efficiencies in the future.