“I JUST GOT THE JANUARY FINANCIAL REPORT AND YOU ARE ALL SPENDING LIKE A BUNCH OF DRUNKEN SAILORS! IF YOU KEEP THIS UP, WE WILL BE OUT OF BUSINESS BY JULY! EVERYONE NEEDS TO IMMEDIATELY CUT BACK SIGNIFICANTLY AND THAT INCLUDES ENGINEERING, SALES, AND ESPECIALLY TRAVEL! THERE WILL BE DIRE CONSEQUENCES FOR ANY VP THAT DOESN’T GET HIS OR HER BUDGET BACK ON TRACK THIS MONTH!”
– Former CEO who probably wants to remain anonymous
Every February, the CEO of a corporation I once knew sent out a similar voicemail message to the whole organization. His point was clear: spend less! Sure, he got those results, but unfortunately, he also created many more unintended consequences. For example, Engineering cut back their development work including validation and pre-launch plant visits, and as a result, products were just not ready for production on time. Fixing those start-up quality issues then required more travel, more testing, and more expediting of parts. All together, these problems (as you’ve probably guessed) killed mid-year budget performance and resulted in another scathing voicemail with even more draconian cuts.
Towards the end of the year, however, departments were actually in danger of underspending their budgets (and thereby losing them the following year), so everyone scrambled to spend as much as they could. But due to the nature of invoicing, many bills arrived and were paid the following January – hence the poor first month performance. Worse yet, customers felt ignored (“How come nobody ever visits us?”) and wondered why a company who promoted their adoption of Lean so much just couldn’t get their act together. The company eventually went bankrupt.
A budgeting process that didn’t align with the realities of the business cycle was just one of their many problems. If you started asking organizational performance “Whys?”, however, you would see that their leaders were actually horrible problem solvers – despite all their training in Lean, Six Sigma, and other techniques. Having spent three decades in formalized problem solving myself, I have come to realize that there is an underlying pattern to successful problem resolution that isn’t as blatantly obvious as it needs to be in many methodologies. That pattern is treating each problem-solving step and its related assumptions as their own hypotheses.
When we use the scientific method to learn about or fix problems, we create and prove a hypothesis or plausible relationship. Ice cream sales and murder rates are correlated, maybe our hypothesis is that sugar highs cause overly aggressive behavior. If we dig a little deeper, though, we find the erroneous “correlation = causality” trap and re-hypothesize that both ice cream sales and homicides increase together in warmer weather. We can prove that relationship with data, and while we cannot control the climate, we may be able to experiment with means of changing the interaction. For more complicated / complex problems, we may need to create and prove several separate but related hypotheses throughout our entire problem solving cycle like this simplified example:
- What problem (or gap) are we solving, or is there even a real problem to begin with? Politicians are great at creating problems that don’t exist but let’s stick with our aforementioned friend, the CEO. He obviously had a fiduciary responsibility to shareholders and a great concern about budget performance, but he didn’t understand that spending in his company shouldn’t be flat (poor assumption), that underspending could actually increase total cost (poor correlation), and that certain investments (like visiting customers) could have positive Net Present Values (poor understanding of value). His first hypothesis of “spending is too high in January and that will just continue throughout the year” was not just wrong, but detrimental to his overall goal of improving total profit. And from what he knew at the time, he couldn’t have been sure he had a real problem to begin with. A “problem statement” is just a hypothesis until it can be scientifically proven.
- What is the root cause or causes of this problem? Everybody likes simple, single root-cause explanations, like “The web server was down because Bob tripped on the power cord and knocked it out.” Unfortunately, life is rarely that simple. For example, it was recently reported that both a technical malfunction and the pilots’ response caused the deadly crash of AirAsia 8501 in 2014. And problems get even trickier when we try to change organizational behavior, or deal with variation problems that can all have multiple, interacting and/or constantly changing factors. While we often strive to simplify problems, we also need to make sure we don’t oversimplify them to our detriment – a common problem I often run into coaching executives. Based on little data and a cursory, biased analysis, the CEO incorrectly hypothesized that the root cause of his problem was that “all of his people were simply irresponsible.” A “root cause” is just a hypothesis until it can be scientifically proven.
- Will our proposed solution(s) improve the problem(s) to an acceptable degree? Complex problems won’t always have 100% effective solutions, but for most problems we should be able to test for efficacy through a well-constructed experiment like a test market, pilot team, or DOE (Design of Experiments). We can also improve our confidence of success if we can turn a problem on or off at will and measure the results – like removing ice cream from bad neighborhoods and observing the outcome. After a repeated year of unchanged spending patterns, the CEO should have realized that his hypothesized solutions (including threats) were not just ineffective, but compounded the problems. “Solutions” are just hypotheses until they can be scientifically proven.
Whether using A3s, the 5 Whys, DMAIC, Value Stream Mapping, or any other problem-solving methodology, many organizations don’t spend the effort necessary to prove all their hypotheses, and either under-solve the real problem or erroneously solve a non-existent issue. Along the way they are too quick to define their problems, rely on too many unsupported assumptions, or they get too impatient and excited while jumping to the solution phase that they skip over the necessary steps in between. The CEO could have easily created a very good-looking and convincing A3 around his budget issue but still never achieved a resolution. Why? Because he never addressed all his underlying hypotheses.
Don’t become an “anonymous former CEO” – use the scientific method to its fullest and prove ALL your critical hypotheses along the way.
