Making Assumptions

Case History of Five Reasons Why We Fail to Solve Problems and What We Can Do About It! — Making Assumptions

Part 1 of a 5-Part Series

Solving problems successfully and consistently requires discipline and practice.  It is a constant challenge with a number of obstacles that can regularly interfere with the desired outcomes.  In over three decades of problem solving, I’ve seen many obstacles to success, and I’ll examine the five most common in this series of blog posts.  We fail to solve problems because we:

1. Make assumptions
2. Over-rely on experience
3. Rely on “experts”
4. Come to the problem with preconceived ideas
5. Depend too much on memories

In this blog I will tackle “making assumptions” and will go into more detail on the other four reasons in future blogs.

Making Assumptions is Certain Death to Solving a Problem

The definition of assumption is to accept something as true or certain without proof.   We make assumptions daily, often without realizing it, but in the context of problem solving, it can be deadly, prompting you to:

• Conclude you have a problem where none exists
• Lead you to identify the wrong problem
• Accept at face value things you shouldn’t
• Identify the wrong root cause
• Use the wrong countermeasure (solutions)

An Example of Working on a Problem That Isn’t a Problem

I once worked at an Air Force Base as a consultant Lean Master Black Belt, training future black belts.  One team was composed of eight Non-Commissioned Officers (NCOs) who were working on a project to reduce training hours from the existing yearly total of 40 hours to a future state of 24 hours.  The team allocated 40 hours to work on the project, eight hours a day for five days.  Representatives of the squadron that actually conducted training couldn’t attend the meetings until the fourth day.  When they finally arrived, it was discovered that actual training time was already reduced to 24 hours and the project, along with the prior three days’ work, was wasted.

When I learned of this I suggested the First Sargent meet with the Air Base Wing Commander and report what happened.  The project was put on hold for the remainder of the fourth day and on the fifth day the team met and were instructed to proceed with the project.  Their instructions were to try and recreate the root cause and countermeasures that led to the current state of 24 hours.  The Commander wanted them to learn the steps to problem solving and all the steps in the continuous improvement process.

The team gave an “out-briefing” (presentation) to the Commander on the fifth day.    While he congratulated them on their work, it was clear from his body language and demeanor when he left the meeting that he wasn’t pleased.

What had happened to lead to all of this?  I met with the Commander, and after further discussions, I learned he took at face value another officer’s recommendation to work the “problem” of reducing the hours.  I asked him what sort of proof the officer gave him to demonstrate that a problem existed.  The Commander replied, “None, I assumed the officer knew what he was talking about.”

I respectfully asked the Commander what he would do in the future when confronted with similar situations.  He responded, “Next time they better have the evidence, with the correct numbers, to back up what they are saying!”  He was visibly upset.  He accepted the blame for the NCO’s wasted time and was furious with the officer who brought the problem to him.  The Commander said he should have asked to see the data.  He just made too many assumptions.

Lessons Learned

1. Make sure you’re working a real problem. Back up assumptions with reliable, verifiable facts.
2. Don’t assume someone else’s assumptions and accept things at face value. Ask “how do you know?” and “can you show me data?”  This is the beginning of real problem solving.
3. The eight NCOs were left guessing what root causes had originally been identified to solve the so-called “problem.” There hadn’t been a paper trail or anyone to tell them how the training squadron had reduced the hours.  Those folks had transferred to other bases prior to the project.
4. The Commander was the highest-ranking officer on the base and the NCOs didn’t want to embarrass him, which it ultimately did in the long run. Also the NCOs were intimidated by the Commander’s rank.  It also created ill feelings about participating in future continuous improvement events.
5. By identifying the wrong root cause, the team came up with the wrong countermeasures. Make sure you have the correct problem and investigate enough to find the real root cause and put in a countermeasure to address it.

My next blog will be:  Over-relying on Experience