Understand the Problem Before You Choose a Solution

If your software team doesn’t address the right problem, they might experience project success but product failure.

Image by gpointstudio on Magnific

Not a Medium member? Read this story here.

Imagine you worked for a year on a project that had executive support and high visibility. In your business analyst (BA) role, you performed the requirements elicitation, analysis, and specification. The development team built what the stakeholders asked for and deployed the product on schedule. But just three months later, the product is considered a failure and decommissioned because it didn’t solve the right problem. Oops.

The Problem Problem

Too often, software teams build and release requirements, features, and even entire products that go unused because those teams didn’t fully comprehend the business situation and the problems they were trying to solve. Understanding the problems or opportunities your solution will address provides confidence that it will indeed achieve the desired outcomes.

When a stakeholder approaches a software team with a need, they might present one or more of these items:

1. A solution they want the team to build, or at least the concept of one
2. Some screens they sketched out that imply the functionality they seek
3. A statement they think describes their problem, but is actually just a symptom of the real problem
4. A description of the real problem they want to solve
5. A statement of their business objectives, the goals they hope a solution will let them achieve

The first three are what you’re most likely to hear. The last two, which are the most important, often go unstated. Then, it’s up to the BA to ask the right questions to ensure that everyone involved understands the real problem and the stakeholders’ associated business objectives.

As an example, I used to work in a software group that supported a large chemical research organization. My manager once asked me, “Got an hour?” A customer had requested that our team port a small PC BASIC program he’d written to our mainframe so others could readily use it.

Yes, I could do that in an hour. But by the time I worked with that user and some other stakeholders to understand what they really wanted to accomplish with this effort, the project expanded considerably. It took 100 hours to fully specify, design, build, verify, and deliver the correct solution (which was, coincidentally, an application called SOLUTION for calculating chemical solution recipes). The app was a grand success, thanks in large part to taking the time to understand the problem and objectives before diving into my source code editor.

The software team’s challenge, then, is to ensure that everyone understands the goals of any initiative and the problem to be addressed early on, rather than committing right away to a solution that could be off the mark or incomplete. Admittedly, it’s more fun to set about building something quickly, but it can be expensive to have to rebuild it repeatedly to try to get it right.

Business Problems

A business problem is any issue that prevents the business from achieving its goals or exploiting an opportunity. It can be a small problem, such as a user complaint that some task takes too long, which can perhaps be solved by streamlining some functionality. Or it can be as large as organization-level business challenges that demand major projects or entirely new products.

Organizations launch initiatives to solve one or more business problems. Each activity gets funded because management expects its value to outweigh its costs. However, rather than presenting a clear problem statement, the executive sponsor or lead customer might simply tell the team what to build. If you don’t understand the problem adequately, or if you begin with a specific solution in mind, there’s a good chance that the team will solve only part of the problem — or perhaps none of it.

When you’re presented with a stated problem, it’s a good idea to perform a root cause analysis until you’re confident that the foundational issue and its contributing factors are well understood. Then you can conceive possible solutions that you know will address those root causes.

If you’re presented with a solution, explore this question: “If <solution> is the answer, what was the question?” In other words, ask “Why do you think that’s the right solution?” You might discover that the underlying issue demands a different approach: possibly simpler, possibly more complex, possibly more specific, possibly more general. You won’t know until you perform the analysis.

Eliciting the Real Problems

A stakeholder might request a solution such as “Combine several systems into one,” with the expectation that such a strategy would address multiple, unspecified objectives. However, system consolidation could be overkill if a simpler answer is appropriate. A root cause analysis could sort all this out.

Root cause analysis involves working backward from a stated problem or a proposed solution to identify the underlying problems and the factors that contribute to them. With the 5 Whys technique, you ask questions like “Why is that a problem?” or “Why are we not already achieving that goal today?” repeatedly until you unveil the compelling concern. The conversation between a business analyst and a key stakeholder might go something like this:

Analyst: “You requested that we combine your four current systems into one. Why do we need to combine them?”

Stakeholder: “Because our customers complain that they must keep signing in between webpage clicks. It’s annoying. This is because they’re accessing different backend systems that all have separate user accounts.”

Analyst: “Why is it an issue if your customers are complaining?”

Stakeholder: “According to our market research, 25 percent of our customers have left us for the competition because of their frustrations with usability on our site.”

Analyst: “If that’s the case, why not just implement single sign-on to improve usability?”

Stakeholder: “That would help, but we’d still have to maintain and support all four systems.”

Analyst: “If we combined them, wouldn’t you still need the same number of support people for the new system?”

Stakeholder: “We don’t believe so. The four current systems use different programming languages. We need at least one engineer fluent in each language to support each system, although there’s not enough work to keep them busy. By combining the systems into one using a single language, we could free up the additional engineers to work on other products.”

Analyst: “Ah, so it looks like you’re trying to solve multiple problems. You want higher customer retention, and you also want to reduce support costs and free up staff by using fewer technologies.”

By asking “why” several times in this conversation, the analyst now understands that the stakeholder expects their proposed solution to address two significant concerns. Perhaps an interim solution using single sign-on could appease the disgruntled customers quickly, while the larger consolidation initiative works on the larger concern of support and maintenance.

A root cause analysis diagram, also called a fishbone or Ishikawa diagram, is a way to show the analysis results. Suppose the BA drills down into the first problem the stakeholder brought up: losing frustrated customers. The BA could apply the 5 Whys technique to determine exactly why the customers are frustrated and then draw a diagram like the one in Figure 1.

Figure 1. A root cause analysis diagram shows the factors that contribute to the stated problem.

The problem goes at the head of the “fish.” Place the highest-level causes in the boxes on diagonal lines coming off the fish’s backbone. Add contributing causes on the short horizontal lines from each diagonal. Continue the exploration until you reach the ultimate, actionable root causes. Then you can devise one or more solutions to address them.

Once you’ve identified the primary and contributing issues, consider all their implications before committing to a solution. The requested or most obvious solution could be the wrong strategy.

Problem First, then Solution

Stakeholders often will propose a specific deliverable as a requirement: “Build me product X or feature Y.” The stakeholder’s solution may indeed be the correct one — but not necessarily. Make sure you understand the real problem so you don’t build a solution that misses the mark and forces the team to build it again.

This article is adapted from *Software Requirements Essentials by Karl Wiegers and Candase Hokanson. Karl is the author of numerous books on software development and other topics, including [Software Requirements](https://www.processimpact.com/pubs.html#SR3E) (with Joy Beatty), Software Development Pearls, and The Thoughtless Design of Everyday Things*.