PDCA in Non-Deterministic Systems
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.
- What was supposed to happen?
- What did happen and why?
- What can we learn from this? What successes can we sustain and what weaknesses can we improve?
- 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?