Are we solving the right problem?

[#1]

All of us have probably found ourselves in a meeting where the participants quickly move into solution mode and start assigning tasks ... before they've fully discussed and defined the problem that they intend to solve.

Before discussing solutions, it's best to be sure everyone understands the problem. I was recently in a meeting where a team was discussing solutions to a problem. As I listened to their discussion, it was clear to me that these bright, quick minds were so into solution mode that they didn't realize that they had several different interpretations of the problem. Although they all thought they understood the problem, several different solutions were being laid out because they hadn't clearly defined and aligned on the issue. 

I asked some questions to clarify if I understood the problem: Is it this? Is it that? Is it something else? As I continued to funnel down my questions, others quickly grasped that they needed to clarify the issue first. (I told you they were bright, quick minds.) 

As we continued to discuss, we started to reframe the issues. We'd been discussing symptoms, but what was the real problem that was causing these symptoms? What were the pain points being experienced? Were those symptoms or were they the problem? 

For example, a software user might encounter an error message when using the software. One person might state "The error message isn't clear to the user. We need a better error message." Another person, though, might reframe the issue and ask "Why is the user encountering an error message? Can the workflow or UI design be improved to prevent them from being allowed to make the error?"  Often, error prevention is the better course to follow in a situation like this. 

We're problem solvers and it's our natural inclination to solve things and make things better. Let's be sure, though, that we've defined and agreed on the problem first before rushing to find solutions. 

[Darryl Lee]

Nice article @Rose Eliff !

Agreed with the point that it's always best to be sure everyone understands the problem before the discussion. Efficient and effective!

[Bill Sheboy]

Thanks, @Rose Eliff 

Yes, and...

I often find people currently working in software engineering have no experience with root cause analysis, 5 whys, differential diagnosis, experimentation, and other problem-solving methods.  It is no wonder they sometimes rush to "put out the fire" before understanding the problem/conditions and impact/urgency.  There seem gaps to build such skills when there isn't an active "fire" to help respond better when there is one...leading to uncertainty about when and which methods to use for problem solving.

Sometimes this situation leads to a key gap once solutioning occurs: how would we know this solves the problem we are facing and how would we measure that to recognize when it is solved?

Kind regards,
Bill

[Rose Eliff]

@Bill Sheboy - Love your "and"! I agree that many are not trained in problem-solving techniques. I was thinking of the 5 Whys as I was writing this. Perhaps the root cause of people rushing into problem solving mode is that they are trained to solve, not to identify first? 
Very much appreciate your thoughts on this.  

[Taranjeet Singh]

Great article and great guidance for the teams, @Rose Eliff !

I totally agree that everyone in the team should discuss and understand the problem at hand first so that they are on the same page, before switching to the solution mode.

This topic reminds me of the below famous quote from the great Albert Einstein:

[Rose Eliff]

@Taranjeet Singh - Love that quote! I should've used that for my article. (Copying and saving.) Thanks so much! 

[Christine P. Dela Rosa]

I'm a fan of the formal 5 Whys workshop or even taking a quiet breath to ask this important question before immediately looking at the suggested question to answer for a conversation, a meeting, a large project, etc. 

But I especially liked your note @Rose Eliff on alignment of the problem at hand, because even if one person realizes a root cause for a surface-level issue, lack of alignment across the team isn't going to solve the problem. 

[Rose Eliff]

Thanks so much for your comment and especially for posting the link to the 5 Whys Workshop. I've shared it on our Teams channel. A great way for training us on how to reframe problems using the 5 Whys. Thanks, @Christine P. Dela Rosa

[Karthick S]

Good one @Rose Eliff and sharing how important it is to LISTEN first -> understand -> interpret and then act upon it! 

[Laura Campbell _Seibert Group_]

@Rose Eliff There's a really good book that goes in depth about how to reframe problems: "What's Your Problem: To Solve Your Toughest Problems, Change the Problems You Solve" by Thomas Wedell-Wedellsborg.

In the first few pages it lays out the situation of a slow elevator in a building that people are complaining about. You could look into upgrading the motor, the circuitry that controls how it decides where to go, or (and I'm spoiling here), you could put a mirror up next to each elevator door. People are drawn to looking at themselves and that "problem" of a slow elevator will evaporate because they won't notice the time spent waiting while they are looking at their hair. I love the way the story shows so simply that changing how you frame a problem changes what kind of solution you go looking for (from changing a motor to hanging a mirror).

The book includes a framework and worksheets, and is one of the rare business books that is cleverly witty. 10/10 recommend it. Sounds like you already have a good handle on reframing, but could be a good resource if you need to facilitate reframing with more teams.

[Rose Eliff]

Thanks so much, @Laura Campbell _Seibert Group_ ! I'm familiar with the elevator story (great example of reframing the problem), but I haven't read the book. I'll check it out! Appreciate the reco. I do like witty in a business book. 

[Deepak Rai]

Agreed and good one sharing how important it is to LISTEN first 

[Dan Breyen]

The discussion of treating the cause not the symptom could certainly weighs into this discussion.  Even though it may be cheaper in the short term to treat the symptom, if you keep coming back to treating the symptom, you may want to stop and spend a little more time to see if you can actually find the cause and address it.  

Providing some extra time to evaluate your processes can involve spending some more time in your design/implementation phase so you're not spending even more time in the support/maintenance phase.

Listen to what's needed, reiterate the issue for clarity, and THEN look at implementing a problem. 

Writing some documentation up front to explain how a project is intended to work will save time down the road.