How to Hire a Business Analyst for an IT Project: Skills, Red Flags, and Interview Tips

We’ve seen it more than once: a company hires a BA, the project kicks off, and six months later the dev team is building something nobody asked for. Developers blame unclear requirements. The BA says stakeholders kept changing their minds. Stakeholders say nobody listened. Everyone’s right, and the project is a mess.

A bad BA hire doesn’t announce itself upfront. The CV looks fine, the interview goes smoothly, and the problems only show up once the work starts — by which point you’re already behind. This guide is about avoiding that. We’ll cover what to actually look for in a BA candidate, the seniority question, red flags that rarely appear on CVs, and the interview questions that separate people who know how it’s done from people who’ve watched it happen from a distance.

1. What a Business Analyst Actually Does — and What They Don’t

Ask ten hiring managers to describe the BA role and you’ll get eight different answers. That’s the root of most bad BA hires: the company doesn’t know what it needs, so it can’t screen for it effectively.

A BA on an IT project is the person responsible for making sure the dev team builds the right thing. Not the fast thing or the cheap thing — the right thing. They do that by getting clear on what stakeholders actually need (which is often different from what they say they want), documenting those needs in a form engineers can work from, and staying close enough to the process to catch misunderstandings before they become expensive bugs.

Day to day that looks like: stakeholder interviews and workshops, writing requirements documents and user stories, process modelling, and a lot of back-and-forth between the business and the dev team to keep everyone aligned.

What a BA is not: a project manager (they don’t own timelines or budgets) or a product owner (they don’t set product vision or run the backlog). These roles overlap in practice, but they’re not the same thing. When you blur them in a job description, you end up with a candidate who’s unclear on their own responsibilities — and that ambiguity gets expensive fast.

2. The Skills Worth Screening For

Hard skills

On the technical side, here’s what actually matters for IT projects:

• Requirements documentation — BRDs, user stories with clear acceptance criteria, use cases. The benchmark isn’t polish; it’s whether a development team can build from the document without making assumptions. If the requirements leave room for interpretation, they’re not done.
• Process modelling — BPMN for business flows, basic UML for system interactions. Expert-level proficiency isn’t a prerequisite, but a BA should be able to produce diagrams that are accurate, readable, and actionable — not just illustrative.
• Tool fluency — Jira, Confluence, Miro are standard in most IT environments. A candidate with several years of BA experience who hasn’t worked with these tools warrants a direct conversation about how they’ve managed requirements and collaboration in practice.
• SQL fundamentals — reading queries, validating data, understanding table relationships. A BA who can independently verify that data behaves as specified adds meaningful value; one who relies entirely on developers for data validation creates a bottleneck.
• Agile/Scrum in practice — not familiarity with the terminology, but working knowledge of how requirements move through sprints, what a well-groomed backlog looks like, and how to handle scope changes without derailing delivery.

The IIBA BABOK Guide covers elicitation and collaboration as a core competency area — and in our experience hiring BAs, it’s the one that sets strong candidates apart from the rest.

Soft skills

This is where most interviews fall short. Hard skills get candidates through the door; it’s the soft skills that determine whether the project works.

• Communication that goes both ways — explaining technical constraints to a CFO without talking down to them, and translating a VP’s vague vision into something a backend developer can act on. Both directions matter.
• Knowing when to push back — a BA who just transcribes whatever stakeholders say isn’t doing the job. Part of the role is flagging when a request doesn’t make sense, conflicts with something else, or is going to create scope problems down the line.
• Workshop facilitation — getting a room of people with different priorities to agree on requirements is a skill. Some people are naturals; others make it worse. You want someone who’s done it enough times to know how to manage the room.
• Handling conflict between dev and business — it’s going to happen. A good BA gives both sides a shared reference point instead of becoming another source of noise.

3. Junior, Mid-Level, or Senior — Which Do You Actually Need?

Hiring the wrong seniority level is an expensive mistake, and it goes both ways.

The honest question to ask: how much ambiguity is baked into this project? The answer tells you the seniority you need.

4. Red Flags That Don’t Always Show Up in CVs

Most of these only become visible when you actually talk to the candidate. Watch for:

Vagueness. A good BA can tell you about a specific project, a specific problem they ran into, and specifically what they did. “I was responsible for requirements gathering across multiple workstreams” is not that. If they can’t provide any specifics, the experience probably isn’t as deep as the CV suggests.

They can’t separate their role from the PM’s or PO’s. When a candidate describes their past work, do they know where their job ended and someone else’s began? Confusion here usually means they were either doing a bit of everything without real ownership, or crediting themselves with work that belonged to their team.

The portfolio is underwhelming. Ask to see a requirements document or user story set before the interview. If what they bring is thin, generic, or copy-pasted from a template — and they can’t explain why they made the choices they made — that’s a problem. Templates aren’t bad; not knowing why you used one is.

“Agile” is on the CV but doesn’t survive questioning. Ask how requirements changed on a live project. Ask what they did when a sprint was halfway done and the stakeholders wanted to change direction. “We held a meeting” is not an answer.

No curiosity about the business. Some BAs treat requirements like a clerical task — gather, document, hand off. The good ones genuinely want to understand why the business needs what it needs. That curiosity is what makes the difference between requirements that pass review and requirements that deliver results.

5. Interview Questions Worth Asking

Generic interview questions produce generic answers. Behavioural questions — the kind that ask for a specific past situation rather than a hypothetical — are consistently better predictors of on-the-job performance. Here’s what we’d ask:

“Take me through how you got requirements out of stakeholders on a project that was genuinely complicated.”

You want specifics: who was in the room, what techniques they used, what went wrong. A candidate who can’t get specific here hasn’t done the hard version of this work.

“Tell me about a time the dev team and the business side were pulling in opposite directions. What did you do?”

You’re not looking for someone who made everyone happy — that’s usually a sign they avoided the conflict. You want to hear how they navigated it.

“What do you do when the requirements you’re getting are contradictory or incomplete?”

There should be a process here: flag it, trace it back to the source, get a documented decision. “I go back to the stakeholder” without any follow-up structure is a weak answer.

“Show me something you wrote — a user story set, a BRD, a process diagram — and walk me through it.”

The artifact is less important than whether they can explain the thinking behind it. If they’re defensive or vague, that tells you something.

“How do you make sure what you’ve documented is actually what was wanted?”

Sign-off processes, review loops, UAT involvement — there should be a real answer here. A BA who considers their job done when they hand off the document is a liability.

“Have you ever told a stakeholder their request wasn’t going to work? What happened?”

How a candidate handles this question tells you a lot about their confidence and communication style. Pushback is part of the job. Someone who’s never done it either hasn’t been in the right situations or has been avoiding them.

“What’s your first move when you join a new project?”

Stakeholder mapping, reviewing existing documentation, identifying what’s already been decided — a thoughtful answer here shows someone who understands that good requirements work starts before you write a single line.

6. How to Run a Hiring Process That Actually Works

The CV screen matters less than most hiring managers think. Here’s where to focus:

Write a job description that reflects the actual project. Generic BA job descriptions attract generic BA candidates. Describe the domain, the team setup, the stage of the project, what good output looks like. Candidates who’ve done that specific kind of work will recognise it and apply; the wrong profiles will self-select out.

Ask for a work sample upfront. A requirements document, a set of user stories, a process model — something they actually produced. Review it before you interview them. It’ll change the questions you ask.

Run a short case study with shortlisted candidates. Give them a realistic scenario: a vague brief from a fictional stakeholder, some buried contradictions, a tight scope. Ask them to produce a rough requirements outline. What they produce and how they reason through it will tell you more than a two-hour interview.

Get developers in the room. A BA who impresses the HR team but confuses the engineers isn’t the right hire. Run at least part of the interview with someone from the technical side.

Check references on specific outputs. “Was this person good to work with?” is not a useful reference question. Ask whether their documentation was actually usable, whether stakeholders trusted them, how they handled situations where requirements changed late in the process.

7. Should You Hire Directly or Use a Recruitment Agency?

If you have a solid internal HR function, a clear brief, and a few weeks to run a proper process, you can absolutely hire a BA yourself. HR consulting support can help structure the process if you haven’t hired for this role before and want a framework that’s actually been tested.

Where agencies earn their fee is in specific situations: you need someone fast, the domain is niche (fintech, healthcare, enterprise ERP), or you’ve already run a search and it stalled. A good IT recruitment agency has pipelines of pre-vetted candidates and can get you to a shortlist weeks faster than a cold search — which matters a lot when a project is already waiting for the hire.

8. Hiring Models: Which Engagement Format Fits Your Situation

Knowing what kind of BA to hire is one question. Knowing how to engage them is another. The same candidate can be brought on through five different models — and the right choice affects cost, speed, legal exposure, and how much control you actually have over the work. Here’s how each model works in practice.

Direct Hiring

The BA becomes your employee. You handle the contract, payroll, benefits, and all HR obligations. You get full control over how they work, who they report to, and how their role evolves over time.

Best for: Long-term roles where you need the BA embedded in the team, building institutional knowledge over time. If requirements work is a continuous function in your organisation rather than a project-specific need, a direct hire usually makes economic sense within 12–18 months.

Watch out for: The full cost of employment — salary, employer taxes, benefits, onboarding — and the time it takes to run the process. If the need is project-bound, you may end up with a BA on payroll who has nothing meaningful to do once the project wraps.

Outstaffing (Staff Augmentation)

A vendor provides the BA, who works under your direct management — joining your team, following your processes, and reporting to your people. The vendor handles employment, payroll, and HR. You get operational control without the administrative overhead of being the employer of record.

Best for: Filling a specific gap in your team for a defined period — a project ramp-up, a maternity cover, or scaling without committing to headcount. You get the control of a direct hire with significantly less administrative burden, and you can scale up or down more easily.

Watch out for: Vendor margins mean the hourly or monthly rate is higher than a direct hire on an equivalent salary. And if the BA is on the vendor’s bench, you have less visibility into who you’re getting before they start. Vet the individual, not just the vendor.

Outsourcing

You hand off a defined deliverable — a requirements specification, a discovery phase, a full business analysis workstream — to an external team or consultant. The vendor manages their own people and methods. You specify the output; they figure out how to produce it.

Best for: One-off projects with a clearly scoped BA component, or situations where you need specialist expertise — a discovery phase for a fintech product, say — that doesn’t justify a permanent hire. You pay for the outcome, not the hours.

Watch out for: Less day-to-day visibility. If the deliverable spec isn’t tight, you may not discover the gap until review. Outsourcing works best when you know exactly what you need; it works worst when you’re still figuring that out.

EOR (Employer of Record)

A third-party company legally employs the BA in their jurisdiction on your behalf. You manage the work; the EOR handles local employment contracts, payroll, tax compliance, and benefits. This is typically used when you want to hire someone in a country where you don’t have a legal entity.

Best for: Hiring international talent compliantly — particularly relevant when you’ve found the right candidate in a different country and don’t want to set up a local entity just to employ one person. EOR is increasingly common for hiring BAs in Eastern Europe or Southeast Asia while keeping day-to-day management onshore.

Watch out for: EOR adds a service fee on top of the employment cost — typically 10–20% of gross salary. You’re also dependent on the EOR provider’s local compliance expertise, so due diligence on the provider matters as much as due diligence on the candidate.

PEO (Professional Employer Organisation)

Similar to EOR, but under a co-employment structure: both you and the PEO are considered employers, with the PEO handling HR administration, payroll, and compliance while you retain control over day-to-day work direction. PEOs typically operate within a single country and work best when you already have a legal presence there.

Best for: Companies that want to offload HR complexity without losing visibility into their team. If you’re scaling headcount quickly and HR administration is becoming a bottleneck, a PEO lets you move faster without building out the function internally. It’s also a good fit when you want to offer competitive benefits without the overhead of running them yourself.

Watch out for: The co-employment model creates shared liability, which can complicate terminations and disputes. Make sure the agreement clearly delineates which decisions belong to you and which to the PEO. And unlike EOR, a PEO typically can’t operate across borders — if you need to hire internationally, EOR is usually the right call.

Which Model to Choose

The honest answer is that it depends on three questions: how long do you need this person, how much management overhead can you absorb, and where are they located? A long-term embedded BA in your home market is usually a direct hire. A specialist BA for a six-month project in another country is usually EOR or outstaffing. A defined discovery phase with a clear deliverable is usually outsourcing. Most organisations end up using different models for different situations — the mistake is defaulting to one approach regardless of context.

Conclusion

The reason BA hires go wrong so often isn’t that there aren’t good candidates out there. It’s that the hiring process is usually too generic to find them. Resumes don’t show documentation quality. Competency questions don’t reveal whether someone can actually manage a difficult stakeholder conversation. And seniority titles mean different things in different companies.

A more practical approach works better: ask for work samples upfront, run a case study, ask questions about real situations, and get developers into the interview. It takes more time than a standard two-stage screen, but it’s worth it. A bad BA hire — even on a six-month project — can cost significantly more than a recruiter’s fee.If you’re working through a Business Analyst search right now and want a team that’s placed BAs across IT projects of all sizes and domains, we’re happy to talk through what good looks like for your specific situation.