The question of which business analyst is best comes up every time a project kicks off, a team expands, or a hiring panel convenes. I have sat on both sides of that table over 25 years, and the answer is never as simple as the person with the most impressive CV or the longest list of certifications. The right BA for one project can be entirely wrong for another. What matters is understanding what your project actually needs, and then being honest about whether the person in front of you can deliver it.
This is not a theoretical exercise. Getting this wrong costs real money and time. I want to walk you through the criteria that genuinely separate effective BAs from ineffective ones in practice, with a worked example from a regulated environment that shows what happens when the match is poor.
Start With What the Project Actually Needs
Before you assess any individual, you need to be clear on the demand side. I have seen hiring managers reach for generic interview questions before they have articulated what the project requires. That approach reliably produces mediocre outcomes. The profile of the BA you need changes significantly depending on whether you are running a process improvement initiative, a system replacement, a regulatory compliance programme, or a digital transformation. Each requires a different emphasis.
If you are trying to assess what a BA typically contributes across these contexts, the article on Business Analyst Roles and Responsibilities is a useful reference point before you start designing your assessment criteria.
The Five Criteria That Actually Predict Performance
I use a consistent set of criteria when I am evaluating BA capability, whether I am hiring, building a team, or advising a client on resourcing. These are not theoretical competencies lifted from a certification framework. They are the things I have seen make or break project delivery over and over again.
- Analytical rigour: A strong BA does not just collect information, they interrogate it. I want to see evidence that a candidate has challenged data, questioned assumptions, and pushed back when something did not add up, even under stakeholder pressure.
- Communication across boundaries: The BA role sits between business and technology. The best BAs I have worked with can shift register fluently, speaking in business outcomes with executives and in system behaviour with developers, without losing precision in either direction.
- Domain knowledge applied to problems: Generic BA skills travel, but domain knowledge accelerates delivery. A BA who already understands how a regulated industry works, what the compliance constraints look like, and where the operational pain points typically sit, will spend less time getting oriented and more time adding value.
- Technical literacy: Not every BA needs to write SQL or configure systems, but a working understanding of data structures, integration patterns, and system constraints is increasingly essential. If you want to explore this in more depth, the article on Technical Skills Required for a Business Analyst covers this well.
- Structured problem-solving: Good BAs bring method to ambiguity. They know how to define a problem before jumping to solutions, how to prioritise when everything feels urgent, and how to keep stakeholders focused on outcomes rather than feature lists.
A Comparison: Generalist BA vs Specialist BA
One of the most common decisions I see organisations get wrong is choosing between a generalist and a specialist. Both have genuine strengths. The table below sets out the key trade-offs as I have experienced them in practice.
| Dimension | Generalist BA | Specialist BA |
|---|---|---|
| Ramp-up time | Longer, needs domain orientation | Shorter, already understands the context |
| Adaptability | High, comfortable across sectors | Lower, may struggle outside their domain |
| Stakeholder credibility | Must earn it through process | Often arrives with it, based on shared knowledge |
| Fresh perspective | High, less likely to accept the status quo | Lower, assumptions may mirror the organisation |
| Best suited to | Process redesign, cross-functional programmes | Compliance, system replacement, regulatory change |
| Risk of blind spots | May miss domain-specific constraints | May over-fit solutions to familiar patterns |
A Real Example: When the Wrong Match Created Real Problems
On Project X, a mid-sized financial services organisation brought in a BA with strong generalist credentials and a track record in retail operations. The project was a regulatory reporting overhaul, driven by a change in reporting obligations from the regulator. On paper, the BA looked capable. Good communication skills, solid workshop facilitation, familiar with agile delivery.
The friction started in week three. The compliance team, led by a senior manager who had been through two previous regulatory programmes, pushed back hard on the BA’s process maps. The maps were technically accurate but missed several implicit rules about data lineage and audit trail requirements that anyone familiar with the regulatory context would have known to capture. The senior manager was not subtle about it. She told the project sponsor directly that she did not have confidence in the analysis being produced.
The BA was not incompetent. The problem was a misalignment between what the project needed and what the BA was equipped to deliver without significant support. We resolved it by pairing the BA with a subject matter expert from the compliance team, which added time and cost that had not been budgeted. The BA adapted well once they understood the domain constraints, but the first six weeks were slower and more fraught than they needed to be.
That experience reinforced something I had already learned from earlier projects: the question is never simply who is the best BA in the abstract. It is who is the best BA for this project, at this stage, in this environment.
Certifications and Education: What They Signal and What They Do Not
Certifications like the CBAP or the ECBA signal commitment to the profession and a structured understanding of BA frameworks. They are worth factoring in, particularly for early to mid-career candidates where project track record is still limited. But I have worked with CBAP-certified BAs who struggled to manage a difficult stakeholder conversation, and I have worked with uncertified BAs who produced some of the most rigorous requirements documentation I have seen on any project.
Education is similar. A BA with a background in finance, economics, or a regulated discipline will typically ramp up faster on projects in those domains. But the educational background tells you about foundations, not about what someone has done with those foundations in practice. Weight experience over credentials wherever you have evidence of both.
Cultural Fit and Working Style
This is the criterion that gets underweighted most consistently. I have seen highly capable BAs fail not because of skill gaps but because their working style conflicted with the organisation’s operating rhythm. A BA who is accustomed to agile ceremonies and fast iteration will find waterfall-heavy, governance-dense environments deeply frustrating, and that frustration tends to show in the quality of their work and their relationships with stakeholders.
Ask about environments the candidate has worked in, not just roles. Ask how they handled a situation where the governance structure slowed them down. Ask what they do when a stakeholder refuses to engage. Those answers reveal more than any formal competency question. If you want to understand what to look for when someone is operating at their best in the BA role, the piece on The Business Analyst Mindset is worth reading alongside this one.
How to Structure Your Assessment
When I am putting together an assessment process for a BA role, I keep it practical. I am not interested in abstract answers about methodologies. I want to see how someone thinks through a real problem.
- Present a messy scenario: Give the candidate a brief description of a project with incomplete information and conflicting stakeholder positions. Ask them to talk through how they would approach it. You are looking for structured thinking, not a perfect answer.
- Ask for a specific example of pushback: Ask them to describe a situation where a stakeholder disagreed with their analysis and how they handled it. Candidates who cannot recall a moment of friction have either not done much real BA work or are not being honest.
- Review a work sample: If the role involves documentation, ask to see a real example, with sensitive details removed. A process map, a requirements set, or a business case extract tells you far more than any verbal description of their approach.
- Test domain awareness: Ask one or two questions that only someone with genuine domain experience would answer well. Not trick questions, but questions that require applied knowledge, not just general awareness.
The best BA for your organisation is the one who can do the specific work your project demands, earn the trust of the stakeholders who matter most to that project, and adapt when the conditions change. Every other consideration is secondary to that. No certification, no title, and no years of experience can substitute for that combination delivered in the right context.
Frequently asked questions
Which business analyst is best for a regulated industry project?
For regulated industry projects, a BA with direct domain experience in that sector will almost always outperform a generalist in the early stages of delivery. They will already understand the compliance constraints, data governance expectations, and stakeholder sensitivities that take a generalist weeks to learn. Pairing a generalist with a subject matter expert is a viable alternative but adds cost and coordination overhead.
Is a CBAP certified business analyst better than an uncertified one?
Certification signals professional commitment and a structured understanding of BA frameworks, but it does not guarantee performance on a specific project. I have worked with certified BAs who struggled with stakeholder dynamics and uncertified BAs who produced exceptional work. Weight project track record and demonstrated skills over credentials wherever you have evidence of both.
What is the difference between a generalist and a specialist business analyst?
A generalist BA brings adaptability and a fresh perspective, which works well on cross-functional or process redesign projects. A specialist BA brings domain depth and faster credibility with subject matter experts, which matters most on compliance, regulatory, or system replacement programmes. The right choice depends on the nature and risk profile of your project.
How do I assess a business analyst before hiring them?
Present a realistic messy scenario and ask the candidate to talk through their approach, looking for structured thinking rather than a perfect answer. Ask for a specific example of stakeholder pushback and how they handled it. Review a real work sample such as a process map, requirements set, or business case extract with sensitive details removed.
Can a business analyst with no domain experience still be effective?
Yes, but the ramp-up period will be longer and the risk of missing domain-specific constraints is real. The best way to manage this is to pair the BA with an embedded subject matter expert and to build in additional review checkpoints early in the project. Clear expectations about the learning curve need to be set with the project sponsor from the outset.
Try Ash, Your Virtual BA
If this article has raised questions about BA skills, role definitions, or how to position yourself or your team for the right kind of work, Ash can help you go deeper. Ash is trained across 25 years of real BA practice and can answer specific questions about competencies, career positioning, and what strong BA work actually looks like across different project contexts. Whether you want to explore a specific skill gap or talk through what a particular BA role demands, Ash gives you a direct, practical answer grounded in the discipline. Try Ash Virtual BA.
Further reading
- Why NOW is the Best Time to Earn a Business Analysis Certification | IIBA® Business Analysis Blog
- Global Standard for Business Analysis Certifications | IIBA®
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.