The Solution Is Already on the Table Before You Walk In the Room
If you have been working in business analysis for more than a few months, you have almost certainly been handed a brief that reads something like this: “We need a new system to track contractor submissions.” Or: “We need a dashboard so managers can see what is happening.” These are not problems. They are solutions. And strong business analyst problem solving starts by refusing to accept a solution as a substitute for understanding the actual problem underneath it.
The task in front of you right now is probably something like this: you have been assigned to a piece of work, the scope has been loosely described, and stakeholders already have a preferred approach in mind. Your job before you write a single requirement or facilitate a single workshop is to verify whether the stated solution actually addresses the root cause of the problem, or whether it is solving something adjacent, less important, or entirely imaginary. This article will show you exactly how to do that.
Why Teams Jump to Solutions So Fast
It is worth understanding why this happens, not to excuse it, but to know what you are working against. In my experience across government, utilities, and enterprise environments, premature solution framing comes from a few predictable places. A senior stakeholder has already committed publicly to a particular approach. A vendor has been in the building with a product demo. Or the team has simply experienced a symptom so many times that the solution feels obvious.
None of this makes the proposed solution wrong. Sometimes it is exactly right. But arriving at the right answer by accident is not good enough when you are responsible for documenting requirements that a development team will build against. You need to be able to demonstrate that the solution is connected to a real, verified problem.
The risk of skipping this step is serious. Teams spend months building something technically correct that solves the wrong thing. The real job of a business analyst is not to document what stakeholders ask for. It is to understand what they actually need.
A Concrete Example: Where the Data Conflict Was the Real Problem
On a government infrastructure project (Organisation A), I was brought in to help specify a new reporting system. The brief was clear: build a dashboard so asset managers could monitor building condition data in one place. Stakeholders were aligned, the project manager had timelines ready, and the procurement team was already talking to vendors.
Before I started writing requirements, I asked a simple question: what decisions are currently being made badly because you cannot see this data? The room went quiet for a moment, and then the asset manager said something I was not expecting. “Actually, the data is there. The problem is that different teams pull different versions of it and they never match.”
That was the real problem. It was not a lack of visibility. It was data conflict caused by multiple disconnected export processes feeding separate local databases. The analysis document I was reviewing at the time described exactly this pattern: several scheduled mainframe export jobs producing independent flat files, each feeding a separate Access database, with no single authoritative source. When two teams ran reports on the same day from different databases, they got different numbers. The proposed dashboard would have made that conflict visible in high resolution, but it would not have resolved it.
The project sponsor pushed back when I raised this. Her view was that the dashboard had already been scoped and any re-scoping would delay delivery by at least a quarter. I held my position because the alternative was building something that would undermine trust in the data the moment two managers compared their screens in a meeting. We agreed to a two-stage approach: first, establish a single consolidated data repository as the authoritative source, then build the reporting layer on top of it. The delay was six weeks, not a quarter. And the solution actually worked.
This is what real problem solving in business analysis looks like. It involves friction. It requires you to ask uncomfortable questions at the moment when everyone else wants to move forward.
How to Verify You Are Solving the Right Problem
There is a structured approach I use at the start of every engagement to get underneath the stated solution and confirm what the actual problem is. It does not take long, but it has to happen before requirements work begins.
Step 1: Write a Problem Statement That Has Nothing to Do With Technology
Ask yourself: if there were no systems, no software, and no dashboards in the world, what would still be going wrong? Write the answer in one or two sentences. If your problem statement contains words like “system,” “platform,” “tool,” or “dashboard,” you have written a solution statement, not a problem statement. Keep rewriting until it describes a gap between what is happening and what should be happening, in purely business terms.
Step 2: Ask Who Is Affected and How They Are Affected Right Now
A real problem leaves a trail. Someone is doing extra work. Decisions are being delayed. Data is being re-entered. Errors are going undetected. If you cannot find evidence that the problem is causing pain right now, you need to investigate whether it is actually the priority it has been positioned as.
Step 3: Apply Five Whys to the Stated Problem
Take whatever problem has been handed to you and ask “why” five times. Each answer becomes the input to the next question. This technique almost always reveals that the stated problem is a symptom of something deeper. The Five Whys approach is one of the most reliable tools I use for this, and it takes less than twenty minutes when done with the right people in the room.
Step 4: Check Whether the Proposed Solution Would Actually Eliminate the Root Cause
Once you have a root cause, test the proposed solution against it directly. Ask: if we built this solution, would the root cause no longer exist? If the answer is “no” or “probably not,” the solution needs to change, or at minimum needs to be accompanied by other changes that address what is actually causing the problem.
Questions That Surface the Real Problem
These are the questions I ask in early stakeholder conversations. Each one is designed to pull the conversation away from the solution and back towards the actual need:
- What is happening right now that should not be happening? This focuses attention on observable, current pain rather than hypothetical future states.
- What is not happening that should be? This surfaces gaps that may not be causing visible failures yet but are quietly creating risk.
- How do you know this is a problem? This asks for evidence and separates genuine pain from assumption or preference.
- Who is most affected, and what does that look like on a Tuesday morning? Grounding the problem in a day-to-day scenario reveals whether the problem is real and frequent or rare and overstated.
- If we did nothing, what would happen in six months? This tests urgency and helps prioritise whether this problem needs solving before other competing issues.
- Has anyone tried to fix this before? Previous failed attempts often contain the real diagnosis, buried in why they did not work.
Comparing Problem-First and Solution-First Approaches
The difference between these two starting points compounds quickly once a project is underway. Here is how they tend to play out:
| Approach | Starting Point | Requirements Quality | Risk at Delivery |
|---|---|---|---|
| Solution-first | Stakeholder proposes a tool or system | Requirements describe the solution, not the need | High: solution may not address root cause |
| Problem-first | Root cause is confirmed before scoping begins | Requirements trace directly to business outcomes | Low: solution is validated against the actual problem |
| Hybrid (most common) | Solution proposed, problem explored before requirements | Mixed: some requirements grounded in need, some in preference | Medium: depends on how thoroughly the problem was explored |
What to Do When You Find the Solution Does Not Match the Problem
This is the hard part. Telling a project sponsor that the scoped solution will not solve the problem is genuinely uncomfortable, especially when contracts have been signed, timelines have been agreed, and the team is ready to start. But it is the work. And there is a way to do it that does not require you to blow up the project.
Frame your finding as a risk, not a judgment. Something like: “Based on what I have learned in the last two weeks, there is a risk that the proposed solution addresses the symptoms but not the root cause. I would like to spend one session with you walking through what I have found and testing a few options.” This opens a conversation rather than closing one.
Document your finding in writing, even briefly. A short findings document that captures the stated problem, the root cause as you understand it, and the gap between the proposed solution and that root cause gives stakeholders something concrete to respond to. It also protects you if the decision is made to proceed with the original solution despite your analysis.
Sometimes the decision will go against your recommendation. That happens. Your job is to make sure the decision is informed, not to win the argument. Put your analysis on record and make sure the risk is documented in a place the project governance process will pick up.
Building This Into Your Standard Practice
The most effective way to ensure you are solving the right problem is to build problem verification into the front end of every engagement, not as a special investigation, but as a normal part of how you start work.
In practice, this means including a problem statement review in your kick-off activities, running at least one session specifically focused on root cause before requirements workshops begin, and establishing a clear link between the problem statement and the solution scope in whatever document you use to frame the project. If you are working from a business case, check whether the problem has been articulated clearly there. If it has not, that gap is worth raising before analysis begins.
The habit of asking “what problem are we actually solving?” sounds simple. In practice, it is one of the most professionally valuable things you can consistently do, because so few people on a project team are positioned to ask it, and even fewer have the analytical tools to pursue the answer rigorously. That is what makes it a distinctly BA contribution, and it is what separates genuine problem solving from requirement transcription.
Frequently asked questions
How does a business analyst identify the real problem vs the stated problem?
A business analyst identifies the real problem by asking structured questions that separate symptoms from root causes, using techniques like Five Whys and stakeholder interviews focused on current-state pain rather than desired solutions. The stated problem is often a solution dressed up as a need. Comparing what is happening now with what should be happening in business terms, without reference to any technology, usually reveals the gap.
What is business analyst problem solving?
Business analyst problem solving is the practice of identifying, defining, and validating the root cause of a business problem before any solution is designed or built. It involves structured questioning, root cause analysis, and evidence gathering to confirm that the proposed scope will actually address the underlying need. It is distinct from requirements elicitation, which comes later once the problem is understood.
What do you do when stakeholders already have a solution in mind?
When stakeholders arrive with a preferred solution, the most effective approach is to acknowledge the proposal and then ask permission to test it against the problem it is meant to solve. Frame this as a risk validation exercise rather than a challenge to their judgment. If the solution does not address the root cause, document the gap in writing and present it as a risk for the project sponsor to consider.
What questions should a business analyst ask to define the problem?
The most useful questions focus on what is currently going wrong, who is affected and how, what evidence exists that the problem is real, and what would happen if nothing changed. Asking whether the organisation has tried to address the problem before and why previous attempts failed often reveals the real root cause faster than any other line of questioning.
How do you write a problem statement as a business analyst?
A good problem statement describes the gap between the current state and the desired state in purely business terms, with no reference to technology or solutions. It should identify who is affected, what the observable impact is, and ideally include some evidence of frequency or severity. If your problem statement contains words like system, tool, or platform, rewrite it until those words are gone.
Try Ash, Your Virtual BA
If you are working through a problem right now and not yet sure whether the proposed solution actually fits, Ash can help you think it through. Ash is trained in business analysis methodology and can guide you through root cause questioning, help you draft a clear problem statement, and pressure-test a scope against the underlying business need before requirements work begins. It is exactly the kind of structured thinking this article describes, available whenever you need it. Try Ash Virtual BA.
Further reading
- Business Analysis Blog | How to Start Your Career as a Business Analyst | IIBA
- 6 Skills for Your Everyday Business Analysis Practices | Analyst Catalyst Blog
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.