If you are trying to understand what a business analyst does — either because you are considering the role or because you have just been handed BA responsibilities on a project — the clearest answer I can give you is this: a BA figures out what a business actually needs, translates that into something a team can act on, and keeps every stakeholder pointed in the same direction while the work gets done. That is the job. Everything else flows from it.
I have been doing this work for over 25 years across government, utilities, health, education, and large enterprise environments. The title changes. The methodology changes. The fundamental task does not. You are the person who sits between the people who have a problem and the people who are going to solve it, and your job is to make sure neither side is working on a different version of reality.
What a Business Analyst Actually Does Day to Day
The day-to-day reality of the role is far less tidy than any job description suggests. On a typical project, I might spend the morning in a requirements workshop, the afternoon reviewing process maps I drafted the day before, and the end of the day writing up decisions that were agreed verbally so they do not evaporate overnight. Here is what those activities actually look like in practice:
- Requirements gathering and analysis: I lead sessions with stakeholders to understand what they need the solution to do, using interviews, workshops, and document reviews to produce requirements that are clear enough for a developer or a project manager to act on without coming back to me three times a week.
- Process analysis and improvement: I map out how things work now, identify where the friction is, and recommend changes. This is not just drawing flowcharts — it involves understanding why a process works the way it does before suggesting that anyone change it.
- Data analysis and interpretation: I work with data to find patterns, evaluate performance, and build the evidence base for decisions. Tools like Excel, SQL, and Power BI are part of my regular toolkit, and knowing how to read a dataset is as important as knowing how to run a workshop.
- Solution design and documentation: Once I understand the problem, I help design the solution and document it in a form the team can use — whether that is a Business Requirements Document, a set of user stories, or a use case specification.
- Stakeholder communication and facilitation: I manage relationships across the project, making sure business stakeholders, technical teams, and project managers are all working from the same understanding. This is often where the real work happens.
- Project support: Many BAs contribute to risk tracking, scope management, and delivery coordination. It is not a project management role, but the line blurs regularly in practice.
A Real Example: When the Stakeholders Disagreed About Everything
On one project at a large public sector organisation — I will call them Organisation B — I was brought in to support a digital transformation of their grants management process. The brief sounded straightforward: replace a paper-based application system with a digital one. Within two weeks it was clear the brief was anything but straightforward.
The operations team wanted a system that replicated the existing paper forms exactly, because that was what their assessors knew. The policy team wanted a completely redesigned workflow that reflected new legislative requirements. The IT team had already shortlisted a platform without anyone consulting either of the other two groups. And the executive sponsor wanted the whole thing live in four months.
The friction point came during a requirements workshop I ran in week three. I had mapped the current process and presented it back. The operations manager immediately said the map was wrong — not because I had made an error, but because the process I had documented was the official process, and what actually happened on the ground was different. Nobody had written that down anywhere. That single conversation revealed a gap that would have caused the new system to fail on day one if we had not caught it.
I spent the next two weeks running separate sessions with each group, documenting their needs independently, then bringing them together in a structured prioritisation workshop to work through the conflicts. We used a MoSCoW framework to force decisions about what the first release had to do versus what could come later. The IT team’s platform choice turned out to be workable, but only after we got two requirements removed from scope that the platform could not support. The four-month deadline did not move — but we delivered a first release that actually functioned, with a clear roadmap for the remaining requirements. That is what good BA work looks like: not a smooth run, but a managed one.
Core Skills You Need to Do This Work Well
- Analytical thinking: You need to be able to take a complex, messy situation and break it into parts that can be examined and acted on separately without losing sight of how they connect.
- Communication and negotiation: You will spend a significant portion of your time translating between people who use different vocabularies to describe the same problem — and occasionally mediating when they think they disagree but actually want the same thing.
- Technical literacy: You do not need to write code, but you do need to understand what a system can and cannot do, how data is structured, and what it costs to build something. Technical skills for BAs are more important than many job ads suggest.
- Attention to detail: A requirement that is slightly ambiguous will be interpreted differently by every person who reads it. Precision in documentation is not pedantry — it is risk management.
- Stakeholder management: Building trust with people who have competing priorities, limited time, and no obligation to engage with you is a skill that takes years to develop and cannot be shortcut.
Tools Business Analysts Use Most
| Tool | Primary Use | When I Reach for It |
|---|---|---|
| Excel / SQL | Data extraction, manipulation, and analysis | Whenever I need to understand what is actually in a dataset before I write a requirement about it |
| Power BI / Tableau | Data visualisation and dashboards | When I need to present findings to stakeholders who will not read a spreadsheet |
| JIRA / Confluence | Backlog and documentation management in Agile environments | On any project running sprints where traceability and transparency matter |
| Lucidchart / Visio | Process mapping and system diagramming | When I need to show a stakeholder how something works rather than tell them |
| Balsamiq / Axure | Wireframing and prototyping | When a written requirement is not enough and a visual mock-up will get a faster, better decision |
Types of Business Analyst Role
The BA title covers a wide range of specialisations. Understanding where your interests and background sit can help you target the right opportunities — or know who to bring in when you need support on a project.
- IT Business Analyst: Works primarily on technology projects, bridging business stakeholders and technical teams, writing functional specifications and supporting user acceptance testing.
- Process Analyst: Focuses on operational efficiency, using methodologies like Lean or Six Sigma to map, analyse, and improve end-to-end business processes.
- Data / Business Data Analyst: Specialises in interpreting data and translating it into business recommendations, building dashboards, and supporting KPI reporting. There is meaningful overlap here with the BI analyst role — see the BA vs BI Analyst comparison if you are trying to distinguish between the two.
- Systems Analyst: Goes deep into the technical architecture of business systems, assessing performance, recommending upgrades, and aligning system capability with business needs.
- Product Analyst: Works in Agile and product-centric teams, gathering user feedback, monitoring product performance, and contributing to backlog refinement and roadmap planning.
- Regulatory or Compliance Analyst: Ensures business practices meet legal and regulatory requirements, particularly in finance, health, and insurance. Risk assessment and control design are central to this work.
Where the Role Can Take You
One of the things I value most about BA work is that it builds skills that transfer into almost any direction you want to go. Senior BA, Lead Analyst, and Principal Analyst roles are the most direct progression — more complex projects, more strategic influence, sometimes line management of junior analysts. From there, paths into Product Ownership, Project and Programme Management, Business Architecture, and consulting are all well-trodden routes. If you are thinking beyond the immediate next step, the career progression options after BA are broader than most people realise when they are starting out.
Certifications can support that progression. The IIBA pathway — ECBA for those new to the field, CCBA at mid-level, CBAP for senior practitioners — is the most widely recognised. The PMI-PBA suits BAs working in project-heavy environments. Agile certifications like the IIBA-AAC are increasingly relevant as more organisations run hybrid or fully Agile delivery models.
The Challenges That Will Test You Most
Scope creep, ambiguous requirements, and stakeholder misalignment are the problems that come up in every BA role, in every sector, at every level of seniority. They are not signs that a project is badly managed — they are the normal state of complex work. What changes as you develop is your ability to see them coming earlier and handle them with less friction. A structured approach to requirements prioritisation helps with the first two. The third one — stakeholder misalignment — requires patience, structured facilitation, and the willingness to surface disagreement in a room rather than let it fester in separate email threads.
What a business analyst does, at its core, is make complex change manageable — and the longer you do it, the more you realise that the analytical part is rarely the hardest part. The hardest part is getting people to agree on what the problem actually is before anyone starts building a solution. Every other skill you develop in this role is ultimately in service of that one outcome.
Frequently asked questions
What does a business analyst do every day?
Day to day, a business analyst gathers and documents requirements, maps and analyses business processes, facilitates stakeholder workshops, and produces documentation that guides development or change teams. The mix of activities varies by project phase and methodology. In Agile environments, BAs are typically involved in sprint ceremonies, backlog refinement, and user story writing alongside those core tasks.
What skills does a business analyst need?
The core skills are analytical thinking, written and verbal communication, stakeholder management, and attention to detail in documentation. Technical literacy — understanding how systems work and how data is structured — is increasingly important even for non-technical BA roles. Soft skills like facilitation, negotiation, and the ability to build trust with diverse stakeholders are just as critical as any tool or methodology.
What is the difference between a business analyst and a project manager?
A business analyst focuses on understanding the problem, defining requirements, and ensuring the solution meets business needs. A project manager focuses on delivery — managing timelines, budgets, resources, and risk. The two roles often work closely together, and on smaller projects one person may cover both, but they are distinct disciplines with different primary accountabilities.
What tools does a business analyst use?
Common tools include Excel and SQL for data analysis, Power BI or Tableau for visualisation, JIRA and Confluence for Agile project management, and Lucidchart or Visio for process mapping and diagramming. Wireframing tools like Balsamiq or Axure are used when visual mock-ups are needed to support requirements. The specific tools depend heavily on the organisation and project type.
How do I become a business analyst with no experience?
Most people enter the BA field by transitioning from a related role — operations, project coordination, systems support, or a functional domain like finance or HR — where they already use analytical and communication skills. Building familiarity with BA tools, completing a foundational certification like the IIBA ECBA, and being able to articulate the analytical work you have already done are the most practical starting points. Targeting organisations that hire junior or associate BA roles, rather than applying for mid-level positions, gives you the best chance of getting your first formal BA role.
Try Ash, Your Virtual BA
If this article has given you a clearer picture of what business analysis involves, Ash can help you go deeper on any part of it — whether that is understanding BA terminology, working through a requirements challenge, or getting a sharper answer on a concept you are trying to explain to a stakeholder. Ash is built specifically for BA work, drawing on real business analysis methodology rather than generic AI responses. It is the kind of resource I would have wanted at the start of my career and still find useful now. Try Ash Virtual BA and see what it can do for the work you have in front of you today.
Further reading
- What is a Business Analyst? | IIBA
- What is Business Analysis? | Global Standard for Business Analysis Certification | IIBA®
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.