Interview of John Hunter by Bill Fox, part 1 of 3

The Deming Management System

Bill: When I started my career back in the 1980s, one of the most respected and visible improvement experts was W. Edwards Deming. US manufacturers were under enormous pressure to deal with productivity and quality issues that didn’t seem to exist with Japanese manufacturers. Deming was widely recognized as the person largely responsible for the stunning results of the Japanese manufacturers.

His books were very popular and widely talked about. I picked up a copy of The Deming Management Method to see what I could learn and might apply to my own work. I learned about his techniques for making data based decisions and experimented with his methods in a software development process. The results were stunning.

Since that time I have always held his wisdom in high regards especially since many of his methods have withstood the test of time. While Dr. Deming is no longer with us and his methods aren’t as widely adopted, I was curious to learn how someone experienced in his methods might respond to my questions. I’m pleased to have the opportunity to speak with John Hunter today. John is an expert in the Deming Management methods.

John, what is your best process improvement strategy or tactic that has worked well for you or your clients?

John: I would say the PDSA improvement cycle and a few key practices in using the PDSA properly like predicting the results in the plan stage—something that a lot of the times people do not do—to determine what would be done based on the results of that prediction. 

People discover, especially when they’re new to this stuff, regarding the data that they’re collecting, that maybe even if they got the results they are predicting, they still don’t have enough data to take action. So you figure that even if that number is 30, they would need to know three other things before they make the change. So then, in the plan stage, you can figure that you need to address these other issues, too. At any time that people are collecting data is useful to figure out, for instance: “What do we need to do if the result is 30 or if the result is 3?” And if you don’t have any difference, why are you collecting the data? 

Another important piece is the D in Plan, Do, Study, Act. It means “do the experiment”. A lot of times, people get confused into thinking that D means deploy the results or something like that, but thinking of D as ‘doing the experiment’ can be helpful.  

A really big key between people that use PDSA successfully and those who don’t is that the ones that do it successfully turn the cycle quickly. Doing five 2-week PDSAs is way better than doing one 10-week PDSA. Act is another one that tends to be confusing. It really means deploy the standard process throughout the organization or throughout the area that you’re planning on or decide to adjust and redo –run through the PDSA again. One of those things could be to decide that something is not going to work, and stop. While Act is the act of improving the system or deciding that we need to run the PDSA again. And I find that a lot of times, people don’t do a number of those things in the PDSA, and it makes sense that PDSA isn’t nearly as effective as it could be. 

Bill: What’s interesting to me, John, is that in my part of the world and in the companies I deal with, PDSA is almost a foreign concept. How do you bring it up? How do you bring it to the forefront and make it a focus and a priority?

John: Regarding the practical realities of what happens when you work with entire organizations, there are several things you can do. One of the things I believe is that a number of the concepts, like understanding variation and the tool of control charts, have a lot of rigor – that help make them most effective. 

The concept is more important than the exact details, though, in my opinion. Doing the full PDSA the absolute right way is the best thing to do. But in reality, sometimes that’s difficult, and I think, even just the idea that: “Ok, we have something like a PDSA cycle, and essentially what we are trying to do is experiment an improvement on the system. And in order to do that, we want to pilot on a small scale, we want to test things out, we want to make evidence-based decisions based on real data and see what happens.”

Sometimes you can’t do the full blown PDSA idea because you just can’t get people to buy into that at first. One thing I do is try to put a bunch of more effort into really getting them to do it, or the other is to try to have the concept of PDSA without the rigor. It’s dangerous, and avoiding the details embedded in the PDSA process can lead to problems, but I think you can do that for a while and then, as you have successes, you can put in more of the process that has to be there to make it most effective.

One strategy is you take a bunch of shortcuts at first, use a slimmed down improvement process.  Another option is to decide that PDSA is going to drive everything, I’m going to hang everything of the PDSA, and then you just have to keep plucking away until you get people to buy into it. One advantage of the PDSA is there is an awesome book by Gerald J. Langley, Ron Moen, Thomas Nolan, Cliff Norman and Lloyd Provost, The Improvement Guide, that lays out very well the importance of PDSA and how to do it well, and that can be a big help in trying to sell and implement the idea. 

Bill: I’m just kind of curious. What’s the reaction, once it takes hold and people see it working, what’s that experience like for people? What have you seen there? 

John: What I have seen is not as beautiful as you might hope. It seems to be a continual struggle to get people to use PDSA, even after they’ve had all sorts of wonderful successes and seen it work wonderfully. They still struggle to make those decisions; they still don’t want to go through the process. 

The times when it works most easily and where the organization does buy into it and accept it is organizations that are used to lots of planning and where a lot of times it required to do things – so making mistakes is really costly. Then they really want to improve what is often a very painful process they are using now.

So doing PDSA is frustrating for a lot of people because it takes time, even when you are doing PDSA cycles quickly, you are not going to be deploying it to the whole organization after one tiny little cycle. You are going to do five or six, because you are testing little different things, you are figuring out what’s the best way to work. 

So it’s like a quarter before the things get deployed widely. Now, that isn’t always true. You can deploy things really quickly, but it is difficult for the organization to truly adopt and accept these things at the core. And I think it’s one of the reasons why companies like Toyota can remain so special, even after decades of being very open about exactly what they’re doing, because it is so easy for us to not take advantage of good ideas, and PDSA is one. 

These things have been around for 40 or 50 years. About the only truly innovative thing, I believe, there has been in a long time is Clayton Christensen’s “Disruptive Innovation”, which is more than a decade old. 

There are all sorts of wonderful things that are happening largely in software, like minimum viable product, etc.. There are all sort of neat practices around minimum viable product.  But really, if you look at it, they are just good practices around piloting on a small scale and customer focus. It’s a neat idea and I think it’s helpful, but it’s really an idea that’s decades old that has some new language around it, and I think it has improved a little bit, but it’s a tweak on a good idea and not some brand new idea that we have never had before. 

Bill: I think the people who read my interviews would be very interested in getting an overview of the Deming Management System. 

John: I think that over decades, Deming continued to refine his system, so there are lots of different quotes and lots of different concepts that are very well-known, like the 14 Points and the Seven Deadly Diseases. But the way Deming had it defined at the end was Deming’s System of Profound Knowledge, which had four components that were all interrelated and it was one system. 

You have 

  1) Appreciation for System, which is understanding the organization as a system. 

  2) Knowledge of Variation, which is the evidence-based management; and control charts is one of the things that many are familiar with, but the importance is understanding variation and understanding what that means. Control charts are very useful and very good, but truthfully, especially in the non-manufacturing world, people are resistant to using them. It’s better if they use them, but if they don’t, the important thing is to understand variation, and you can do that without having control charts and all sorts of things. 

  3) Psychology, within the context of managing an organization of people – psychology of human systems, how to take care of people inside of an organization to get the most effective results.

  4) Theory of Knowledge. It’s basically about how we know what we know.  

All of the components are interrelated, so for example we can see how theory of knowledge interacts with say understanding variation. We as people believe that there’s much less variation in the world than there really is, that is our belief. So we make judgments based on a belief that is not accurate. We are very good at matching patterns to things (pulling in psychology), and then say: “Ok. We can locate the cause because we see this pattern.” But we see lots of patterns that aren’t truly causal in nature, so the Theory of Knowledge says that if we make judgments based on the way our brain works that would lead us in the wrong direction. 

If we understand how and why we think things, we can do a better job that relates to psychology and things like confirmation bias. If we see evidence that supports our beliefs, we will remember it and cement our belief more; if we see evidence that contradicts our beliefs, we’ll basically ignore it. So these things all tie together, and the critical piece on Deming’s system is that whole system and how it all ties together, in my opinion.

Bill: That’s a fascinating idea. In fact, I’ve just had a conversation with Hillel Glazer about that point today. We were talking about CMMI with a client, and in most appraisals, people guiding a company on CMMI would go looking for evidence. That’s their frame of mind, they want to see specific evidence. Whereas Hillel takes another approach. If the business is operating, you are being successful, you probably are doing practices already. And he looks more for a demonstration that you are actually doing that, rather than creating something that is sort of an artificial artifact to prove that you were doing it, when in fact, you probably are already doing it and have other types of evidence to show it. 

John: I like the idea of demonstrating what is being done. This whole area gets into something that becomes really tricky. You have sort of the textbook definition for how PDSA should be done; and then you have the real world, where things get in the way, people have strengths and weaknesses, people have things they don’t like, the organization has its own idiosyncrasies. 

One option is to say: “No. The textbook says it’s supposed to be done this way. By doing it a different way, you are violating the proper procedures and that is wrong.” And I think that the Deming folks tend to have that opinion a little too much. I think the more knowledgeable, sophisticated Deming folks have less of a problem with accepting deviation from the proper method.

One approach is to say: “No. It has to be true.” And the idea of evidence and proof is one where I see this issue come up. I believe that there is more judgment than it is needed in the Deming approach than people want to admit. And Deming focused on a lot of things, like evidence-based management and getting data, but if you really pay attention to Deming, there’s a lot of it where he understands you need judgment, you need knowledge, and it’s difficult to quantify exactly what that means. 

And so, you get these situations in which if you are relying on judgments, and as what you were saying, it’s like: “OK. I’m going to use my judgment to see what you’re doing, although it doesn’t fit the textbook of what I’m supposed to look for on CMMI,” really meets it in principle, so, good, you are doing the right thing, so we should do it this way.

And I think that’s good, and that’s how I think things should be done. But it is more dangerous, because then you can rely too much on that person’s judgment, them being wise. But then, that is sort of our strategy. You don’t need to follow the textbook absolutely perfectly and you have a less experienced person who doesn’t know as much, who doesn’t understand this tiny thing that isn’t very noticeable but that is really going to create a ripple effect of problems. And because I’m not prescribed to some checklist, my judgment, I overlooked that small little thing. So the more you end up relying on judgment, the more open is for error. 

But I think that you have to acknowledge that it is open, and you try to reduce that. When you try to reduce it to zero use of judgment, I think the results are just as bad. You end up following these checklists exactly and can’t deviate from them even when it totally makes sense to deviate from.

Bill: What is the biggest misunderstanding about the Deming Management System you think people have?

John: I would say that there are a couple. The followers that want to pin everything to Deming tend to overlook the complexities and nuances and other things. 

The other problem is that some of the critics latch on to a specific quote from Deming, something like a one-sentence long quote, and then they extrapolate from that one sentence-long quote what that means. And the problem is that Deming has lots of these one-sentence quotes that are very memorable and meaningful and useful, but they don’t capture every nuance and they don’t alone capture what it really means (you need to have the background knowledge to understand it completely). 

They are sort of trying to oversimplify the message into these sound bites, and I find that frustrating. Because those individual quotes are wonderful, but they are limited to one little quote out of hours of videotape, books, articles, and when you don’t understand the context in which that resides, that’s a problem. 

One final point in that is that one of the things that is common among these misunderstandings of the quotes is he was often focused on making a statement based upon what needed to be said given the current state of affairs. So the Seven Deadly Diseases are not the seven deadly diseases as Plato would write them as “forms.”  They are seven deadly diseases based on the fact of how management is operating today.

So it is possible that in some organizations that some deadly disease is not a big deal, or the fact that that deadly disease has been eliminated, in which case, Deming is not saying that this is a deadly disease that must be dealt with, he says: “These are the common things that I have to focus on.”

So Deming was very aware that most people didn’t understand the impact of variation, they made all sorts of errors related to variation, so he focused a lot on the variation. But then, when people think that it’s all about variation, which a lot of people do. I say: “No, that’s not all.” That’s one part. There is a lot of other stuff – and it is all inter-related.

He talked about things being interrelated, the issues with variation relate to psychology, there is a lot of stuff about respect for people, there is stuff about joy and work.

The idea that his message doesn’t work in a knowledgeable environment, there’s no evidence for it at all. It’s based, I believe, upon misunderstanding a few quotes and thinking that standardization means that the standardization for a knowledge work organization would be the same as standardization in a factory. And it’s just not. 

But there’s plenty of stuff that would be standardized in a software development organization: having code standards, automated testing code before it is deployed, continuously deployment of the code, etc..

All sorts of things should be put into a standard operating procedure, the way that things are done, for a knowledge work it will be a bit different in exactly how that is done but the principle is the same. A lot of people in software development are a little confused about what standardizing a process means. It doesn't mean standardizing in a way that some suit has imposed on you things that don't make sense for software development. That's not what Deming wanted. Deming wanted the process to make sense to the workers, whether the workers are the people at the factory floor, whether they are doctors in a surgery or whether they are software developers developing software. That idea I think is consistent across all the domains and how that is done is going to vary by each of those domains, but the concept is the same.

Bill John, thanks for sharing your best strategy for enlightening us on many aspects of the Deming Management method. We had many more things to discuss, so this is part one in a series of three interviews. I’m looking forward to sharing more of our discussion and thank you again for speaking with me!

 

Continue reading part 2, How Does the Deming Management System Fit With Other Management Strategies, and part 3, Leadership While Viewing the Organization as a System, of the interview.

 

 John Hunter – URL: www.johnhunter.com  Twitter: @curiouscat_com

My background includes two primary focuses: management improvement and information technology program management. In my experience improving the performance of organizations I often found the proper application of software tools could make quick, significant improvements. And for the last 15 years my focus has been on management improvement with a concentration in using technology to aid this process. Unfortunately, many attempts to find information technology solutions cause more problems than they create. But with a proper understanding of management, software development and systems thinking significant gains are possible.