Prachit Parikh: what a business analyst actually does all day

People ask me what a business analyst actually does, and the honest answer is that I translate. Someone in finance, operations or customer service has a problem. A development team has the skills to fix it. Between those two groups sits a lot of room for misunderstanding, and that gap is where a business analyst works.

I'm Prachit Parikh, and I've worked as a business analyst on banking and business systems projects. This post walks through what the job looks like week to week, the tools involved, and what separates a useful BA from someone who just takes notes in meetings.

The short definition

A business analyst makes sure the thing a team builds is the thing the business needed. That breaks down into four jobs: understanding the problem, writing requirements a team can build and test, checking the data those requirements depend on, and making sure the finished change is tested properly before it goes live.

A typical week as a business analyst

Discovery: finding the real problem

Stakeholders usually arrive with a solution in mind. "We need a new report." My first job is to ask why. What decision will the report support? What do they do today without it? Often the real requirement is different, and smaller, than the first request. I spend a good part of each week in short conversations and process walkthroughs, watching how the work actually gets done, workarounds included.

Requirements and user stories

Once the problem is clear, I write it down in a form the team can use. That means user stories with acceptance criteria, for example: "As an approver, I can see all invoices waiting for me on one screen, sorted by due date, so that nothing goes past its payment term." Every story gets criteria someone could test. If nobody can test it, it isn't finished. I go deeper on this in my Substack.

Data validation with SQL

Before anyone builds a report or a process on top of data, I check that data. I run SQL against the source system to confirm row counts, totals and the edge cases that tend to break things: duplicates, missing reference data, records with unexpected dates. A lot of project problems turn out to be data problems that nobody looked at early enough. My Power BI dashboard checklist covers the reporting side of this.

Traceability

I keep a simple trace from each requirement to the tests that prove it. When a stakeholder changes their mind halfway through, and they will, that trace shows exactly what else has to change. I wrote about the lightweight version I use in a traceability matrix people will actually use.

UAT planning and support

User acceptance testing is where the business confirms the change works for them. I plan it: which scenarios get tested, which data is needed, who is testing and when, and what counts as a pass. Then I support testers through it and triage the defects. Here's my full breakdown of what a good UAT plan actually looks like.

Tools a business analyst uses

• SQL for checking data at the source
• Excel for quick analysis and reconciliation
• Power BI for reporting and dashboards
• Jira or a similar tool for user stories, defects and tracking
• Diagrams for process flows, because a picture of the current process settles arguments fast

Some examples of my work, including a requirements workflow built with Python, SQLite, Streamlit and Power BI, are on my GitHub.

What makes a business analyst useful

The best BAs I've worked with share a few habits. They ask "why" before "what." They write things down clearly enough that someone who missed the meeting can act on it. They check the data instead of trusting it. And they stay with a change through testing instead of handing over a document and disappearing.

Frequently asked questions

Is a business analyst technical? Somewhat. You don't need to write production code, but knowing SQL and understanding how systems store data makes you far more effective.

What's the difference between a business analyst and a project manager? A project manager owns the plan, budget and timeline. A business analyst owns what's being built and whether it meets the need.

How do you become a business analyst? Many people move into it from operations, customer service or testing roles, because they already understand the business side. Learning to write good requirements and basic SQL closes most of the gap.

About the author

I'm Prachit Parikh, a business analyst working on requirements, SQL data validation, Power BI reporting and UAT. I've worked as a business analyst at Banking Circle and on business systems projects at Saklax Manufacturing. I keep free templates and SQL checks in my BA Toolkit on GitHub, and I make short animated explainers on YouTube. Besides this blog, I write on Substack, Medium, Hashnode, Dev.to and WordPress, and I answer questions on Quora. You can also find me on LinkedIn, Bluesky, Kaggle, Credly, Crunchbase and Gravatar. Everything is collected on my website and my profile hub.

If you work with business analysts, or you are one, what part of the job do people misunderstand most? Tell me in the comments.