The responsibilities of a BA shift as a project moves through its life. Understanding this arc helps you see where you add value at each stage rather than treating the role as one undifferentiated blob of "analysis."
At the start: understand the problem
- Identify who the stakeholders are — everyone affected by or interested in the outcome.
- Understand the business problem or opportunity that triggered the project.
- Define the scope: what is in, and just as importantly, what is out.
- Establish what success will look like in measurable terms.
During the project: define the solution
- Elicit detailed requirements through interviews, workshops, and document analysis.
- Model processes and data using diagrams — flowcharts, use cases, entity relationships.
- Write clear requirement documents and user stories that the team can build from.
- Prioritise requirements so the most valuable work happens first.
- Manage changes to requirements without letting scope spiral out of control.
Towards the end: validate the outcome
- Support testing by clarifying what "correct" means for each requirement.
- Help define and run user acceptance testing with the business.
- Confirm the delivered solution actually meets the original business need.
- Support the transition as users adopt the new way of working.
A responsibility that runs through every stage: communication. A BA is constantly translating — turning business language into something technical teams can act on, and turning technical constraints into something the business can make decisions about.
Responsibilities that are easy to forget
Beyond the obvious, strong BAs also take responsibility for things juniors often miss:
- Surfacing conflict early. When two stakeholders want incompatible things, the BA's job is to make that visible and help resolve it — not to quietly pick one and hope nobody notices.
- Documenting assumptions. Every project rests on assumptions. Writing them down protects everyone when reality turns out differently.
- Saying "I don't understand yet." The discipline to keep asking until something is genuinely clear, rather than nodding along, is what separates reliable analysis from guesswork.
Practice pointer: for any task you are given, ask yourself "what stage is this project in?" Your most valuable contribution differs depending on whether you are still understanding the problem or already validating a solution.