If you are sitting in front of a project right now and you are not entirely sure whether you are solving the right problem, this article is for you. Business analyst problem solving is not about picking the correct framework off a shelf. It is about training yourself to stay oriented towards the actual problem when everyone around you is already committed to a particular solution. That gap between “what we are building” and “what the problem actually is” is where most BA value either gets created or quietly disappears.
Over 25 years of practice across government, utilities, health, and enterprise environments, I have come back to the same three areas repeatedly: problem identification, elicitation, and audience-focused communication. Get these three working together and the rest of the analytical work becomes significantly more straightforward. Miss any one of them and you end up either solving the wrong thing, gathering the wrong information, or communicating the right answer to the wrong people in the wrong way. What follows is how I actually apply each of these areas on a live project.
Start With the Problem, Not the Solution
The single most common failure I see in BA work is starting from a pre-determined solution. A sponsor comes in with a tool they want to buy, a process they want to replicate, or a system they want to replace, and the BA is handed a scope statement that already contains the answer. The problem identification work gets skipped entirely. I was caught in exactly this situation on Project X, a data reporting initiative for a mid-sized public sector organisation. The project was framed from day one as a dashboard implementation. The sponsor had already demoed a commercial BI platform and was ready to sign a contract.
When I started my problem identification work, using a combination of five whys and a fishbone analysis, it became clear within two weeks that the reporting problem was a data quality problem. The dashboards they were trying to build would surface inaccurate data more efficiently. They did not need a BI tool. They needed a data governance process. The sponsor pushed back hard. She had already presented the dashboard solution to her director and did not want to reopen that conversation. I spent the better part of a week preparing a structured problem statement with evidence from the elicitation work I had done, showing that without addressing data quality first, the dashboard would either be delayed or deliver misleading outputs. Eventually she agreed to a two-phase approach: data governance first, reporting layer second. That decision added six weeks to the initial timeline and saved the project from a failed go-live.
This is why problem identification is not a preliminary step you do once and move past. It is ongoing work that needs to remain visible throughout the project. Techniques I use regularly include root cause analysis, mind mapping, five whys, and fishbone analysis. Each one serves a different purpose depending on how well-defined the problem space is at the start.
Choosing the Right Elicitation Approach
Once the problem is defined clearly enough to start gathering requirements, the next question is how to elicit. This sounds like a mechanical decision but it is not. Each project has a different stakeholder landscape, a different level of organisational readiness, and a different risk profile for getting it wrong. I plan elicitation the same way I plan any analytical task: I identify the variables first, then choose the technique.
The main elicitation techniques I draw on, and when I use each one, are as follows:
- Interviews: Best when you need depth from a small number of high-influence stakeholders who are unlikely to speak candidly in a group setting.
- Requirements workshops: Most effective when you need to build shared understanding across multiple stakeholders quickly and surface conflicting views in a managed environment.
- Observation: Invaluable when stakeholders struggle to articulate what they do because the work is deeply habitual and undocumented.
- Document analysis: A strong starting point when existing policy, process documentation, or system specifications are available but have never been fully interrogated.
- Prototyping: Useful when stakeholders cannot visualise what they need from a written description alone and abstract requirements keep producing contradictory feedback.
- Surveys and questionnaires: Appropriate when you need broad coverage across a large, distributed user group and qualitative depth is less critical than scale.
- Brainstorming: Helpful in early-stage problem exploration when you want to generate a wide range of possibilities before filtering down.
- Focus groups: Useful when you want to understand user sentiment and attitudes rather than specific functional requirements.
- Interface analysis: Essential when a new system needs to interact with existing platforms and no one has documented those integration points properly.
On Project X, I used document analysis first to review existing reporting templates, then moved to structured interviews with six operational managers to understand what decisions they were trying to make with the data. The interviews surfaced something no document would have shown: two of the managers were working from completely different definitions of the same performance metric. That finding alone changed the shape of the requirements substantially. You can read more about structuring this kind of elicitation approach in the article on types of elicitation techniques for the business analyst.
Comparing Elicitation Techniques by Use Case
The table below summarises how I select between the most commonly used elicitation methods based on project context. These are generalisations, and in practice I almost always combine two or more techniques rather than relying on one.
| Technique | Best suited to | Key limitation |
|---|---|---|
| Interviews | Deep exploration with senior or specialist stakeholders | Time-intensive; does not surface group dynamics |
| Requirements workshops | Consensus-building across multiple stakeholders | Louder voices can dominate; requires strong facilitation |
| Observation | Undocumented or habitual processes | Observer effect can alter natural behaviour |
| Document analysis | Existing system or policy environments | Documents are often outdated or incomplete |
| Prototyping | Visualising abstract or poorly-defined requirements | Risk of anchoring stakeholders to early designs |
| Surveys | Large distributed user populations | Low response rates; limited depth |
Communicating for the Audience in Front of You
Knowing what the problem is and having solid elicitation data is not enough if you cannot communicate the findings in a way that allows your stakeholders to make decisions. I have seen well-evidenced analyses fail to land because they were pitched at the wrong level of detail for the audience, or structured in a way that buried the key message underneath too much supporting material.
Before I present anything, I ask myself five questions about the people in the room:
- Who are they and what is their role in the decision? Knowing whether someone is a decision-maker, an influencer, or an impacted user changes everything about how I structure a presentation.
- What problem are they trying to solve right now? My analysis needs to connect directly to the thing they are actively worrying about, not the thing I find most analytically interesting.
- What decision do they need to make from this information? If I cannot state the decision clearly, my communication will be vague by default.
- What level of detail serves them? Executives need the headline and the implication. Operational managers need the process impact. Technical teams need the specification.
- What format will they actually engage with? A 40-slide deck sent to someone who reads on their phone at 7am is not communication, it is noise.
On Project X, when I needed to present the data quality finding to the sponsor’s director, I prepared a single-page summary with three columns: the problem, the risk of proceeding without addressing it, and the recommended approach. The director read it in two minutes and approved the revised plan. The 18-page analysis document I had also prepared was never opened. The discipline of knowing your audience is not about dumbing things down. It is about respecting the cognitive load your stakeholders are already carrying and giving them exactly what they need to act.
Communication Habits That Actually Hold Up Under Pressure
Audience focus is a strategic orientation. The daily habits that support it are more granular. These are the ones I have found most durable across different organisations and project types:
- Prepare before every stakeholder interaction: Turning up without a clear agenda or objective wastes their time and signals that you do not value it.
- Respond rather than react to pushback: When a stakeholder challenges your analysis, slow down before responding. Understand whether they are questioning the evidence or the recommendation. They are different problems.
- Listen more than you speak in early engagement: I use the OARS technique in stakeholder conversations: open questions, affirmation, reflective listening, and summary reflections. It creates space for stakeholders to articulate the real problem without me steering them towards the answer I already have in mind.
- Avoid jargon unless you are certain the audience shares it: BA terminology that is second nature to you can create distance with operational stakeholders who do not live in project environments.
- Commit to what you say you will deliver: If a deadline slips, communicate a revised expectation before the original date passes. Silence erodes trust faster than a delayed deliverable does.
- Align explicitly with the stakeholder’s vision: Before presenting a recommendation, confirm that you understand what success looks like from their perspective. This reduces the risk of a technically correct recommendation landing as tone-deaf.
Strong stakeholder engagement is the connective tissue that holds all of this together. I have written more about the practical mechanics of this in the article on stakeholder engagement, which covers relationship-building and influence in more detail.
Problem Solving as a Continuous Orientation
The practical difference between a BA who solves problems and one who delivers outputs is not a matter of technique. It is a matter of where your attention is pointed throughout the project. Techniques are tools. Mindset is the hand that picks them up. What I have described here is not a one-time process you run at the start of a project and then close off. Problem identification needs to stay active as new information emerges. Elicitation needs to flex as the stakeholder landscape shifts. Communication needs to recalibrate every time the audience changes. If you keep these three areas in view simultaneously, you will consistently produce work that moves people towards better decisions rather than work that simply documents what they already thought they knew. That is what business analyst problem solving looks like when it is actually working.
Frequently asked questions
What is a business analyst problem solving framework?
A business analyst problem solving framework is a structured approach to identifying the real problem, gathering the right information through elicitation, and communicating findings in a way that enables stakeholders to make decisions. It is less about following a rigid methodology and more about maintaining a consistent orientation towards the actual problem throughout the project. The three core areas are problem identification, elicitation, and audience-focused communication.
What problem solving techniques do business analysts use?
Business analysts commonly use root cause analysis, five whys, fishbone analysis, and mind mapping to identify and define problems before moving to solution design. These techniques are used to uncover the underlying cause of an issue rather than treating the symptom that is most immediately visible. Choosing the right technique depends on how well-defined the problem is at the start of the engagement.
How does a business analyst identify the root cause of a problem?
Root cause identification typically involves structured techniques such as the five whys, fishbone diagrams, and stakeholder interviews designed to move past surface-level symptoms. The BA asks progressively deeper questions about why the problem exists until a cause is found that, if addressed, would prevent the problem from recurring. This work is most effective when combined with direct observation and document analysis to validate what stakeholders say against what the data shows.
What is the difference between a problem solving focus and an implementation focus in business analysis?
An implementation focus starts from a predetermined solution and works backwards to justify it, whereas a problem solving focus starts from the problem and works forwards to identify the most appropriate response. BAs who default to implementation focus risk delivering solutions that address the wrong issue, which wastes budget and fails to create the intended value. Maintaining a problem solving focus requires actively questioning solution assumptions even when sponsors have already committed to a direction.
How important is stakeholder communication in business analyst problem solving?
Stakeholder communication is central to business analyst problem solving because even a well-evidenced finding will fail to produce change if it is not communicated in a way that enables the right people to act on it. Understanding who needs what information, at what level of detail, and in what format is as important as the analytical work itself. Poor communication of a correct analysis is one of the most common and avoidable causes of project failure.
Try Ash, Your Virtual BA
If this article has prompted you to think more carefully about how you frame problems, structure your elicitation, or communicate with stakeholders, Ash can help you take that thinking further in the context of your actual project. Ash is built specifically for BA practice and can help you sharpen a problem statement, explore elicitation options, and work through stakeholder communication challenges using real BA methodology rather than generic advice. Put the framework in this article to work on your current task right now with Try Ash Virtual BA.
Further reading
- Business Analysis Blog | I’m a Business Analyst at Heart | IIBA
- 6 Skills for Your Everyday Business Analysis Practices | Analyst Catalyst Blog
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.