Solving problems is great…but, first, you have to determine what the problem really is. This doesn’t necessarily require some brilliant flash of insight — there are simple tools that you can apply to nail down what’s going wrong. You can start, for example, by determining what IS and IS NOT true compared to other problems you face.
I suppose this is too obvious to mention, but: There’s no point in having a solution for a problem unless it’s the solution for the problem you’re facing. Unfortunately, when we see an attractive solution, we often implement it without checking to see if it’s the solution for the problem we actually have. Sometimes, implementing the solution does give us real benefits (that’s why we thought the solution was attractive)…but it still leaves us with the original problem.
Sometimes, we don’t even get those benefits.
The reason we apply solutions that don’t work for the problem is that we often don’t spend enough time on the first step of problem-solving: Getting an accurate description of the problem. I don’t say “a complete description” of the problem because, quite frankly, that’s not achievable. Often looking for a complete description is just a way to defer dealing with the problem.
If you want to solve the problems you actually have you need some critical thinking skills. One output of that critical thinking is an accurate description of the problem. That description is a powerful tool, as programmers know.
One of the most common experiences among programmers is struggling with some bug in a piece of software for hours before calling over a co-worker for help. Then, while describing the problem to that co-worker, the programmer suddenly realizes what the problem is. You’ve probably had similar experiences in your own life: You describe a problem to a friend and, suddenly, the answer is obvious.
It’s not that we get smarter when we talk to other people. It’s just that, often, the first time we accurately describe a problem is when we explain it to someone else. When we’re just talking to ourselves, we tend to shortchange ourselves and work with a simplified (and, usually, inaccurate) description of the problem. Rather than stopping for a moment and saying “What is the problem I’m working on?” we keep hammering away at what out turns out to be symptoms of the real problem…or even on something that has nothing to do with the problem.
When you’re working on a problem, give yourself the same courtesy you give to others: Start with an accurate description of the problem.
The first step in describing the problem is to be precise about what’s actually going on. That isn’t hard to do.
The consulting company Kepnor-Tregoe, whose practice is built around problem-solving, uses an Is/Is Not approach to quickly identify a problem accurately. This process consists of looking at both the places where the problem does occur and where it does not occur; at the times that the problem does occur and when it does not occur; how this problem is like and is not like other problems.
Atlassian, who provide their customers with enterprise applications, used a similar process when one of their cloud applications suddenly failed. Here’s the start of their process (they call the description of the problem the “problem definition”):
After we got the initial report, the first thing we needed to figure out was what was really going on here:
- Who is affected? Is it just a few users, everyone with a ‘q’ in their name, or the entire West coast? Establishing scope is key to problem definition.
- What are they experiencing? What does it look like when they experience the problem? Someone get me a screenshot! Is it every time or just some times?
As you can see, their first step was to get a description of the problem including scope and time: when, where, and to whom the problem happened (and, as a result, who it didn’t happen to).
The wonderful thing about the Is/Is Not approach is that you can test it. If your description of the problem is accurate, for example, you should be able to specify all the places where the problem should occur and all the places where the problem should not occur. You may find that, based on your description, the problem should be occurring somewhere…but it’s not. Now you know your description isn’t complete.
On the other hand, if the problem is occurring in places where, according to your description, it should not be. When that happens, your diagnosis is more complicated. You either:
Quite frankly, it’s hard to say which of those two alternatives is worse: Either way, though, you still don’t know what the problem is and, as a result, any solution you apply is unlikely to fix the problem.
Having an accurate description of the problem is just the first step, of course. The next step is to analyze the problem to find out why it’s occurring and how it’s occurring. Sometimes the problem is occurring because something “special” happened; often the problem turns out to be part of your standard process.
It’s important, therefore, to consider not only the “why” of the problem but the process it’s part of. I was complaining to one of my mentors once about some application that I’d inherited — about how badly constructed it was and all the problems that created for me. He said “You know, the people who built it were probably doing the best they could with the information, skills, and time they had available.” He was, in other words, telling me that the problem was an unavoidable result of the way my company built applications. Sometimes that’s true: The problem is baked into the process.
If you’re familiar with Statistical Quality Assurance then the tools from that field can be helpful. SQA asserts that any problem that re-occurs “frequently enough” isn’t a symptom of something of anything special going wrong — it’s just the way things work. In other words, sometimes the factory produces a functioning product, sometimes the factory produces a collection of parts that looks like a functioning product — it’s just the way the factory works. Only if a problem occurs very infrequently should you assume that something special has gone wrong and needs to be fixed.
When a problem is “part of the system” then you might just have to live with it because, quite frankly, you’re happy with the other outputs of the process (i.e. you like everything else about the factory except for the odd non-working product). In that situation, you should be thinking about “coping strategies” rather than solutions (e.g. set up a generous return policy for defective products).
Alternatively, you may decide to change the process. That’s a brave response…and outside of the scope of this blog post (but is covered in Learning Tree’s Critical Thinking and Creative Problem Solving course). I’ll just wish you the best of luck with that.