I was in Texas recently and witnessed a traffic accident. A man was turning into the intersection and ran into a pickup truck hauling a horse trailer. Unfortunately, there was a horse in the trailer at the time, and the carrier was overturned.
An officer arrived at the scene and saw that the horse had broken its leg. Seeing no other alternatives, he pulled out his gun and shot it. We all grew very quiet.
Then, turning his attention to the man in the other vehicle, he asked, “So, are you hurt?”
In the concrete business, we must regularly deal with problems. Usually, we find someone to blame rather than chasing down the most important thing: finding cause.
Through my journey from employee, to consultant, and then to business owner, I learned how the best and worst organizations operate, how they think, and what they believe when it comes to resolving problems. Much of this came to me via live experience and trial and error. In other words, I learned the hard way.
Below are seven common pitfalls to problem solving. How many do you recognize?
1. Not thinking 80/20. The Pareto Principle says that 80% of the outcome often comes from 20% of the causes. Or, 80% of the benefit can be captured with less than 20% of the effort. Which of the contributing factors is causing the most impact? Target those.
2. Solving the wrong problem. Let’s say your customer has asked you to reformulate a mix design to contain more coarse aggregate. But what they really want is a solution to a varied appearance after the concrete is polished. These are different objectives, albeit related. What if the issue was rooted in mixing time or additives? Problem statements should have two key ingredients, if nothing else: an object to improve and the measured performance “deviation.”
3. Overlooking what the problem is not. Being willing and able to eliminate key areas of analysis that do not pertain to the specific problem is key to isolating the root cause. The human mind is second to none in its ability to rationalize, however, and we have a strong urge to make things fit (even when they don’t). One example: one of your mixes fails the seven-day compression test consistently, yet the exact same mix — minus the fly ash — never fails. How many potential causes can we logically eliminate already without knowing anything else?
4. Wasting valuable time with unneeded analysis. Most companies do not have unlimited resources to work on things, so conducting all the analysis you want on a problem is not going to be very practical. Therefore, prioritizing what data you do need is very important to solving the problem in a reasonable amount of time. There’s a well-known phrase called “boiling the ocean” that describes this notion well. As the metaphor goes, there are two ways to get a cup of hot water:
a) Get one cup of water, put it on the stove and boil it.
b) Boil the entire ocean and scoop one cup of the boiling water.
What key information is needed to solve the problem? Be as efficient as possible.
5. Using the wrong mix of quantitative versus qualitative questioning. Quantitative analysis deals with math and understanding numerical relationships. Qualitative analysis explains why the numbers are what they are. You will need a healthy mix of both, probably at a ratio of 70:30. For example, quantitatively we know that selling price erosion is the reason for shrinking revenues on our permeable concrete products. Qualitative analysis tells us it’s because we have a new competitor in the same market whose product boasts a more efficient pour. Too much reliance on either one of the analysis types will always give you an incomplete answer.
6. Deploying the wrong framework. Starting with the wrong approach is akin to building an apartment complex on a house foundation: It won’t fit and eventually, the structure will fall over. Ask yourself: Am I dealing with an actual unknown cause or do I need to just make a decision instead? If it is indeed a problem, is it a profitability issue or a strategic business situation (new market, acquisition, repositioning)? Or maybe the problem is a performance issue with cycle time not running at the same level as before. Apply the right tool and the answer is more forthcoming.
7. Forgetting to “destructively test” the potential root cause. If you have unlimited time and money, ignore this last rule. For the rest of us, this easy trick makes a difference. Before launching an experimental fix — but after you have a favorite root cause theory — mentally test how that root cause specifically accounts for the defect or deviation, how it explains when it occurred when it did, why it occurs where it does and if it explains the patterns that it leaves behind. If it can’t explain all of the known facts of the problem, then either your theory needs revising or the “facts” are not really facts.
It’s not natural to say: “Let’s determine when and where the problem occurred” or “Let’s find out why this happened” or “Let’s not assume someone messed up.” Perhaps we’re unsure how to approach an issue. If we keep in mind that processes exist for solving problems just like processes exist for batching concrete, we can get back to the important things like innovation and customer service.
