What Does a Business Analyst Do on a Real Project?

If you are trying to work out what a business analyst does before committing to the role, or you are already in it and wondering whether your day looks like everyone else’s, start here. What does a business analyst do? The honest answer is that the job is mostly reading, questioning, writing, and managing the gap between what people think they agreed and what is actually in the document. That is a very different picture from the “bridge between business and technology” framing you will find in most job descriptions, and understanding the difference matters if you want to do the work well.

I have been doing this work for 25 years across government agencies, water utilities, hospitals, universities, and large enterprise technology programmes. What follows is an account of what the role actually involves, structured around the moments that define a real project day, not a theoretical one.

What a BA Does Before the First Stakeholder Meeting

Most project days start at a desk, reading. Before I speak to a single stakeholder on a new project, I spend time understanding the environment I am walking into. That means working through previous project documents, policy papers, system documentation, annual reports, and any requirements that have been captured before and abandoned. This is called desktop analysis, and it is one of the most underrated parts of the job.

The reason it matters is that stakeholders tell you what they think you need to know. Desktop analysis tells you what they forgot to mention, what has been tried before and failed, and what constraints exist that nobody flags in a kick-off meeting because everyone has already accepted them as permanent. Walking in having already read the background material changes the quality of every conversation you have from that point forward.

On a project I worked on for a public sector environment agency, I spent three days reading legislative instruments and internal policy documents before I met anyone. In the first workshop, a senior manager made a statement about what the system needed to do that directly contradicted a regulatory obligation I had found in my reading. If I had not done that preparation, I would have documented her requirement without question. Instead I was able to flag the conflict on the spot. She pushed back initially, certain she was right, but when I showed her the specific clause in the legislation she went quiet. That moment changed the dynamic of the entire engagement. She trusted my judgement from that point in a way she would not have otherwise, and it set the tone for every workshop that followed.

What a BA Does in a Stakeholder Meeting

A stakeholder meeting is not a passive experience. You are not there to listen and take notes, although you do both. You are there to ask questions the stakeholder has not thought to answer yet, and to surface the real need behind the stated requirement.

The most important skill in a stakeholder interview is understanding the difference between what someone says they want and what the business actually needs. A stakeholder who says “I need a report showing all customer complaints by region” actually needs to identify which regions have systemic service problems so she can allocate resources. The report is one possible solution. It might not be the right one. Getting to the underlying need before jumping to a solution is the core discipline of the role, and it is harder than it sounds when you are in a room with someone who is certain they already know exactly what they want.

I use a simple test in every stakeholder interview: for every requirement I hear, I ask what decision it supports or what problem it solves. That question surfaces the real need more reliably than any formal elicitation technique I have encountered. For a deeper look at how to structure those conversations, the requirements elicitation questions guide on this site is worth working through before your next session.

What a BA Does Between Meetings

This is the part of the job that nobody talks about, and it is where most of the actual work happens. Between meetings, a BA writes. A lot. Here is what that output looks like in practice:

Requirements documents: Structured records of what the solution needs to do, written precisely enough that a developer can implement against them and a business stakeholder can validate them without ambiguity.
Process maps: Visual representations of how work currently flows and how it should flow after the change is implemented, used to surface gaps, duplications, and decision points that verbal descriptions miss.
Gap analyses: A comparison of the current state against the desired state that identifies specifically what needs to change to get from one to the other.
Meeting summaries: A record of decisions made, issues raised, and actions agreed, because if it is not written down it did not happen and will be disputed later.
Stakeholder registers: A living document that tracks who has an interest in the project, what they care about, and how they need to be kept informed as the work progresses.

None of this writing is glamorous. All of it is essential. The BA is the person on a project team who produces the paper trail that everyone else relies on to make decisions. If that trail is incomplete, ambiguous, or poorly structured, the project suffers in ways that are invisible until they become very expensive. The relationship between documentation and analysis is worth understanding clearly, and the article on business analyst documentation versus analysis covers exactly where the line sits.

A Real Project Day: What It Actually Looks Like

Time	Activity	What Is Actually Happening
8:30am	Review notes from yesterday	Identifying questions that need answers before the morning workshop
9:00am	Stakeholder workshop	Eliciting requirements, resolving conflicting views, documenting decisions in real time
11:00am	Write up workshop outputs	Turning notes into structured requirements, flagging gaps and open questions
12:30pm	Informal conversation with a developer	Checking whether a requirement is technically feasible before committing it to the document
1:30pm	Update the requirements register	Numbering new requirements, setting priorities, updating status on existing ones
2:30pm	Review call with the project manager	Flagging a scope risk identified in the morning workshop that was not in the original brief
3:30pm	Draft a process map	Turning a verbal description of a current-state process into a swim lane diagram for validation
4:30pm	Prepare questions for tomorrow	Identifying the three things that need to be resolved before the next workshop can proceed

That is a real project day. There is no single moment where you bridge anything. There are about forty small moments where you ask the right question, write down the right thing, or flag a problem before it becomes a crisis.

The Hardest Part of the Job That Nobody Warns You About

The hardest part of being a BA is not the writing or the analysis. It is managing the gap between what stakeholders think they have agreed and what is actually in the requirements document.

On a programme I worked on for a large health organisation, I ran a series of workshops over six weeks to elicit requirements for a new patient administration system. At the end of the process I circulated the requirements document for sign-off. Two senior clinicians came back with change requests that directly contradicted requirements they had explicitly agreed to in workshop three. When I showed them the workshop notes, one of them said she had not understood what she was agreeing to at the time.

That is not an unusual situation. People agree to things in workshops that they later reinterpret when they see them written down in formal language. The other clinician was more direct: he said the requirement was wrong and that I had written it up incorrectly. I had verbatim notes and a signed attendance register. The conversation that followed was uncomfortable, but it was necessary, and it had to be conducted without blaming either of them while also holding the requirements baseline firm. That is the work nobody teaches you. Facilitation skills matter enormously in those moments, far more than any technical knowledge.

A BA’s job is to minimise that gap by being relentlessly specific in documentation and checking understanding at every stage. It is also to manage the conversation when the gap appears anyway, which it will, without capitulating and without creating an adversarial dynamic. Done well, that conversation is the most valuable thing a BA does on a project.

What the Role Is Really Selecting For

After 25 years I have a clear view of what makes someone effective in this work. It is not technical knowledge, although that helps. It is not certification, although credentials have their place. Here is what actually matters:

Curiosity about how things work: You need to find it genuinely interesting when a process breaks down or a stakeholder says something that does not quite add up, because that friction is where the real analysis begins.
Precision in writing: The quality of your documentation directly determines the quality of the decisions made from it. A BA who cannot write clearly will struggle regardless of how sharp their thinking is.
Tolerance for ambiguity: Requirements are rarely handed to you fully formed. The job involves working with incomplete information and producing structured output from it, often under time pressure.
Political awareness: Stakeholders have competing priorities and agendas. Navigating that without taking sides while still surfacing the truth is a skill that takes years to develop and cannot be learned from a textbook.
Consistency under pressure: When a senior stakeholder insists a requirement be changed because it is inconvenient, the BA is often the only person in the room protecting the integrity of what was agreed.

If you find yourself drawn to why processes break down, what people actually mean when they say they need something, and how to produce a document that a room full of stakeholders can genuinely agree on, this is the right career. If you are looking at building a BA career deliberately rather than drifting into it, understanding what the day-to-day work actually looks like is the most useful thing you can do before making that investment.

The role is messier, more political, and more intellectually demanding than most job descriptions suggest. It is also more satisfying, because when you get it right you can see exactly where your contribution made the difference between a project that delivered and one that did not. That visibility is rare in most professional roles, and it is one of the reasons I have stayed in this work for as long as I have.

Frequently asked questions

What does a business analyst do on a daily basis?

A BA spends most of a project day in stakeholder conversations, writing up outputs from those conversations, and maintaining requirements documents and process maps. The ratio of meetings to writing varies by project phase, but writing is always a significant part of the role. Flagging risks and gaps to the project manager is also a regular daily task.

Is business analysis a technical or business role?

It is both, which is what makes it distinctive. A BA needs enough technical understanding to have a credible conversation with developers and enough business understanding to represent stakeholder needs accurately. You do not need to be a developer, but you need to understand what developers need from you.

What is the hardest part of being a business analyst?

Managing the gap between what stakeholders think they agreed and what is actually documented is consistently the most difficult part of the role. Requirements sign-off is rarely as clean as the process suggests, and a significant part of the BA role is navigating those conversations diplomatically while maintaining the integrity of the requirements baseline.

Do business analysts write a lot?

Yes. Requirements documents, process maps, gap analyses, meeting summaries, stakeholder registers, and business cases are all standard BA outputs. The quality of that writing directly affects the quality of the project. A BA who cannot write clearly will struggle regardless of how good their analysis is.

What qualifications do I need to become a business analyst?

No specific qualification is required to enter the field. A background in business, IT, or a related discipline is helpful but not essential. Hiring managers care more about demonstrated analytical thinking, clear communication, and practical experience than about specific degrees or certifications.

Try Ash, Your Virtual BA

If reading this has you thinking about what it actually looks like to produce the outputs a BA is responsible for, Ash is built for exactly that moment. Ash asks you the same questions a senior BA would ask in a discovery session, guides you through 15 categories of requirements, and produces a structured Business Requirements Document you can download and use on your current project. The analytical framework is already built in, so you can focus on the substance rather than the structure. Try Ash Virtual BA.