Blog

PDCA in Non-Deterministic Systems

by Jamie Flinchbaugh on 10-13-09

When does PDCA not apply? Can we say “not here”? Alan Shalloway attempted to address this for the software community in his blog last week. You can read his full post yourself. Apparently many in the software community (but not all, before you call me out on that) feel that PDCA can’t work because your system is non-deterministic. In other words there are many choices or forks in the road as you go forward.

First, PDCA stands for Plan – Do – Check – Act. I’ll save a deep explanation for another post. Your plan involves an understand of your process, your work, and the outcomes that it drives. Do is to execute it. Check it to understand your results and how they compare to the results you expected. This is where learning occurs. Then once you have the learning, you Act, which might actually be going ‘back to the drawing board’ (I wonder how long that phrase will work considering how many people never saw a drawing board?).

If you don’t think this applies in an unpredictable environment, consider how well the U.S. Army applies it. There are few things more variable than a military mission where your opposing force is always in motion and a major factor in both your plans and your execution. Starting at the National Training Center, the U.S. Army developed the After Action Review. After every mission you are asking essentially 4 questions.

  1. What was supposed to happen?
  2. What did happen and why?
  3. What can we learn from this? What successes can we sustain and what weaknesses can we improve?
  4. What is our new actions or changes?

I find it hard to argue that software development is more unpredictable and variable than this environment, yet they have a built-in PDCA process with a focus on learning, cause-and-effect, and process improvement.

Where have you applied PDCA? What have you had to do to make it work for you?

Comments

  • Hi Jamie,

    We’re going to use PDCA for managing our global workflow as part of our new distributed control model. Process leads at a production location will be responsible for monitoring KPMs/KPIs, taking corrective action when performance is undesirable, ensuring the corrective action fixed the problem, making further adjustments as needed and then repeating the cycle. I chose the PDCA solution in this case because the framework is robust yet easy to understand and deploy across several geograhies and cultures.

    I also like to use PDCA for improvement activities resulting from value stream mapping. PDCA makes for clear status communication. The task owner also has a clear understanding of what is expected. The best part is the often forgotten “did it work?” check is built in.

    Jeff Thell October 13, 2009 at 8:08 am
  • Hi Jamie,

    We’re going to use PDCA for managing our global workflow as part of our new distributed control model. Process leads at a production location will be responsible for monitoring KPMs/KPIs, taking corrective action when performance is undesirable, ensuring the corrective action fixed the problem, making further adjustments as needed and then repeating the cycle. I chose the PDCA solution in this case because the framework is robust yet easy to understand and deploy across several geograhies and cultures.

    I also like to use PDCA for improvement activities resulting from value stream mapping. PDCA makes for clear status communication. The task owner also has a clear understanding of what is expected. The best part is the often forgotten “did it work?” check is built in.

    Jeff Thell October 13, 2009 at 8:08 am
  • Hi Jamie,

    We’re going to use PDCA for managing our global workflow as part of our new distributed control model. Process leads at a production location will be responsible for monitoring KPMs/KPIs, taking corrective action when performance is undesirable, ensuring the corrective action fixed the problem, making further adjustments as needed and then repeating the cycle. I chose the PDCA solution in this case because the framework is robust yet easy to understand and deploy across several geograhies and cultures.

    I also like to use PDCA for improvement activities resulting from value stream mapping. PDCA makes for clear status communication. The task owner also has a clear understanding of what is expected. The best part is the often forgotten “did it work?” check is built in.

    Jeff Thell October 13, 2009 at 8:08 am
  • I use PDCA in marketing which to say the best an unpredictable environment. It provides the structure to get things done and allows everyone to get on the same page. Of course, the page size is A3. 😉

    Joseph T. Dager October 13, 2009 at 8:48 am
  • I use PDCA in marketing which to say the best an unpredictable environment. It provides the structure to get things done and allows everyone to get on the same page. Of course, the page size is A3. 😉

    Joseph T. Dager October 13, 2009 at 8:48 am
  • I use PDCA in marketing which to say the best an unpredictable environment. It provides the structure to get things done and allows everyone to get on the same page. Of course, the page size is A3. 😉

    Joseph T. Dager October 13, 2009 at 8:48 am
  • I’ve been involved with various versions of the Shewhart/Deming cycle for decades, even before I knew a name for it. Since I have been involved with the software industry since 1972, the relative formality with which a PDCA-like approach has been used has varied, but it’s been there.

    These days, I take an Agile approach to process and improvement and feel an effective Agile team does a PDCA-like cycle every day.

    Certainly, if the “Plan” part is intended to address an enterprize wide improvement program, the time frames for each of the “phases” in PDCA will take a while. But then, one of the Principles behind an Agile approach is not to work in such long timeframes, so that visibility of an feedback about results occurs very frequently (i.e., days/weeks not months).

    I think PDCA gets a bad rap in some places because it becomes associated with big “programs” where so much can happen between steps in the cycle that you can attribute success or failure to lots of factors.

    Scott Duncan October 13, 2009 at 10:51 am
  • I’ve been involved with various versions of the Shewhart/Deming cycle for decades, even before I knew a name for it. Since I have been involved with the software industry since 1972, the relative formality with which a PDCA-like approach has been used has varied, but it’s been there.

    These days, I take an Agile approach to process and improvement and feel an effective Agile team does a PDCA-like cycle every day.

    Certainly, if the “Plan” part is intended to address an enterprize wide improvement program, the time frames for each of the “phases” in PDCA will take a while. But then, one of the Principles behind an Agile approach is not to work in such long timeframes, so that visibility of an feedback about results occurs very frequently (i.e., days/weeks not months).

    I think PDCA gets a bad rap in some places because it becomes associated with big “programs” where so much can happen between steps in the cycle that you can attribute success or failure to lots of factors.

    Scott Duncan October 13, 2009 at 10:51 am
  • I’ve been involved with various versions of the Shewhart/Deming cycle for decades, even before I knew a name for it. Since I have been involved with the software industry since 1972, the relative formality with which a PDCA-like approach has been used has varied, but it’s been there.

    These days, I take an Agile approach to process and improvement and feel an effective Agile team does a PDCA-like cycle every day.

    Certainly, if the “Plan” part is intended to address an enterprize wide improvement program, the time frames for each of the “phases” in PDCA will take a while. But then, one of the Principles behind an Agile approach is not to work in such long timeframes, so that visibility of an feedback about results occurs very frequently (i.e., days/weeks not months).

    I think PDCA gets a bad rap in some places because it becomes associated with big “programs” where so much can happen between steps in the cycle that you can attribute success or failure to lots of factors.

    Scott Duncan October 13, 2009 at 10:51 am
  • I’ve used it for personal productivity. I’ve been struggling to find time to write a book, and I’ve blamed it on interruptions from email, phone calls, and other external factors. A thorough PDCA showed me that the damage was self-inflicted — I was the one distracting myself from work — and now I’ve put countermeasures in place to keep me focused on writing.

    Daniel Markovitz October 13, 2009 at 1:28 pm
  • I’ve used it for personal productivity. I’ve been struggling to find time to write a book, and I’ve blamed it on interruptions from email, phone calls, and other external factors. A thorough PDCA showed me that the damage was self-inflicted — I was the one distracting myself from work — and now I’ve put countermeasures in place to keep me focused on writing.

    Daniel Markovitz October 13, 2009 at 1:28 pm
  • I’ve used it for personal productivity. I’ve been struggling to find time to write a book, and I’ve blamed it on interruptions from email, phone calls, and other external factors. A thorough PDCA showed me that the damage was self-inflicted — I was the one distracting myself from work — and now I’ve put countermeasures in place to keep me focused on writing.

    Daniel Markovitz October 13, 2009 at 1:28 pm
  • Thanks everyone for sharing your comments. I’m glad to hear everyone is having some success with PDCA, from the personal application to the organizational. I also wrote a column about PDCA a few years back called The Little Engine That Could because I think if you stick with it long enough then anything is possible. You can check it out here: http://www.assemblymag.com/CDA/Articles/Column/8cbfc02c65b0f010VgnVCM100000f932a8c0____

    Jamie Flinchbaugh October 13, 2009 at 2:59 pm
  • Thanks everyone for sharing your comments. I’m glad to hear everyone is having some success with PDCA, from the personal application to the organizational. I also wrote a column about PDCA a few years back called The Little Engine That Could because I think if you stick with it long enough then anything is possible. You can check it out here: http://www.assemblymag.com/CDA/Articles/Column/8cbfc02c65b0f010VgnVCM100000f932a8c0____

    Jamie Flinchbaugh October 13, 2009 at 2:59 pm
  • Thanks everyone for sharing your comments. I’m glad to hear everyone is having some success with PDCA, from the personal application to the organizational. I also wrote a column about PDCA a few years back called The Little Engine That Could because I think if you stick with it long enough then anything is possible. You can check it out here: http://www.assemblymag.com/CDA/Articles/Column/8cbfc02c65b0f010VgnVCM100000f932a8c0____

    Jamie Flinchbaugh October 13, 2009 at 2:59 pm
  • Hi Jamie,

    AAR (After Action Review) is just another form of PDCA and it clearly states the goal:

    Learn from your past actions!

    It will take some time to commit to it. Saving people away due to your lean efforts will counterattack the improvement in the long-run!

    Beware that your people are the most precious asset in your organization (whether private sector, public sector, production or service, doesn’t matter).

    ..only these guys can do the AAR or PDCA;-)

    Cheers,

    Ralf

    PS.: Perhaps there is a future time when “The Singularity is Near” and robots will be enabled to overtake – not now though!

    RalfLippold October 13, 2009 at 2:59 pm
  • Hi Jamie,

    AAR (After Action Review) is just another form of PDCA and it clearly states the goal:

    Learn from your past actions!

    It will take some time to commit to it. Saving people away due to your lean efforts will counterattack the improvement in the long-run!

    Beware that your people are the most precious asset in your organization (whether private sector, public sector, production or service, doesn’t matter).

    ..only these guys can do the AAR or PDCA;-)

    Cheers,

    Ralf

    PS.: Perhaps there is a future time when “The Singularity is Near” and robots will be enabled to overtake – not now though!

    RalfLippold October 13, 2009 at 2:59 pm
  • Hi Jamie,

    AAR (After Action Review) is just another form of PDCA and it clearly states the goal:

    Learn from your past actions!

    It will take some time to commit to it. Saving people away due to your lean efforts will counterattack the improvement in the long-run!

    Beware that your people are the most precious asset in your organization (whether private sector, public sector, production or service, doesn’t matter).

    ..only these guys can do the AAR or PDCA;-)

    Cheers,

    Ralf

    PS.: Perhaps there is a future time when “The Singularity is Near” and robots will be enabled to overtake – not now though!

    RalfLippold October 13, 2009 at 2:59 pm
  • Ralf, I don’t know about the robot thing but yes, AAR is just a specific application of PDCA. It can take some time. It will take some time. But it doesn’t have to be a lot of time. We’ve had groups start with just 10 minutes a week. The improvements were small but still worth the effort.

    Jamie

    Jamie Flinchbaugh October 13, 2009 at 3:13 pm
  • Ralf, I don’t know about the robot thing but yes, AAR is just a specific application of PDCA. It can take some time. It will take some time. But it doesn’t have to be a lot of time. We’ve had groups start with just 10 minutes a week. The improvements were small but still worth the effort.

    Jamie

    Jamie Flinchbaugh October 13, 2009 at 3:13 pm
  • Ralf, I don’t know about the robot thing but yes, AAR is just a specific application of PDCA. It can take some time. It will take some time. But it doesn’t have to be a lot of time. We’ve had groups start with just 10 minutes a week. The improvements were small but still worth the effort.

    Jamie

    Jamie Flinchbaugh October 13, 2009 at 3:13 pm
  • I’ve used it for my route to a location. Talk about variability, complexity, and unpredictability. I think the important thing to remember is that the only truly random processes that we have proven are on a quantum scale. Everything (for our practical purposes) has some level of predictability. If there is some level of predictability then PDCA can apply.

    Ankit

    Ankit October 13, 2009 at 3:26 pm
  • I’ve used it for my route to a location. Talk about variability, complexity, and unpredictability. I think the important thing to remember is that the only truly random processes that we have proven are on a quantum scale. Everything (for our practical purposes) has some level of predictability. If there is some level of predictability then PDCA can apply.

    Ankit

    Ankit October 13, 2009 at 3:26 pm
  • I’ve used it for my route to a location. Talk about variability, complexity, and unpredictability. I think the important thing to remember is that the only truly random processes that we have proven are on a quantum scale. Everything (for our practical purposes) has some level of predictability. If there is some level of predictability then PDCA can apply.

    Ankit

    Ankit October 13, 2009 at 3:26 pm
  • Hi Jamie,

    Very nice post. I think the resistance to PDCA comes down to the fact that most people don’t plan. We think we plan but it’s often merely justifying the action they intend to take, not the result of understanding the current condition and analyzing root causes; those non-deterministic forks can be mapped out as scenarios and hypotheses to test.

    Capturing the cost of poor quality is essential for software and other creative enterprises such as product development. Planning may hurt for right brain enabled people, but it’s the ounce of prevention.

    Jon Miller October 14, 2009 at 4:55 pm
  • Hi Jamie,

    Very nice post. I think the resistance to PDCA comes down to the fact that most people don’t plan. We think we plan but it’s often merely justifying the action they intend to take, not the result of understanding the current condition and analyzing root causes; those non-deterministic forks can be mapped out as scenarios and hypotheses to test.

    Capturing the cost of poor quality is essential for software and other creative enterprises such as product development. Planning may hurt for right brain enabled people, but it’s the ounce of prevention.

    Jon Miller October 14, 2009 at 4:55 pm
  • Hi Jamie,

    Very nice post. I think the resistance to PDCA comes down to the fact that most people don’t plan. We think we plan but it’s often merely justifying the action they intend to take, not the result of understanding the current condition and analyzing root causes; those non-deterministic forks can be mapped out as scenarios and hypotheses to test.

    Capturing the cost of poor quality is essential for software and other creative enterprises such as product development. Planning may hurt for right brain enabled people, but it’s the ounce of prevention.

    Jon Miller October 14, 2009 at 4:55 pm
  • “Apparently many in the software community”

    More precisely that would be the Scrum community and even then perhaps only the official Scrum community.

    Jason Yip October 21, 2009 at 5:38 am
  • “Apparently many in the software community”

    More precisely that would be the Scrum community and even then perhaps only the official Scrum community.

    Jason Yip October 21, 2009 at 5:38 am
  • “Apparently many in the software community”

    More precisely that would be the Scrum community and even then perhaps only the official Scrum community.

    Jason Yip October 21, 2009 at 5:38 am
  • Jason, that’s a fair correction. Although in my experience, the broad software community does have more than their share of “that doesn’t apply here” and “we’re different” than they should.

    Jamie Flinchbaugh October 21, 2009 at 7:36 am
  • Jason, that’s a fair correction. Although in my experience, the broad software community does have more than their share of “that doesn’t apply here” and “we’re different” than they should.

    Jamie Flinchbaugh October 21, 2009 at 7:36 am
  • Jason, that’s a fair correction. Although in my experience, the broad software community does have more than their share of “that doesn’t apply here” and “we’re different” than they should.

    Jamie Flinchbaugh October 21, 2009 at 7:36 am