4 Steps to Efficiently Solve Problems
Problems—we all have to deal with minor or major problems in our personal or professional lives. Having a consistent problem-solving approach can be very helpful, and demonstrating strong problem-solving skills can help you stand out in your career.
In this blog post, I'm going to cover a simple problem-solving framework. Although much of what I discuss can be applied to any type of problem, I'll focus on using the framework from a professional standpoint.
"We cannot solve our problems with the same thinking we used when we created them."
- Albert Einstein
Categories of Problems
Work-related problems can generally be categorized by the area they impact most. That's not to say a problem can't impact multiple areas, but usually there is an area of primary impact. I find it useful to categorize problems into the following three categories:
- People—These problems center around people, their expectations, and their interactions with other people.
- Product—These problems are related to what you produce at work. The "product" can be tangible or intangible. If you're a home builder, your product would be houses. If you're a software developer, the product would be the application you work on. If you're a sales professional, you produce sales. Problems in this category are often related to the "product" not meeting the expectations of the customer or stakeholder.
- Process—These problems are related to the processes you use at work, generally in the context of producing the work product. The problem could be the process isn't producing the desired result, the process isn't being followed, or the process doesn't account for enough scenarios.
Although the framework described in the sections below works with each of these categories, the specific approaches you take might vary. For example, if you're dealing with a process-related problem, a group discussion to analyze the problem likely makes sense. If it's a people problem, group discussions can be counterproductive, particularly in the early stages.
The Steps (and the Pre-Step)
The framework consists of four steps and a very important pre-step. The four steps are as follows:
- Analyze—Understand the root cause.
- Plan—Determine how to resolve the problem.
- Implement—Put the resolution in place.
- Evaluate—Determine if the resolution is producing the desired results.
I'll discuss these steps further below, but first I want to discuss an important precursor—triage. In emergency medical situations, the triage process is used to prioritize patients: do they need immediate attention to survive, or do they have injuries that aren't immediately life threatening? Sometimes, we're faced with more problems than we can immediately solve, so it's helpful to prioritize them. I find the following questions to be useful in this process:
- Is there an immediate action I need to take to reduce the impact of the problem?
- Is there a reasonable degree of likelihood I can solve this problem?
- If I can solve the problem, can I solve it in a timely manner?
- If I can solve the problem, will it make a significant difference?
The answers to these questions can help you prioritize the order in which you should focus on particular problems. If a problem is causing significant and immediate pain, then you need to stabilize the situation first—often by addressing the symptoms.
For example, if a customer is upset, you need to address their immediate pain before attempting to resolve the root problem. Once you've done so, you can move on to prioritization. If a problem is solvable, can be solved quickly, and has a significant impact, you should focus on it first. If you aren't sure the problem can be solved, or solving it won't have a positive impact, then it should be lower on the priority list.
Once this prioritization has been completed, you can analyze the problem.
The goal for analyzing the problem is to understand the root cause(s). (Yes, problems can have more than one root cause.) If you can address the root cause, you can prevent the problem from recurring. It's important during this process to get multiple perspectives on why the problem occurs. If the problem is in the Product or Process categories, I like to use a group of approximately five people to discuss the root causes. If it's a person problem, a group setting might be counterproductive and individual conversations are better. However, for Person problems, it's critical to get multiple perspectives.
There are many techniques for getting to the root cause of problems. One popular and effective approach is the "5 whys." With this approach, you iteratively ask "Why?" about the problem and then each answer until you get to a root cause. For example:
- Why did the upgrade fail? -> The prerequisite updates weren't installed.
- Why weren't the prerequisites installed? -> The person performing the install didn't know there were prerequisites.
- Why didn't the person performing the install know there were prerequisites? -> They didn't read the release notes.
- Why didn't they read the release notes? -> The release notes aren't included or linked to from the installer.
- Why aren't the release notes included or linked to from the installer? -> Because the release notes aren't always required reading for an upgrade.
When using the "5 whys" approach, it's important to look for process failures as the root cause. In many cases, it's easy to get to a why such as "There wasn't enough time" or "We didn't have enough people." If you want to fix the root cause, you need to get to "Why did the process fail to alert us of the problem?"
Once you have one or more root causes, you can start looking at how to resolve them going forward. This is another great time in the process to involve multiple people. Having multiple perspectives can produce innovative approaches to address the root causes. It's also important to remember you might need multiple solutions if you have multiple root causes.
Brainstorming is a good way to generate ideas, but it's helpful to have a method to manage all the ideas that can be produced. Affinity Grouping is an approach that has been around for a long time, and for good reason—it works well. After generating ideas, you group and potentially combine the similar ones. The various ideas in each group can lead to a better, more rounded solution.
An important aspect of the solution(s) you develop is that you can measure the outcomes. I've seen many great ideas that simply didn't result in the desired outcomes for reasons that couldn't be anticipated. If you're able to measure successful outcomes (and unsuccessful outcomes), it helps you adjust more quickly and pivot to different solutions if needed.
Now it's time to put the solution in place. How you do so can vary significantly depending on what the solution is. However, a key consideration should be how the solution will be monitored. This is why it's important to define what success looks like in the planning stage. Those measurements are what you will monitor.
It's important to allow some time before moving to the next step. How much time? It depends—it can be helpful to look at how many times the new solution has been used when determining this. For the example above about release notes, imagine you decided to add an "IMPORTANT" note in a new version of an installer to link people to the release notes. If a week has passed, but only one person has downloaded the new version, then you probably don't have a large enough sample size to evaluate the solution yet. Conversely, if it's only been 24 hours, but 50 people have downloaded the new version, you have a much better sample to work with.
Evaluating the solution requires looking at the outcomes objectively and determining if they match expectations. Often, you will find the solution did improve things, but perhaps not as much as you would have liked. If that's the case, you can refine and iterate on the solution. It might take a few iterations to get the outcomes you would like.
What if the outcomes really don't match expectations? This scenario often indicates the root cause wasn't fully understood, and you might need to jump back to the Analyze step. Revisiting the problem with the additional insight of what did not work can help you uncover other root causes.
The next time you're faced with a problem at work, think TAPIE:
Problem solving is a process—and it's one we need to be able to carry out in a thoughtful and timely manner throughout our careers. Our ability to consistently and efficiently address problems can be what sets us apart.
John Welch is the Chief Technology Officer at SentryOne, where he leads a team in the development of a suite of data and BI products that make monitoring, building, testing, and documenting data solutions faster and more efficient. John has been working with data, business intelligence, and data warehousing technologies since 2001. He was awarded as a Microsoft Most Valued Professional (MVP) 2009 - 2016 due to his commitment to sharing his knowledge with the IT community, and is an SSAS Maestro. John is an experienced speaker, having given presentations at Professional Association for SQL Server (PASS) conferences, the Microsoft Business Intelligence conference, Software Development West (SD West), Software Management Conference (ASM/SM), SQL Bits, and others. He has also contributed to multiple books on SQL Server and business intelligence.