Accenture Business Analyst — Interview Questions
Accenture Business Analyst Interview Questions
Accenture's Business Analyst role sits between the client and the delivery team — translating a business problem into requirements a technical team can build against, then defending those requirements when priorities shift mid-project. Because Accenture staffs BAs across nearly every industry (banking, retail, telecom, life sciences, public sector), interviewers care less about domain trivia and more about whether you can structure ambiguity, communicate trade-offs to non-technical stakeholders, and hold a line when a client pushes back. This guide covers the scenarios that come up most often and what a strong answer sounds like.
Accenture's Interview Process for Business Analyst
Most candidates go through three stages: an HR/recruiter screen focused on motivation and fit, a group business case designed to test how you reason and collaborate under time pressure, and a final round with a manager or senior consultant that digs into your approach on real BA work — requirements gathering, stakeholder conflict, documentation. Campus and high-volume pipelines often insert an asynchronous HireVue-style video round (3–8 competency questions, timed) between the screen and the case round.
Question 1: The Finance-vs-Ops Requirements Conflict
You're the BA on a supply chain modernization project for a retail client. Two weeks before go-live, the client's finance lead tells you the new reporting module has to cut a planned integration to stay under budget. The same afternoon, the ops lead tells you that integration is the only reason the warehouse team agreed to the rollout at all. Both are cc'd on the same email thread, both expect an answer by end of day, and your project manager is unreachable until tomorrow. What do you do?
Why interviewers ask this
This tests whether you default to picking a side (and whose) or whether you first separate the stated positions from the underlying needs. Weak candidates escalate immediately or promise something to whichever stakeholder is more senior. Strong candidates slow down enough to find out what each side actually needs before committing to anything in writing.
Example strong answer
I'd reply to both within the hour, but not with a decision — with a holding statement acknowledging I've seen both notes and I'm looking into options before end of day, so neither person is left assuming I've sided with the other. Then I'd get on a call with each of them separately. With finance, I'd ask what specifically is driving the budget cut — is it a hard ceiling this quarter, or a target that has some flexibility if I can show the integration pays for itself later? With ops, I'd ask what breaks operationally without the integration — is it a nice-to-have they're attached to, or does the warehouse team genuinely have a fallback process if it's delayed rather than cut?
Often this reveals the two positions aren't as opposed as the email thread makes them sound. In this case, say finance's real constraint is this quarter's capex, and ops's real requirement is having the integration live before peak season in four months. That gives me a third option neither of them proposed: phase the integration into next quarter's budget instead of cutting it, which satisfies finance's timing constraint and ops's functional requirement.
I'd document both original asks, the actual constraints behind them, and the phased option, then send a short summary to both stakeholders and my PM proposing the phased approach with a specific date for the delayed piece — not asking them to decide between two bad options, but giving them one they can both accept. I'd flag to my PM separately that finance and ops are misaligned on budget assumptions beyond just this ticket, since that's a pattern worth surfacing before it recurs on the next deliverable.
Follow-up questions
- Finance says the phased option still doesn't work — the capex line is truly zero until next fiscal year. What's your next move?
- Two days later, ops finds out about the finance conversation from someone else and feels blindsided. How do you handle that?
Question 2: The Vague Client Ask
A client stakeholder emails: "We need better visibility into our order fulfillment process — can you put together some requirements?" That's the entire brief. You have a kickoff call in three days.
Why interviewers ask this
Accenture BAs get requests like this constantly, and Accenture is graded by the client on whether the eventual solution actually solves the problem — not just whether it matches a literal request. This question checks whether you can convert a vague ask into a scoped, testable set of requirements without either guessing or bombarding the client with an overwhelming questionnaire.
Example strong answer
Before the kickoff, I'd do two things. First, I'd look at what's already documented — support tickets, prior project notes, any existing process maps — to form a hypothesis about where the actual pain is. "Better visibility" from an order fulfillment team usually means one of three things: they can't see where an order is stuck, they can't tell which delays are their fault versus a carrier's, or leadership can't get an aggregate view without asking someone to pull a report manually. Second, I'd draft 5–6 targeted questions built around those hypotheses rather than a generic requirements checklist, so the call has structure even if my hypotheses are wrong.
In the call itself, I'd ask them to walk me through what happens today when someone asks "where is order #12345" — who do they call, how long does it take, what system do they check. That single walkthrough usually surfaces the real gap faster than asking "what are your requirements" directly, because people are much better at describing what's broken in a concrete scenario than articulating an abstract need.
From there I'd draft a one-page requirements summary — the specific visibility gaps we uncovered, who's affected, and 3–4 candidate solutions ranked by effort — and send it back to the stakeholder for a sanity check before treating anything as final. That gives them one clear document to react to, which is much faster for them than reviewing a formal requirements spec, and it protects me from building against an assumption they never actually confirmed.
Follow-up questions
- The stakeholder reads your one-pager and says "this isn't really what I meant" without being able to say what he did mean. What now?
- You discover during the walkthrough that the real problem is a data quality issue three systems upstream, not a visibility problem at all. Do you say so, and how?
Question 3: Recommending With Incomplete Data
Three days before a client steering committee, you're asked to recommend whether to expand a pilot program to two more regions. Your data only covers 6 weeks of the pilot, and the two weeks with the strongest results overlapped with a promotional campaign that won't repeat. What do you tell the committee?
Why interviewers ask this
Accenture engagements run on timelines that rarely align with when "enough" data exists. This tests intellectual honesty under pressure to deliver a confident-sounding answer, and whether you can still be useful — recommend something — without overstating what six weeks of promo-skewed data can support.
Example strong answer
I wouldn't present a single number as if it were a clean answer, because it isn't one, and a steering committee making a multi-region investment decision deserves to know that. I'd separate the results into promo weeks and non-promo weeks and present both, showing the pilot performed well even excluding the promo period, but at a meaningfully lower magnitude — say the pilot did 22% better than baseline overall, but roughly 11% better once the promo weeks are excluded.
Then I'd frame the recommendation around that honest range rather than around the headline number: I'd recommend expanding to one region first, not two, with a defined 8-week measurement window and no promotional overlap, specifically so the next data point is clean enough to justify (or not justify) full rollout. That gives the committee a real decision — move forward, but de-risk the investment — instead of either a false-confidence "yes, expand to both" or an unhelpful "we don't have enough data yet."
I'd also flag the specific gap upfront in the deck itself, not bury it in an appendix, because the client finding out later that the strongest data point was promo-driven damages trust in every number after it. Being the person who surfaces that risk before it becomes a problem is part of what makes a BA useful in the room, not just a slide-builder.
Follow-up questions
- The client sponsor pushes back and says the promo overlap doesn't matter, they want to move fast on all regions. How do you respond?
- How would you have structured the pilot differently from the start to avoid this exact problem?
Question 4: Scope Creep After Sign-Off
Requirements were signed off six weeks ago. In today's check-in, the client casually mentions a feature they assumed was "obviously" included, and it wasn't scoped or estimated. The delivery team is already building against the signed requirements. What do you do in that meeting, and after?
Why interviewers ask this
This is one of the most common friction points on Accenture delivery engagements. Interviewers want to see you protect the project's scope and timeline without making the client feel dismissed or accused of moving goalposts — because how you handle that moment shapes the client relationship for the rest of the engagement.
Example strong answer
In the meeting, I wouldn't argue the point live or agree to anything on the spot. I'd acknowledge it directly — "that's a fair assumption, let me check exactly what was scoped and come back to you today" — which buys time without either promising it's in or flatly saying it's out, and signals I'm not dismissing their concern.
After the meeting, I'd pull the signed requirements doc and confirm precisely what's in and out, then estimate the actual effort to add the feature — not a guess, a real number from the delivery lead. I'd bring both back to the client together: here's what was scoped, here's why this specific feature wasn't in it, and here's what adding it now costs in time or budget, with two or three concrete options — add it now with a defined timeline impact, add it in a phase 2, or descope something else of similar effort to make room.
What I wouldn't do is frame it as "you're wrong, it wasn't included" even if that's technically true, because the client's experience is that they thought it was covered, and a purely contractual response damages the relationship even when I'm right on paper. The goal is to be accurate about scope while giving them a real choice, not to win the argument about what was originally agreed.
Follow-up questions
- The client says the delay this causes isn't acceptable and implies Accenture should absorb the extra work for free. How do you handle that?
- How would you change the sign-off process on your next project to reduce how often this happens?
Question 5: Prioritizing a Backlog Under Conflicting Urgency
Three stakeholders each tell you their backlog item is "the most urgent" for the next sprint, and you only have capacity for one. None of them has visibility into what the others asked for. How do you decide, and how do you communicate it?
Why interviewers ask this
This checks whether you have an actual method for prioritization — impact, effort, dependency, risk — versus just picking whoever asked loudest or most recently. It also tests how you communicate a decision that two of three people won't like.
Example strong answer
I'd start by getting each stakeholder to tell me not just that their item is urgent, but what specifically breaks if it doesn't ship this sprint — a hard deadline, a dependency blocking another team, a compliance risk, or just strong preference. That single question usually separates real urgency from perceived urgency; in my experience at least one of three "urgent" items turns out to be flexible once you ask what actually happens if it slips a sprint.
Then I'd score the three against a simple, consistent frame — business impact, effort required, and what else depends on it being done first — rather than an ad hoc judgment call, so the outcome is defensible if questioned later. Say one item unblocks a downstream integration two other teams are waiting on, one is a genuine hard deadline tied to a regulatory filing, and the third is valuable but has no dependency and no fixed date. The regulatory one likely wins on risk, but I'd flag the dependency-blocking one as a close second that should be next in line, not dropped.
When I communicate the decision, I wouldn't just announce the winner. I'd tell each of the other two specifically why their item didn't make this sprint and when it's realistically coming — vague deferrals are what make stakeholders escalate over your head, whereas a concrete "this is next sprint, here's why" usually holds even when they're disappointed.
Follow-up questions
- One of the deprioritized stakeholders escalates directly to your project sponsor before you've had a chance to explain your reasoning. What do you do?
- How would you build a lighter-weight version of this prioritization method that doesn't require a full scoring exercise every sprint?
Preparation tip
The strongest Accenture BA candidates don't just answer the question asked — they narrate how they'd find out more before answering, because that's what the actual job rewards. If your answer to an ambiguous scenario is a clean, confident plan with no mention of what you'd verify first, it usually reads as naive rather than decisive.