PDCA vs. PDSA: What’s the Difference?

I was waiting for a session to begin at the Agile 2011 conference a couple weeks ago when the guy next to me struck up a conversation. What’s your name? What do you do? (You know, typical questions one conferencegoer will ask another to more comfortably pass the in-between time.) When he found out I was a college professor with a specialization in quality and quality management he said “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 some nerve damage in one of my ears, which means I have a hearing problem, especially in a large conference room where there’s a lot of crowd chatter. I told him I LOVED kickball. After he contorted his face and gave me the furrowed eye of confusion, I asked him to repeat the question, got a clarification of the question (OOPS), explained my auditory predicament, and we quickly got back on track.

“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?”

I was really intrigued by this question, because my assumption had always been that they were both valid methodologies – only that PDCA was to be used for more straightforward improvement scenarios, and PDSA was to be applied in more complex scenarios – when the metrics that you were CHECK-ing and the environmental conditions surrounding those metrics 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?”)

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 quickly 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, he described his interpretation of 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. As described by Moen & Norman, the characterization of this approach as PDCA was a further interpretation of the lecture by the Japanese attendees.

In 1986, Deming amended his description of PDCA to emphasize the importance of reflecting on the meaning of whatever metrics you’re checking, and thus PDSA emerged. Deming was emphatic about the importance of not just checking, 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.



  • Pingback: Quality Soup « Quality and Innovation

  • Pingback: College Football Rule Changes and PDSA | Lean Blitz – Do it better.

  • How about the use of “Adjust” vs. “Act”?

  • I need this information – PDCA VS. PDSA

  • I find this article (and some of related papers by Moen and Norman) of interest as I’m currently writing about game-based lean production training.

    When the interpretation of the “A” or the “C/S” confuses professionals, how do we use PDCA/PDSA to support industrial blue-collar workers or university students in their training?

    The answer is, I don’t.

    Somehow, PDCA/PDSA is used for anything from small-step improvements to strategic business level, which adds to the confusion. Moreover, PDCA/PDSA tends to be prescriptive with a number of steps in each phase.

    I prefer to use a model that describes how the participants carry out their tasks in the training environment and in their (future) workplace.

    • Hi Leo. I have really unsettled feelings towards PDCA/PDSA… to me, both of them are kind of used as a crutch (e.g. “We do PDCA”) instead of a model for good hygiene (e.g. “We always collect good data, evaluate it in terms of available options and the problem context, implement adjustments based on recommendations, and then revisit it later.”) I think the best way to “use it” is, like you said, to create good procedures that bake the hygiene in. Is that what you’re saying?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s