When a project lands on your desk and something is clearly wrong but nobody can quite agree on what, that is exactly the moment business analyst problem solving examples become useful. Not as inspiration, but as a working reference. The techniques exist. The question is which one fits this problem, right now, and how do you apply it without losing the room. I have been in that position more times than I can count, across government departments, utilities, health systems, and enterprise transformation programmes. What follows is what actually works.
The Five Problem Types You Will Encounter Most Often
Most of the problems I have been asked to investigate fall into a small number of categories. Knowing which type you are dealing with early on shapes everything that follows: the stakeholders you engage, the data you seek, and the technique you reach for.
- Process inefficiency. The work is getting done, but too slowly, with too many errors, or at too high a cost. The problem lives in the workflow itself, not in the people running it.
- Declining performance. A metric that matters, sales volume, customer retention, or system uptime, is moving in the wrong direction and the cause is not yet understood.
- Customer or user experience failure. Feedback, complaints, or churn data signals that users are not getting what they need from a product, service, or process.
- Cost pressure. The organisation needs to reduce expenditure without degrading the quality of what it delivers, and someone needs to identify where the cuts can safely be made.
- New capability requirement. A strategic decision to build, buy, or change something has been made, and the work now is to define precisely what the solution must do before anyone starts building it.
Each of these calls for a different starting point. A cost reduction exercise almost always benefits from financial data analysis before any stakeholder workshops. A user experience problem usually needs observation and interview data before you even look at system logs. Getting the type wrong at the start costs you weeks.
A Worked Example: When the Obvious Answer Was Wrong
On a project I worked on for Organisation A, a public sector body running a licensing service, the operational manager had already decided what the problem was before I arrived. Processing times were too long, she told me, because staff were not following the correct workflow. She wanted a training programme and a new checklist. The project sponsor agreed. My job, as far as they were concerned, was to document the improved process and write the training requirements.
I ran a short desktop analysis first, reviewing the case management data from the previous six months. What I found did not support the training hypothesis at all. Processing times were consistent across all staff. There was no cluster of slow performers. But there was a very clear spike every time a case required sign-off from a second team, which sat in a completely different directorate and operated on a different case management system. Cases that stayed within the licensing team were processed in an average of four days. Cases requiring cross-directorate sign-off averaged nineteen days.
When I brought this back to the operational manager, she pushed back hard. She said the second team was outside her remit and that raising it would create political problems with the other directorate head. She wanted to proceed with the training solution. I understood the constraint, but I also knew that spending budget on training would have zero impact on the actual bottleneck. I documented both positions in a structured problem statement, presented the data at the next steering group, and the sponsor made the call to engage the second directorate. It took another three weeks of conversations to agree a shared intake process, but processing times dropped by sixty per cent within two months of implementation. The training programme was quietly shelved.
The point of friction here was real and it mattered: a stakeholder with legitimate authority over the work was directing me toward a solution that the data did not support. The only way through it was a structured, evidence-based problem statement that separated the symptom from the cause. I relied heavily on root cause analysis to make that case, and it held.
If you want a structured approach to framing the problem before you start selecting techniques, the Business Analyst Problem Solving Framework lays that out in detail and is worth reading alongside this article.
Problem Solving Techniques: What Each One Is Actually Good For
The techniques below are not a checklist to work through in sequence. Each one has a specific function. Choosing the wrong tool for the problem type is one of the most common mistakes I see on projects, particularly from analysts who default to the same technique regardless of context.
- Brainstorming. Most useful in the early divergent phase when you genuinely do not know what is causing a problem and you need the team to surface possibilities without filtering them too early.
- Process mapping. The right tool when you suspect the problem lives in the workflow. Mapping the current state visually almost always reveals handover failures, duplication, and unnecessary wait states that nobody has noticed because they are too close to the work.
- Root cause analysis. Use this when the presenting symptom and the actual cause are likely to be different things. It forces you to look at the relationships between contributing factors rather than treating the first plausible explanation as the answer.
- The Five Whys. A fast, lightweight version of root cause analysis that works well in a workshop setting or a one-to-one conversation. Keep asking why until the answer stops being operational and starts being structural. You can read a detailed walkthrough in the “Why” is the How of Getting to the Root Cause of a Problem article.
- Mind mapping. Useful when the problem space is genuinely complex and you need to organise your thinking before you can communicate it to stakeholders. It is a personal thinking tool as much as a workshop tool.
- Fishbone diagram. Also called an Ishikawa diagram, first developed by Dr Kaoru Ishikawa at the University of Tokyo in 1943. It is a structured way to categorise the potential causes of a problem across dimensions like people, process, technology, and environment. The Fishbone Analysis Example article walks through a practical application.
- SWOT analysis. More useful for strategic problems than operational ones. It surfaces the internal and external context around a problem, which matters when you are evaluating whether a proposed solution is viable given the organisation’s current position.
- Pareto analysis. When you have data on multiple contributing factors, a Pareto chart quickly shows you which twenty per cent of causes are driving eighty per cent of the impact. Focus your solution there first.
- Cost-benefit analysis. Once you have identified potential solutions, this is how you evaluate them financially. It is particularly important in organisations where budget authority sits with finance teams who will not approve a recommendation without a clear numbers case.
- Decision matrix. When you have multiple viable options and need a transparent, defensible basis for recommending one over the others, a decision matrix with weighted criteria is far more persuasive than a verbal recommendation alone.
- CATWOE. This technique checks that your problem statement is actually describing a problem and not accidentally describing a solution. It forces you to consider the perspective of customers, actors, the transformation process, the worldview behind the decision, the owner of the system, and the environmental constraints. It is underused and, in my experience, it saves a lot of late-stage rework.
Choosing the Right Technique for the Situation
The table below gives you a quick reference for matching technique to context. It is not exhaustive, but it covers the scenarios you will encounter most regularly.
| Problem Type | Recommended Technique | Why It Fits |
|---|---|---|
| Cause is unknown and stakeholders disagree | Root cause analysis or Five Whys | Separates symptom from cause and creates a shared evidence base |
| Process is slow or error-prone | Process mapping | Makes the current state visible and exposes handover failures |
| Multiple contributing factors suspected | Fishbone diagram | Organises causes by category and prevents premature fixation on one factor |
| Data shows uneven distribution of impact | Pareto analysis | Identifies the highest-leverage causes quickly from existing data |
| Multiple solution options to compare | Decision matrix or cost-benefit analysis | Provides a transparent, auditable basis for the recommendation |
| Problem statement risks being a disguised solution | CATWOE | Tests the problem from multiple stakeholder perspectives before work begins |
| Complex, ambiguous problem space | Mind mapping | Helps organise thinking before communicating to stakeholders |
| Strategic or environmental context needed | SWOT analysis | Surfaces internal and external factors that affect solution viability |
Applying the Approach in Practice
The worked example above followed a sequence that I now apply consistently regardless of the project context. It is not a rigid framework, but it reflects what actually works when you are under time pressure and stakeholder scrutiny.
First, I define the problem precisely before I accept anyone else’s definition of it. That means reviewing whatever data exists and writing a problem statement that describes the observable symptom, the impact, the scope, and what is not yet known. The Problem Solving Steps for Business Analysts article covers this phase in more depth if you are building that capability right now.
Second, I select the technique based on what kind of problem it appears to be, not based on what technique I am most comfortable with. That distinction matters more than it sounds.
Third, I run the analysis, document the findings, and present them back to stakeholders with a clear recommendation. Not a list of options with no guidance. A recommendation, with the supporting evidence. Stakeholders can override it, as the operational manager in Organisation A tried to do, but they need to do so explicitly and on record.
Fourth, I implement and monitor. A solution that is not tracked against the original problem is just activity. The metric that defined the problem, processing time, complaint volume, cost per unit, should be the metric that confirms whether the solution worked.
Where BA Problem Solving Connects to Broader Project Work
Problem solving does not sit in isolation from the rest of the BA role. The moment you move from identifying a problem to recommending a solution, you are already in requirements territory. The problem definition shapes the scope. The chosen solution drives the requirements. Getting the problem wrong at the start means your requirements will be precise answers to the wrong question, and that mistake is expensive to undo late in a project.
This is also where your facilitation skills become critical. Most of the friction in the Organisation A example came from a stakeholder who felt the analysis was encroaching on a sensitive political relationship. Navigating that without losing credibility or derailing the project requires the kind of structured facilitation approach covered in Business Analyst Facilitation Skills: Run Workshops That Work.
The best problem solvers I have worked with over 25 years share one habit: they are deeply sceptical of the first explanation they are given. They treat the presenting problem as a hypothesis to be tested, not a brief to be executed. That scepticism, applied with evidence and structured technique, is what separates analysis from administration.
Frequently asked questions
What are some examples of problems a business analyst solves?
Business analysts typically solve problems like process inefficiency, declining sales or performance metrics, poor customer retention, cost overruns, and the need to define requirements for new systems or capabilities. Each problem type calls for a different analytical technique and a different set of stakeholders. The key is diagnosing the problem type correctly before choosing an approach.
What problem solving techniques do business analysts use?
The most commonly used techniques include root cause analysis, the Five Whys, process mapping, fishbone diagrams, SWOT analysis, Pareto analysis, decision matrices, cost-benefit analysis, and CATWOE. The right choice depends on whether the cause is known, whether multiple factors are involved, and whether you need to compare solution options. Using the wrong technique for the problem type is one of the most common sources of wasted analysis effort.
How does a business analyst approach a problem they have never seen before?
The starting point is always to define the problem precisely before accepting any stakeholder’s framing of it, which often means reviewing existing data and writing a structured problem statement. From there, you select a technique that fits the problem type rather than defaulting to a familiar tool. The goal is to separate the presenting symptom from the underlying cause before any solution work begins.
What is root cause analysis in business analysis?
Root cause analysis is a structured technique for identifying why a problem is occurring rather than just describing what the problem is. It works by tracing relationships between contributing factors, using tools like the Five Whys or fishbone diagrams, until you reach the systemic cause rather than a surface-level symptom. In BA practice it is most valuable when the obvious explanation and the actual cause are likely to be different things.
How do business analysts handle stakeholder pushback during problem solving?
The most effective approach is to separate the evidence from the opinion, which means documenting your analysis in a structured problem statement that shows the data behind your conclusion. When a stakeholder disagrees, you present the evidence clearly, acknowledge their concern, and escalate to the decision-maker if the disagreement cannot be resolved at the working level. The goal is not to win the argument but to ensure that any decision to proceed differently is made explicitly and on record.
Try Ash, Your Virtual BA
If you are working through a real problem right now and need help structuring your analysis, choosing the right technique, or drafting a problem statement that will hold up to stakeholder scrutiny, Ash is built for exactly that. Ash understands BA practice from root cause analysis through to requirements definition, and can help you move from a vague brief to a clear, defensible position faster than working it through alone. Try Ash Virtual BA and put it to work on the problem in front of you.
Further reading
- 9.1 Analytical Thinking and Problem Solving | BABOK® Guide
- Fun and Learning: The Soft Side of Business Analysis | Analyst Catalyst Blog
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.