A Matter of Opinion by Kevin McManus
First published in Industrial Engineer magazine March 2001
In his book "Built to Last", author Jim Collins presents a trait of our Western culture that he calls "the tyranny of the OR." In a simple sense, he is referring to our penchant for polarizing on any issue - avoiding the uncertainty of gray for the seemingly safe absolutes of either black or white. When it comes to problem solving, especially in a team environment, this trait is unfortunately both alive and well.
Problem solving theory teaches us that we should use data to make decisions whenever possible. Time constraints and cost concerns often force us away from fact-based management however, and instead we rely on opinion much more than we should. For engineers who choose (or are assigned) to work with teams as a resource, this tendency towards opinion, and the subsequent polarization around unproven 'facts' that occurs in team meetings, can be particularly troubling. We as much as any profession however perhaps need to move a little more towards the middle.
The use of data in problem solving is further complicated by the myriad of problem solving approaches that exist. You can find improvement processes that have as few as four, or as many as twelve, steps. If you spend too much time trying to sort out the actual distinctions between all of these approaches, you may wind up needing one of the more familiar twelve step processes that actually works. The differences that are promoted exist more to make money than they do to make a given process more effective.
Problem solving efforts essentially involve three list creation and reduction steps. First, we create a list of problems that need to be solved, or in other words, a list of possible projects. After selecting a problem / project from that list, we then create a second list of possible causes for our selected problem. We pick the primary root cause, or causes, of our problem, and then create a list of possible countermeasures, or solutions, that will eliminate our problem forever. We complete the process by selecting the best solution, or solutions from that third list, and then put it in place. Problem solved - right?
Most teams are great at list creation, or at least relatively better at it than they are at the rest of the problem solving process. Think about it - isn't brainstorming one of the more well-known and most frequently practiced of all of the team problem solving skills that you have seen in action? How many times have you seen the walls papered with possible projects, causes, and solutions, only to watch the problem they were intended to address show more resiliency than the tape that holds the flip chart paper to the wall?
Teams are taught to use data whenever possible to help them select possible projects, to determine if they have actually selected the true root cause, and to ensure that the selected solution actually solves the problem. Unfortunately, opinions enter into the team meeting room during each of these three list reduction steps to a greater degree than they should. Once opinions assume control, dominant team members, or the need for a quick solution, can overwhelm the process and discount the problem solving effort faster than a dot-com loses its stock market value.
It would be simple to say that we can correct this problem simply by committing as a team to use data whenever possible to make decisions. It's that "whenever possible" part of the commitment that bothers me however. Isn't that a statement that is largely based on opinion and interpretation? Plus, we know that some of the factors that are most important in assessing the merits of a possible project, cause, or solution can't be measured, even if we had the time or money to do so. What's a team to do? Are we destined to suffer the recurring nightmare of problems that just won't go away? Will we continue to blame this nightmare on the team process instead of recognizing that it is our decision making processes that are really at fault?
The solution lies much more towards the middle of the continuum than it does towards either the data pole or the opinion pole. We can begin simply by looking at the process we use to select options from our project, cause, or solution lists. Do we restrict our efforts to the use of opinion-based tools such as multivoting or the nominal group technique, or do we use decision matrices, countermeasure analysis, and solid project justification techniques to help us include some form of data in making our choices? In other words, are we attempting to reduce the percent of time that we rely on opinion for decision making from 100% towards something that is closer to 50%?
It is not fair, realistic, or practical to make factual decisions 100% of the time. It is not cost, time, or sanity effective to rely solely on opinion either. That is why we process improvers use the term "fact-based" to define our quest - we use facts (data) when possible, but we also recognize that as Dr. Deming said "the most important things are both unknown and unknowable." By making data a key component of our decision making process, we can make much wiser choices and begin to solve those problems that seem to plague us on a repeated basis.
The next time you are in a well-papered meeting room, observe the process that your team is using to pick the "best" options from the lists you have created. To what degree are opinion, and the tyranny of the OR, controlling your team's effectiveness? To what degree are you using some form of fact-based decision making tools to help you identify the best project, cause, or solution? How does your team decide what to do next? By the way, the alternative that Collins proposes to the 'tyranny of the OR' is called the "genius of the AND." He goes on to say that by learning to embrace both extremes along a number of dimensions, we can learn to effectively use data and opinion together. I think we also need to keep in mind what comedian Dennis Miller likes to say - "of course, that's just my opinion - I could be wrong." Keep improving!
Would You Like to Learn More?
Click on one of the following links to learn even more about Great Systems! and the types of systems improvements I can help you make:
“The only thing I know is that I do not know it all.” -- Socrates