A big part of what we do is solving problems, both for clients and to help us operate well in our businesses. In this post, I’ll share some questions that, in my experience, help us understand the real problem we’re looking to solve.
We have more problems to solve than time to solve them. This is true in many industries, including technology. We live in an unpredictable, complex world where technology changes rapidly. We’re vulnerable to ever-evolving security threats and clients need us to create products that are valuable, easy to use, responsive and of high quality. As well as all this, to serve our clients well, we need to prepare for tomorrow, to adapt and solve problems that clients haven’t yet experienced.
When surrounded by so many opportunities to solve problems and help clients, it can be tempting to build solutions without fully understanding the problems we're looking to solve. This results in waste, failure and rework which places more pressure on an already burdened system. It also means we fail to deliver the outcomes needed to solve the problems we set out to solve. Even if we work on improving ways of working and technology so that we produce solutions more efficiently, there’s still a fundamental thing to consider:
“The more efficient you are at doing the wrong thing, the wronger you become. It is much better to do the right thing wronger than the wrong thing righter. If you do the right thing wrong and correct it, you get better.” --Russell L. Ackoff
How long should we spend understanding the problem?
When thinking about how much time to spend on understanding the problem, consider Albert Einstein’s approach:
“If I had an hour to solve a problem. I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” --Albert Einstein
Of course, I’m not saying we must always stick to these numbers, I just wonder if we’re spending too little time understanding the real problem. Do you always feel you understand why the problem needs solving? Do you always feel that all your questions have been answered? Do you always get together with people who have different backgrounds, experience and knowledge so you can hear different perspectives?
Here’s one example, from Russ Ackoff, of why it’s useful to have people of different backgrounds trying to understand a problem:
A manager of a large office building was getting an increasing number of complaints from tenants about the speed of the lift service, particularly in rush hour. Some of the bigger tenants threatened to leave. The manager wrote the following problem statement:
The lifts in the office building
Are running slowly
Which is causing tenants to complain and threaten to leave
The manager brought in highly skilled, well paid, engineers to do a cost-benefit analysis of how to speed up the lift service. The engineers examined the lifts and went away to share notes, do calculations and come up with ideas. After a few weeks the engineers came up with three possibilities:
add more lifts
replace some, or all, of the current lifts with faster versions
add a central computerised control system to optimise routing of the lifts.
None of these options was financially viable. The manager arranged a workshop, with people from all areas of the business, so that they could come up with solutions. For hours they shared ideas, none of which was viable. When the room grew quiet, a psychologist, from the people team, made a suggestion. This suggestion cost a few hundred pounds. It worked.
The psychologist suggested they put mirrors in the lobbies around the lifts. It turned out that the waiting time at the lift wasn’t overly long; people just got bored waiting every day. By providing mirrors, people looked at themselves, or others, while waiting and no longer got bored.
So a better problem statement is:
Tenants
are getting bored waiting for lifts, particularly in rush hour
which is causing them to complain and threaten to leave.
It’s a subtle difference that opens up the scope for solutions. The first problem statement focuses on what wasn’t working as well as it could, the second starts with the people that it affects. Luckily the team stumbled across a good solution. Now imagine if they’d investigated the problem more thoroughly in the beginning. They wouldn’t have had to pay engineers to come in. They wouldn’t have had to wait for weeks for the engineers’ solutions.
How do we know when we understand the problem?
In my experience, asking questions, to a cross functional team, helps us know if we understand the problem. Here are questions that I find it useful to ask.
What questions do you think you need answered so that you fully understand this problem?
This generates a wave of thinking in people who come up with questions they need answered if they’re really to understand the problem. When no more questions are being generated, I ask:
What more questions do you think you need answered so that you fully understand this problem?
It’s incredible how this question stimulates another wave of thinking and more questions are generated. I repeat this question until no one raises any more. This might take a few minutes, or it might take significantly longer if the problem is highly complex or ill-defined. I sometimes ask this question ten times in a row with more questions being generated each time.
It’s then time to go and find out the answers to the questions raised. Once all the answers are found, it's time to get back together and check that the problem is now understood. To do this, I repeat the two questions I asked last time. It may be that there are still more questions to answer. When there are no more questions to answer, everyone is on the way to understanding the problem, but we’re not done yet. There’s another question you can ask to help make sure you all understand the problem.
If you knew, that you have to explain the problem to a key stakeholder, what more would you ask about the problem?
Even more questions might now be generated. When all these questions are answered, there’s just one more to think about:
How do you think we might validate that we’ve understood the problem correctly?
It’s brilliant how people come up with ideas. It might involve talking to clients, customers and users. It might involve pictures or slides. Again, this leads to actions you can take so that you’re more confident you’ve understood the problem. In my experience, the problem statement evolves during this process and can end up looking very different from the original version.
How can we justify spending this long on understanding the problem?
When we’re so busy, it can feel wasteful to spend this much time on all stakeholders understanding the problem. If it becomes apparent that it’s going to take “too long” to answer all questions, then isn’t it good you’re putting the time in. If you’re not confident you understand the problem, then the odds of solving the wrong problem are high.
If you do see the need to put more time into understanding the problem, it often takes courage to start doing things differently. One way that I have found helps get change to happen is experimenting. A possible hypothesis might be:
If we analyse the problem until all stakeholders feel able to explain the problem to others
Then the final problem statement will be significantly different from the original and we’ll solve the right problem.
I wish you well in understanding the problems you're looking to solve.
If you'd like to book a free 30-minute consultation to find out more about how we can help you with improving the flow of work, please contact us using the link below:
Kommentare