If you have a problem in front of you right now and you are not sure where to start, the problem solving steps I am going to walk you through will give you a usable structure immediately. Not theory. Not a framework to study. A practical sequence you can apply today, whether you are in a discovery workshop, writing up a problem statement, or trying to work out why a proposed solution keeps getting knocked back.
After 25 years working across government, utilities, health, education, and enterprise environments, I can tell you that the analysts who consistently deliver good outcomes are not the ones with the most tools. They are the ones who know how to define a problem properly before reaching for any technique at all. Tools only work when you know what problem they are serving.
Why Tools Are Not Your Starting Point
Early in a BA career, it is easy to feel that confidence comes from knowing more techniques. If I just learn enough methods, the thinking goes, I will be ready for anything. I have felt that pressure myself and I have watched dozens of analysts tie themselves in knots trying to select the right framework before they have even understood the problem in front of them.
The reality is that tools are only as useful as the problem they are matched to. The core skill is understanding the problem first, then choosing the technique that helps you communicate and analyse it. That sequence matters enormously. Get it reversed and you end up doing sophisticated analysis of the wrong thing.
The Four Problem Solving Steps
The business analysis process is, at its heart, a series of problem-solving activities. Those problems might be operational, strategic, technical, or people-related. The same basic structure applies across all of them:
- Define the problem. Identify the true source of the issue, not just the symptoms that are visible on the surface.
- Generate ideas to solve the problem. Use structured creative techniques to surface options, with the right people in the room.
- Evaluate and select alternatives. Assess the options against business objectives, constraints, and stakeholder priorities.
- Implement solutions. Define the pathway forward and support delivery in a way that reflects what the problem actually required.
There are more elaborate methodologies available, including Simplex, Appreciative Inquiry, and Soft Systems Methodology. I have drawn on all of them at different points. But in practice, most of what I do maps back to these four steps, and so will most of what you do.
Step 1: Defining the Problem
Half the battle is identifying the true source of the problem. Treating symptoms without understanding root causes is not only ineffective, it is expensive. The symptoms keep recurring and the organisation keeps paying for interventions that do not fix anything lasting.
Techniques like Five Whys and mind mapping are useful here, both as personal tools for your own thinking and as group facilitation tools in workshops. I use Five Whys conversationally during process mapping sessions because it does not break the flow. Someone raises an issue, I ask why it happens, they answer, I ask why again, and within a few exchanges we are at a cause that was not visible at the start of the conversation.
There are two workshop approaches I use regularly for problem definition. In a business process analysis workshop, I capture the current state step by step and invite stakeholders to raise issues as we go. In a blue skies session, I set aside the current state entirely and use open questioning to surface problems and ideas without the constraint of existing process maps. The blue skies approach works particularly well with senior stakeholders who have no appetite for detailed process scrutiny. Using DOWNTIME from Lean Six Sigma as a questioning backbone gives the session enough structure to be productive without making it feel like a formal audit.
The output of this step should be a clear problem statement that everyone in the room has agreed reflects the real issue, not just the loudest complaint.
A Worked Example: When the Problem Definition Gets Challenged
On Project X, a large public sector body engaged me to support a service delivery improvement initiative. The initial brief described the problem as a technology gap: the existing case management system was outdated and causing delays. The project sponsor wanted a system replacement scoped and costed within the first four weeks.
When I ran the first process mapping workshop with frontline staff, a different picture emerged. Yes, the system was clunky. But the real source of the delays was a breakdown in handoffs between two teams who had different interpretations of a shared policy. Cases were being held at the boundary between the teams because neither team believed the handoff was their responsibility. The system was slow, but it was not causing the backlog. The policy ambiguity was.
The friction came when I raised this with the sponsor. She pushed back hard. The technology replacement was already being positioned internally as the solution, and there was political momentum behind it. Walking that back felt like undermining the project’s rationale. I documented the root cause analysis findings carefully, presented them as evidence rather than opinion, and proposed that the business case include both the process issue and the system issue as separate workstreams with separate cost-benefit cases. That framing allowed the sponsor to retain the technology initiative while acknowledging the process problem as something that needed to be fixed regardless of what happened with the system.
The final outcome was that the policy was clarified and the handoff process was redesigned before the technology procurement began. The procurement subsequently took a different shape because the requirements were now grounded in the real problem. Without that early friction, the project would have spent a significant budget on a system replacement that would not have reduced the backlog.
Step 2: Generating Ideas
Once the problem is properly defined, idea generation becomes much more targeted. Brainstorming works best when participants feel safe to contribute and when the facilitator is asking questions rather than suggesting answers. If the group arrives at a solution themselves, they are far more likely to invest ownership in making it work.
Good facilitation is what separates a productive brainstorming session from a meeting where the loudest person’s idea wins. I always prepare questions in advance, set clear expectations at the start of the session, and push participants past their first and most obvious answers. The interesting ideas rarely come in the first ten minutes.
Stakeholder analysis informs who should be in which session. The people who understand the operational detail are not always the same people who can see the strategic picture, and mixing them without structure creates noise rather than insight.
Step 3: Evaluating and Selecting Alternatives
This is where the BA’s analysis work becomes visible as a deliverable. The evaluation of options maps to two BABOK knowledge areas: Requirements Analysis and Solution Evaluation. The typical outputs at this stage are a business requirements specification and a business case, both of which summarise the options, the analysis behind them, and a recommendation.
The table below shows the most common problem types I encounter and the techniques most relevant to each. This is not a comprehensive list, but it covers the patterns that repeat most often across sectors.
| Problem Type | Common Root Causes | Key Techniques |
|---|---|---|
| Strategic objectives not being met | Poor alignment of initiatives, siloed delivery, weak governance | Strategy analysis, stakeholder analysis, domain modelling, business case |
| Service delivery below target | Manual processes, poor coordination, unclear roles, lack of system support | Process mapping, customer journey mapping, value stream mapping, requirements analysis |
| Operational bottlenecks | Policy changes, duplicated processes, outdated systems, training gaps | Lean Six Sigma (DOWNTIME), process re-engineering, operational performance analysis |
| System functionality not supporting business needs | Poor requirements definition, evolving business context, legacy infrastructure | Interface analysis, functional requirements documentation, prototyping, vendor assessment |
| Poor access to decision-making information | Fragmented data sources, manual reporting, no governance for data quality | Information architecture, data modelling, data governance analysis |
When it comes to the recommendation itself, I always frame options against the business objectives that the project was set up to achieve. A recommendation that is not anchored to the original problem definition will struggle to survive scrutiny from a project board or a finance committee.
Step 4: Implementing Solutions
Implementation depends entirely on what the options analysis concluded. You might be improving a business process, procuring or developing a system, or redesigning an organisational structure. Each pathway has its own set of BA activities, and each brings its own set of problems to solve. In this sense, implementation is not the end of problem solving. It is the beginning of the next round of it.
Project management carries significant responsibility at this stage, and the relationship between the BA and the project manager matters. Understanding where those roles divide and overlap helps both parties work more effectively and avoids gaps in accountability during delivery.
Common Problems Business Analysts Face in This Work
Alongside the problems you are solving for the organisation, you will regularly encounter problems in the work itself. The table below covers the ones I see most frequently and what I do about them.
| Problem | Mitigation |
|---|---|
| Lack of ownership by stakeholders | Involve senior leadership early to communicate purpose and expectations; escalate if engagement does not improve |
| Conflicting views from stakeholders | Give all parties a voice; facilitate collaborative resolution in both group and one-on-one settings |
| Unrealistic timeframes | Document what the BA process requires, share it early, and involve project leaders in agreeing a realistic plan |
| Scope creep | Keep the problem statement visible and use it to assess every new request; involve the project manager in expectation management |
| IT-driven solutions displacing business-led ones | Communicate the risk clearly and escalate; ensure business requirements are documented before technology decisions are made |
| Information siloes across departments | Ensure elicitation activities cover all impacted areas; use domain modelling to make gaps visible |
| Not asking the right questions | Plan questions in advance against expected outcomes; use a business analysis approach document to structure elicitation activities |
Using Your Unconscious Mind as a Problem-Solving Asset
One thing I have come to rely on after years of this work is deliberate incubation. When I am stuck on a problem, I saturate myself in the detail, ask myself the question I need to answer, and then step away. I walk, sleep on it, or do something entirely unrelated. Ideas surface during that break that would never have come from staring at a whiteboard. This is not mysticism. It is how cognition works under cognitive load. The important thing is not to force it. Give the problem space and come back ready to capture what arrives.
Genuine problem-solving ability, built through practice and reflection, is what distinguishes a business analyst who delivers change from one who documents it. The four steps are simple. Applying them under pressure, with resistant stakeholders and shifting constraints, is where the real skill develops, and where the most satisfying outcomes come from.
Frequently asked questions
What are the problem solving steps for business analysts?
The four core problem solving steps are: define the problem, generate ideas to solve it, evaluate and select alternatives, and implement the chosen solution. Each step builds on the last, and skipping the definition step is the most common reason solutions fail to address the real issue. Applying these steps consistently, even informally, significantly improves the quality of outcomes.
How do business analysts define a problem?
Business analysts define problems by looking beyond the symptoms to identify root causes, typically using techniques like Five Whys, mind mapping, or facilitated workshops. The goal is to produce a clear problem statement that stakeholders agree reflects the true issue rather than the most visible complaint. Without this foundation, any solution risks being built on the wrong understanding.
What tools do business analysts use for problem solving?
Common tools include root cause analysis, Five Whys, mind mapping, fishbone diagrams, process mapping, value stream mapping, and brainstorming facilitation. The choice of tool should follow from a clear understanding of the problem, not precede it. Using a technique before the problem is properly defined is one of the most common mistakes early-career BAs make.
How do you handle stakeholders who disagree on the problem definition?
Give every stakeholder the opportunity to express their perspective, then use facilitated group sessions to find common ground rather than letting the loudest voice dominate. Documenting the agreed problem statement and circulating it for sign-off helps prevent the definition from drifting. Where genuine conflict remains, escalate to senior leadership rather than letting it stall progress.
What is the difference between treating symptoms and solving the root cause?
Treating symptoms addresses the visible effect of a problem without changing the underlying condition that causes it, which means the symptoms keep recurring and costs accumulate over time. Root cause analysis works back through the layers of an issue to find the originating factor that, if addressed, would prevent the symptoms from returning. Business analysts are responsible for making that distinction clear to stakeholders and decision-makers.
Try Ash, Your Virtual BA
If you are working through a problem definition right now and need help structuring your thinking, writing a problem statement, or preparing questions for a stakeholder workshop, Ash is built for exactly that. Ash draws on BA methodology to help you move from a messy brief to a clear, defensible problem definition faster than working through it alone. Whether you are preparing for a discovery session or trying to articulate root causes in a way your sponsor will accept, Ash can help you get there. Try Ash Virtual BA.
Further reading
- Journey to Solutions – Leading through Problem-Solving | PMI
- The Sun Never Sets on the Problem-Solving Workshop | Agile Alliance
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.