How to Dissect a Problem to Find Root Cause

I’m going to get personal for a sec. I was talking to my dad the other night. He mentioned that once his car lease was up he wouldn’t lease another car. He would give up driving all together. Through the course of our conversation he said over and over how he wasn’t sure what to do because without a car he’d never be able to run out for a loaf of bread or a gallon of milk. He’d go back and forth between the notion of finding an inexpensive car that he could use to do those kinds of errands and giving up driving completely. This debate was enhanced by an endless loop about bread and milk. Since Dad was on speakerphone, my husband was able to logically interject ideas about taking ride shares (which are in abundance and inexpensive where Dad lives) or tracking how often the spur of the moment milk or bread runs occur and figuring out the relative costs of ride shares versus a monthly car payment plus insurance. These were all very sound ideas, but as any expert problem solver and/or someone with aging parents knows, Dad’s concerns had zero to do with costs or supermarket runs…they had to do with loss of control and autonomy and what that means in the grand scheme of things.

I share this because my account above is a real-life example of how easily root cause can be hidden when you’re trying to solve a problem. What is being presented to us, whether it’s in work or in life, doesn’t always reveal what’s causing the issue in the first place. As a problem solver, I consider myself one-part detective, one-part analyst and one-part confidant. Whether I’m untangling a mess at work or for a friend, I’m taking this triple-pronged approach to finding root cause:

Detective: When presented with a problem to solve, the first step is to hunt for as much information as possible. I’ll do this in a variety of ways like conducting stakeholder interviews, gathering customer feedback, performing process time-studies, pulling reports, doing marketplace assessments. The tactics will all depend on which problem I’m trying to solve. The goal here is to gather data.

Analyst: Once I have the data, it’s time to dig into it to find trends, gaps, etc. to build the facts. I often find that when I’m gathering anecdotal information, it’s often skewed by the people suppling the information. I’ll get into that more deeply when I talk about the third prong. This is why the analysis stage is so essential, to gather hard facts that can support any ultimate solution I may come up with. Plus, it’s hard to refute facts when they are staring you in the face.

Confidant: When I’m working with a team or an individual, I always make a point of listening. And I don’t mean just listening to hear someone out. I mean listening to understand. To really get a sense on where the team is or where an individual is with a particular problem. Are they bringing fear into it? Job insecurity? Anger? There is an emotional component to work that is as real as any you find in a personal situation. Listening with an understanding ear helps me get a better read on root cause and preps me for building solutions that will work within a given environment. It also helps the people with whom I’m working feel more comfortable sharing what’s really troubling them. It’s a win-win for building trust and getting work across the finish line.

What other roles can a problem solver play when looking for root cause? Let’s discuss!