Here Are Seven Common Things You Should NOT Do When Problem Solving.
By Ryan Brown
I was in Texas recently and served as a witness to a traffic accident on one of the busy highway frontage roads. 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. Traffic was building up quickly on both sides.
An officer arrived at the scene and quickly surmised that the horse had broken its leg. Seeing no other alternatives, the officer 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 aggregates business, we all have to deal with problems on a fairly regular basis. In most instances, the default position for tackling problems is to find blame. I know how cynical this must come off, but it’s our nature. What is the first thing you ask when you find crayon on your walls at home? How about when a customer didn’t receive a load?
There is tenacious pursuit of blame: “You can’t rely on those drivers; they live in their own worlds;” “Those salesman – they promise the world without thinking practically;” and “We need to find the dispatcher who no doubt routed the wrong truck.”
Just the accusation itself provides such gratification. And it solves the problem … or does it? In the workplace, we are wired to 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 in the real world that I found most valuable not to do. How many of these do you recognize?
1. Not thinking 80/20. The Pareto Principle basically says that 80 percent of the outcome often comes from 20 percent of the causes. Put another way, 80 percent of the benefit can be captured with less than 20 percent 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 change a product grind to contain higher levels of 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). Example: one of your operations is having a throughput issue with a new crusher. Yet upon further review, the throughput rate was great until three Wednesdays ago. How many favorite potential causes can we logically eliminate already without knowing anything else?
4. Wasting valuable time with unneeded analysis. Most companies (outside of Google or Apple) do not have unlimited resources to work on things, so conducting all the analysis you want on a problem is not going to be a very practical endeavor. Therefore, prioritizing what data you do need is very important to solving the problem in a reasonable amount of time. There’s a very 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 vs. 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 profitability on our crushed gravel products. Qualitative analysis tells us it’s because we have a new competitor in the same market who has figured out a way to offer faster delivery. Too much reliance on either one of the analysis types always gives 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 just won’t fit and somewhere down the line the structure will fall over. Questions to ask yourself are: 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, etc.)? Or maybe the problem is a performance issue with downtime running at a different level as before. Apply the right tool and the answer is a lot more forthcoming.
7. Forgetting to “destructively test” the potential root cause. Going back to the resource limits addressed in #4, if you have unlimited time and money, ignore this last rule. For the rest of us, this easy trick will make a difference. Prior to launching into 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. This exercise is called destructive testing and is a big time saver when faced with many “pet theories.”
We process countless problems every day at work. However, 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 unintentionally short circuit the process because we are just unsure of how to approach an issue. If we keep in mind that processes exist for solving problems just like processes exist for mining and processing aggregates, we can get back to the important things like innovation and customer service.
Just don’t put the cart before the horse.
Ryan Brown is the founding consultant at Next Level Essentials LLC, a profit-improvement practice that seeks to help building products operations minimize landed costs, maximize margins and streamline the problem solving process. E-mail Ryan at [email protected] or visit www.nextlevelessentials.net.