If you are sitting with a requirements workshop coming up, a scope that keeps shifting, or a project sponsor who cannot articulate what they actually need, you are dealing with the most persistent business analyst challenges in the profession. These are not edge cases. Research collected as far back as 2005 and confirmed repeatedly since then shows that the same three or four problems account for the majority of BA-related project failures. Knowing what they are and how to respond is a practical survival skill, not a theoretical exercise.
I have worked across government, utilities, health, education, and enterprise environments over 25 years. The names of the organisations change. The problems do not. What follows is grounded in published survey evidence, practitioner insight from the BA community, and my own direct experience of what happens when these challenges are left unmanaged.
What the Evidence Actually Says About BA Challenges
A 2005 survey by Business Improvement Architects, carried out with business analysts attending Project World/Business Analyst World in Toronto, identified ten challenges. The top two were “Lack of Clarity in the Scope of the Business Functions” and “Business Requirements Not Well-Defined.” Nearly two decades later, those same two issues still top every informal poll and post-mortems I have seen. That is not a coincidence. It reflects a structural problem in how organisations commission and run analysis work.
The survey is worth reading because it goes beyond naming the problems. It provides discussion on how to deal with the top four challenges, and the practical advice holds up well. The broader BA practitioner community, including writers at Business Analyst’s Times, has consistently reinforced the finding that requirements elicitation is the primary fault line. The argument is straightforward: if the BA cannot make the most of business users’ time and knowledge during elicitation, everything downstream suffers. Poor inputs produce poor outputs, regardless of how well the rest of the project is managed.
A third perspective worth noting comes from Bridging The Gap, which has examined challenges not just for individual BAs but for BA managers. The argument there is that BA managers carry significant responsibility for the quality of analysis across a team, and yet they rarely receive credit for what they contribute to the profession. Managing BA capability, coaching analysts through difficult stakeholder situations, and setting standards for documentation are invisible forms of labour that shape project outcomes at a level above the individual analyst.
The Core Business Analyst Challenges in Practice
Rather than treating these as separate problems, I find it more useful to think of them as a chain. Unclear scope produces vague requirements. Vague requirements produce stakeholder conflict. Stakeholder conflict produces rework. Rework produces deadline pressure. And deadline pressure produces the kind of rushed analysis that stores up problems for later. Breaking the chain early is always the better investment.
Unclear Scope
Scope ambiguity is the challenge that causes the most downstream damage, and it is also the one most likely to be treated as someone else’s problem. Project managers want to move to planning. Sponsors want to talk about outcomes. Developers want to start building. Nobody wants to spend time at the front end establishing exactly what is and is not included in the analysis effort. Scope creep and governance is a real and persistent issue, and the best time to address it is before the first workshop, not after the third delivery milestone has slipped.
In my experience, the most effective tool here is a written scope statement reviewed by the project sponsor in a dedicated session before any elicitation starts. It does not need to be long. It needs to be specific enough that someone can read it and tell you with confidence whether a given topic is in or out.
Requirements That Are Not Well-Defined
Poorly defined requirements are almost always a symptom of rushed or shallow elicitation rather than a failure of documentation. The document is where the gap becomes visible, but the root cause is earlier in the process. Stakeholders describe what they experience, not what they need. BAs who accept that description at face value end up writing requirements that reflect current-state pain rather than future-state intent.
The practical response is a structured questioning approach. Requirements elicitation questions that probe the why behind every what are the single most valuable habit a BA can develop. “What does the system need to do?” is a much weaker question than “What decision are you trying to make with this information, and what stops you making it now?”
Stakeholder Engagement and Availability
Getting the right people in the room at the right time is harder than it sounds. Subject matter experts are busy. Senior stakeholders delegate to people who do not have the authority to confirm decisions. Business users attend workshops but defer to a manager who never attends. These are practical problems with practical solutions, but they require the BA to invest in stakeholder mapping before the engagement begins rather than discovering the gaps during it.
Managing Conflicting Stakeholder Expectations
Even when stakeholders are present and engaged, they frequently want different things. Finance wants a solution that reduces cost. Operations wants a solution that reduces workload. Compliance wants a solution that reduces risk. None of those objectives is wrong, but they will produce conflicting requirements unless the BA actively surfaces and manages the tension. Stakeholder engagement at this level is not just facilitation. It is political navigation.
Comparing the Challenge Areas
| Challenge Area | Where It First Appears | Primary Impact | Typical Response That Fails |
|---|---|---|---|
| Unclear project scope | Project initiation | Scope creep, rework, missed delivery | Assuming scope will clarify as work progresses |
| Vague business requirements | Requirements elicitation | Incorrect solution design, failed UAT | Accepting stakeholder descriptions without probing |
| Stakeholder availability | Planning and scheduling | Delayed decisions, incomplete information | Waiting until the workshop to identify the right people |
| Conflicting stakeholder expectations | Elicitation and sign-off | Disputed requirements, stalled approvals | Documenting all views without facilitating resolution |
| BA manager support and standards | Team and programme level | Inconsistent quality across deliverables | Treating BA management as purely administrative |
A Worked Example: When Scope and Stakeholders Collide
On a finance transformation programme I worked on for Organisation A, the project brief described the scope as “end-to-end accounts payable process improvement.” That sounds clear. It was not. Within two weeks of starting elicitation, I had three different interpretations from three different stakeholders. The CFO understood it to mean process redesign only, with no system changes. The IT lead assumed a full system replacement was in scope. The accounts payable team lead thought we were looking at a narrow fix to the invoice matching workflow.
None of them were being awkward. Each had received a different briefing during the project approval stage. When I brought the three interpretations together in a single document and sent it to the project sponsor for clarification, the response I got was not resolution. It was pushback. The sponsor felt that surfacing this disagreement publicly made the project look badly managed, and asked me to “work it out quietly” with the individual stakeholders rather than escalate.
That is a recognisable dynamic. The instinct to manage difficult information privately is common in organisations where project failure carries political cost. I held my ground, explained that undocumented scope decisions would create much larger problems at delivery, and asked for a formal scope workshop with all three stakeholders in the same room. The sponsor agreed reluctantly. The workshop took half a day and produced a written, signed scope statement that excluded system replacement and defined the process improvement boundaries specifically. That document was referenced four times in subsequent weeks when individual stakeholders attempted to reintroduce items that had been explicitly excluded.
The friction was uncomfortable. The outcome was a project that delivered within its original boundary. Without that conversation, I am confident at least two of those three interpretations would have ended up in the requirements documentation, producing a solution that satisfied none of the stakeholders fully and exhausted the budget trying to satisfy all of them.
What BA Managers Carry That Individual Analysts Often Miss
It is worth spending a moment on the BA manager dimension, because it is often invisible to analysts who are heads-down on their own projects. The challenges faced by BA managers are real and distinct from those faced by practising analysts. A BA manager is simultaneously responsible for the quality of analysis across a portfolio, the professional development of individual analysts, the standards that govern how requirements are documented, and the political relationships that determine whether the BA function gets consulted at the right point or brought in too late to add value.
When a BA manager sets clear documentation standards, coaches an analyst through a difficult stakeholder situation, or fights for BA involvement at the initiation stage of a project, none of that work appears in a requirements document. It shapes the quality of every requirements document the team produces. If you are early in your career and you have a BA manager who does those things, that is worth recognising. If you are a BA manager reading this, the challenges you navigate on behalf of your team are a meaningful contribution to the profession, even when they go unacknowledged.
Practical Responses Worth Prioritising
- Write a scope statement before the first workshop. Even a one-page document that lists what is in and what is out gives you something concrete to test stakeholder interpretations against.
- Ask the why behind every what. “What do you need?” is a starting point. “Why do you need it, and what happens if you do not get it?” is where the real requirement lives.
- Map your stakeholders before you engage them. Knowing who has authority to confirm decisions, who influences those people, and who is likely to object late in the process shapes your entire engagement plan.
- Surface conflicts in writing, not just conversation. A verbal agreement that two stakeholders want the same thing is fragile. A written requirement signed by both is much harder to unpick later.
- Treat BA manager challenges as part of the landscape. If you are an analyst, understand that your manager is navigating constraints that directly affect your working conditions. If you are a manager, invest in the coaching conversations that do not show up in a project plan.
- Build your elicitation approach around the constraint. If time with subject matter experts is limited, structured elicitation techniques that extract maximum insight per session are worth the preparation investment. Elicitation techniques vary significantly in how much they demand of participants, and choosing the right one for the context matters.
The business analyst challenges that appeared at the top of a survey in 2005 are still the challenges that derail projects today, not because the profession has failed to learn from them, but because they are embedded in the way organisations commission and govern change work. Scope ambiguity, vague requirements, and conflicting stakeholder expectations are not problems you eliminate once and move on from. They are features of every new project that require active management from the moment the brief arrives. The BAs who handle them well are not the ones with the most frameworks. They are the ones who address the discomfort early, document agreements in writing, and hold the line when the pressure to move fast pushes against the need to get it right.
Frequently asked questions
What are the most common business analyst challenges?
The most consistently reported challenges are unclear project scope, poorly defined business requirements, and managing conflicting stakeholder expectations. These three issues are closely linked: scope ambiguity leads directly to vague requirements, which in turn produces stakeholder disputes during review and sign-off. Addressing scope clarity before elicitation begins reduces the severity of all three.
How do business analysts deal with unclear scope?
The most reliable approach is to produce a written scope statement before the first elicitation session and have it reviewed and signed off by the project sponsor. This document does not need to be long, but it must be specific enough to determine whether any given topic is in or out. Revisiting it when new items are proposed is the foundation of effective scope governance.
Why is requirements elicitation such a difficult part of the BA role?
Requirements elicitation is difficult because stakeholders typically describe what they experience rather than what they actually need, and because the people with the most knowledge are often the least available. Effective elicitation requires structured questioning that probes the reasoning behind every stated requirement, not just the surface-level description. It also requires the BA to secure genuine time from the right people before the engagement begins.
What challenges do business analyst managers face that individual BAs do not?
BA managers carry responsibility for analysis quality across an entire team or portfolio, not just their own projects. They must set and enforce documentation standards, coach analysts through stakeholder difficulties, and advocate for BA involvement at the right point in project initiation. Much of this work is invisible in project reporting, but it directly determines the consistency and quality of what the team delivers.
How can a business analyst manage conflicting stakeholder expectations?
The most effective approach is to surface conflicting expectations explicitly and early, rather than attempting to satisfy all positions simultaneously through vague requirements. Bringing stakeholders together in a structured session where trade-offs are discussed and documented produces more durable outcomes than managing each stakeholder separately. Written, agreed requirements that reflect a genuine resolution are far harder to dispute later than verbal commitments.
Try Ash, Your Virtual BA
If the challenges in this article feel familiar, particularly the pressure to clarify scope fast, run better elicitation sessions, and document requirements that stakeholders will actually sign off on, Ash is built for exactly that work. Ash guides you through structured BA processes, helps you ask the right questions at the right stage, and supports you in producing clear, well-formed requirements without starting from a blank page. Try Ash Virtual BA and put a practical tool behind the challenges you are navigating right now.
Further reading
- The Business Analyst’s Challenge: Bridging the Gap Between Business Needs and Data Products | Analyst Catalyst Blog
- 12 Challenges Faced within my Business Analysis Career | Analyst Catalyst Blog
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.