Well, I am, for one.
Don’t misunderstand – for any given good or service I procure, I want the highest possible quality version, and become quite frustrated when the things I buy end up failing in executing their purposes, either in effectiveness or lack of longevity. Like anyone else, I tend to avoid those vendors who sharply disappoint me, usually forever.
“So,” I can hear GTIM Nation say, “why do you claim to be against quality?”
Because of the way it has been shoe-horned into the Project Management codex, that’s why. Examples follow.
The first reason I find Quality Management experts highly off-putting has to do with their tools, especially the Ishikawa, or fishbone diagram. According to WhatIs.com, a fishbone diagram
… is useful in brainstorming sessions to focus conversation. After the group has brainstormed all the possible causes for a problem, the facilitator helps the group to rate the potential causes according to their level of importance and diagram a hierarchy. The design of the diagram looks much like a skeleton of a fish. Fishbone diagrams are typically worked right to left, with each large "bone" of the fish branching out to include smaller bones containing more detail.[i]
Note the use of the term “brainstorm” in the first two sentences – clearly it’s a large part of creating the diagram. But science is not consensus, and consensus is not science, not even management science. If you are relying on the subjective opinions of the members of your team in order to uncover some hidden truth or insight, you’re doing it wrong. And, as if that wasn’t bad enough, the “facilitator helps the group rate the potential causes according to their level of importance.”[ii] Rate the level of importance? Based on what, exactly? It’s yet another opportunity for subjective inputs to influence the direction of the analysis of the problem under investigation.
Then there’s the whole issue of identifying causality. I’ve been in my share of Six Sigma quality reviews, and never, not even once, heard the facilitator mention the distinction between proximate and material causes. The short answer is that a proximate cause is clear and direct, as in the first domino caused the second one to fall over by being, itself, tipped over. The material cause would be that the second domino fell over because it had been stood up on edge right next to the first domino, thereby qualifying for the “if-not-for” test. This may seem to be mere semantics at first glance, but the distinction in properly identifying remedies to the problems being investigated is huge. For example, one tactic in filling out the fishbone diagram is to ask “Five Whys.” An example I’ve used before involved the sinking of the Titanic. The cause of the Titanic’s sinking, of course, was that it hit an iceberg on the night of 14 April, 1912. One line of the “Five Whys” can go like this:
- Why did the ship hit the iceberg? Because it couldn’t turn away from it in time.
- Why couldn’t it turn away from it in time? Because the lookouts did not give the helmsman sufficient warning.
- Why didn’t the lookouts provide sufficient warning? One reason was that they didn’t have access to the binoculars they would usually use.
- Why didn’t they have access to their binoculars? Because they were locked away in a storage locker, and nobody on-board had the key.
- Why didn’t anybody have the key? Because the person who had the key had been fired prior to the Titanic setting sail, and hadn’t handed them over when he left.
So, based on this “analysis,” some useful strategies in the avoidance of similar maritime disasters would include:
- Don’t fire the person who has the keys to the binocular locker.
- Or, if you do, make sure you get the keys back.
- Alternately, you could ensure that multiple pairs of binoculars are carried on every voyage, and no two of them are kept in the same locker.
- If, however, you find that the only pairs of binoculars are, indeed, in a locked locker, take an axe and destroy the door to the locker.
- If your ocean liner company has a rule against axing open any locker, turn the ship around and go back to port where more pairs of binoculars can be procured (hopefully, quality ones [get it?]).
I could go on (and often do), but you see my point. Without a clearly articulated distinction between proximate and material causality, all the Ishikawa diagram does is help structure a conversation. It doesn’t really help identify the optimal Project Management strategy to either an experienced or looming PM disaster stemming from poor quality.
The other reason I’m opposed to the way Quality Management has been pushed onto the PM universe is due to the notion that those doing the pushing are somehow automatically afforded the intellectual high ground. Touching on the title of this blog, there’s a definite stigma attached to anyone who actually comes out and challenges the notion that Quality Management-types could ever be mistaken in their recommended strategies. But as I’ve been reminding GTIM Nation over the past few months, the old PM saw “Quality, Affordability, Availability: pick any two” is unavoidable. For the Quality guys to automatically assume that their favorite aspect of project delivery is a foregone conclusion strikes me as, well, lacking perspective.
Think about it: you don’t see Affordability or Availability getting their own sections in the PMBOK Guide®, do you?
[i] Retrieved from https://whatis.techtarget.com/definition/fishbone-diagram on May 12, 2019 at 17:14 MDT.