Over recent weeks I have had several conversations about PDCA – Plan, Do, Check, Act – and whether or not it is helpful as an approach to problem solving. PDCA has its roots in the work of Deming in the 1950s where it evolved from his thinking on a manufacturing cycle: from design, production, sales and research. Its adaptation for use in problem solving resulted in the four steps:
- Plan – define the problem, understand it and develop solutions
- Do – implement those solutions
- Check – see if the problem has been solved
- Act – standardise the solution if it has worked, or go back to ‘Plan’
PDCA is widely used as a problem solving framework in many Lean implementations, but, for me, it just doesn’t work! For real people, trying to solve real problems, it simply doesn’t tell you how to go about solving a problem. You always have to ‘drill it down’ to another level of detail that describes what people actually have to do. The other issue I have with it is that a large part of the problem solving process takes place in ‘Plan’. It’s quite right that the majority of effort should be spent on analysing a problem and developing viable solutions, but putting all this into one step masks the reality of the process and risks over-simplifying it to the extent that people may leap to quick fix solutions without doing the necessary definition and analysis.
The reality is that all the really effective problem solving processes have significantly more than four steps, once you translate PDCA into something that people can use. You could do worse than start with DMAIC from Six Sigma (Define – Measure – Analyse – Improve – Control); at least people can get more meaning about what needs to be done.
It’s also important to point out that DMAIC is unlikely to be a straightforward, linear process. D, M and A often require some iteration, for example when measurement or analysis throw up some issues about the original definition.
So, although PDCA is fine in principle, I don’t think it’s that helpful on a day-to-day basis. It feels to me that some of the Lean enthusiasts are falling into Deming’s trap of using slogans and exhortation because they are so obsessed with the methodology. They “have to” use PDCA and they will use it whether or not people in the process “get it” or not.
Over the years I have designed and run countless workshops to help people learn how to solve problems using a combination of analysis and creativity, and also facilitated improvement teams that have successfully reduced cycle-times, eliminated waste and improved customer satisfaction. All of them have achieved that by using problem solving approaches that go well beyond the unhelpful simplicity of PDCA.
[Addendum: I was reminded, by Ian Gotts @iangotts, of the alternative definition of PDCA: Plan, Delay, Cancel, Apologise; often applied to IT projects! Thanks Ian]