Where is the Deming study that asserts most errors are in organization or process?

Question

Organization background: SW development team, painful level of bugs, little process (2 to 3 pts max on Joel Spolsky's 12-point test). I have hard time convincing the team that the organization is defective and not just "devs are incompetent".

I remember E. Deming's claim from his study that most (80%+?) problems originate in process, methods and organization and not in workforce errors, but for the life of me I can't find it by googling. Does smbdy here know the study that is source of such claims?

Answer 1

There is no such study, it is based on Dr. Deming's experience.

http://management.curiouscatblog.net/2013/04/24/94-belongs-to-the-system/

"I should estimate that in my experience most troubles and most possibilities for improvement add up to the proportions something like this: 94% belongs to the system (responsibility of management), 6% special."

Page 315 of Out of the Crisis

Getting hung up on the figure 94% is a mistake. His point was that you improve performance going forward by improving the system not blaming people. His two books provide background and the thought process involved behind why we are failing to manage better. Changing the people, while leaving the system in place, most often doesn't help.

Variation does confuse people sometimes. The same mistake as say yelling at someone any time results are really bad. Most likely results will get better. Not because yelling helps but essentially regression to the mean. So you can move people out after really bad results and things get better. Of course, most of the time they would have gotten better if you left the people there (and did nothing or yelled).

Even when the person did totally mess up, why did the system allow that? Why did the system put that person in a place where they were not qualified? Answering and fixing these types of questions would help improve the system. Yes, occasionally the answer might be Joel was hired sensibly, managed and coached sensibly but he just became a complete jerk and won't respond to coaching and this is only his fault. But normally that won't be the case, the even when the person seems nearly totally to blame (and that isn't even a very common situation - normally there are obvious weaknesses in the system that put them in the place to fail and will likely put anyone else in the same place in the future).

Answer 2

Google Demming, 95/5. This will provide a few links to where you could find some of his work.

The problem you have, however, will not likely be solved by introducing Demming to your bosses. Blaming the people is the easiest thing to do and, when you replace a person or two, demonstrates you are actively managing to the problem. It does not matter whether it will be effective; that can just gets kicked down the road to be dealt with another day.

Interestingly enough, however, when performance is high, we do not typically give credit to the organization. We reward the people, even though the people are not likely why performance is high, or at least with the weight with which we like to celebrate them.

Answer 3

From what you say, your basic problem is that you don't have a team to begin with. A group of groups of people blaming each other is not a team in any case. I see two possibilities:

1. Get the whole team on one table. Confront them with the situation: The team (as a whole!) is performing bad, nobody has a solution, so basically the project is about to fail. The following discussion may become ugly, but also may reach the point where the team understands that they need to change something in order to change the situation. Then you can introduce your ideas.

2. The (lack of) confidence of you developers is a serious problem. I'm pretty sure they are not happy with taking the blame, so they might be the ones most welcoming your proposals. If you start improving management with them, then they will most likely improve and be able to prove it. This robs the rest of the team of the possibility to blame the developers. And that, in turn, makes them (DBAs + admins) become potential scapegoats. That, in combination with the developers's success story might be enough to get the whole team.

Considering how you describe your team situation, I don't have high hopes for any of these possibilities. Honestly, it sounds to me as if the project already failed. But then again, you can barely loose to much from here on...