Data Analyst vs Business Analyst vs BI Developer: roles in a project

Data Analyst, Business Analyst, BI Developer. You open three job descriptions and find SQL, business communication and reporting in all of them. Then a fourth describes a Business Analyst who barely touches datasets and spends most of the time examining processes and system requirements. I would use the title as a starting point for questions, rather than a complete description of your future working week.

I started as a Business Analyst and did substantial work in SQL and Excel. A more experienced colleague handled some of the more business-focused responsibilities. That experience shows how one team divided its work. It does not establish that every Business Analyst should have the same duties or that these three roles are interchangeable everywhere.

To make the differences concrete, I will use a fictional project: a shop wants to manage orders waiting too long for dispatch. We will follow the request through requirements, analysis, reporting and maintenance. The organisational examples and numbers are synthetic. My goal is to help you assess responsibility, without creating another rigid hierarchy of job titles.

Start with the result someone is responsible for

The distinction I find most useful is this: a Business Analyst helps define a need and the conditions for a change, a Data Analyst investigates a problem using data, and a BI Developer builds a reporting solution that people can use repeatedly. In a real team, one person may perform parts of all three jobs. It still helps to recognise when the type of responsibility changes.

The UK government’s Business Analyst framework covers business problems, user needs, processes and the effects of change. Its Data Analyst framework includes preparing, analysing and communicating data. These descriptions provide one useful comparison. They do not impose definitions on every employer or determine the scope of a particular vacancy.

For any offer, I would record three things: what I must deliver, who will use it and how we will know it works. A list of applications cannot answer those questions on its own. Two people using SQL every day may produce very different results. One investigates a hypothesis, another maintains a shared reporting model, and a third checks whether a system requirement is feasible.

One request can hide two different needs

Our operations manager says, “I need a dashboard of delayed orders.” It is tempting to open Power BI immediately. I would first ask what she will do after reading it. Will she move people between tasks, contact the warehouse, or inform customers? Without a decision to support, we could build an attractive screen that simply confirms an unpleasant situation.

In this example, the manager wants to identify orders requiring intervention each day. That needs a current queue, a responsible team and a prioritisation rule. She also wants to know whether the process improved over the previous month. That requires historical data and comparable measures. One view may not serve both purposes well, although both requests mention delays.

An order may contain several items, travel in multiple parcels and receive payment after it was placed. Subtracting two dates does not resolve these distinctions. We need a unit of observation and agreed start and end events. Each role will use these decisions for a different purpose, but everyone needs the same understanding of what the numbers describe.

The Business Analyst clarifies the intended change

A Business Analyst might begin by mapping the process. Who receives the order? What prevents it from reaching the warehouse? Who authorises partial dispatch? What happens when an item is unavailable? Conversations should create shared understanding of the problem and possible actions. Recording a request for a “fast, intuitive report” leaves the delivery team with considerable interpretation to do.

A useful output here is a short description of two needs: a daily intervention list and a monthly process review. For each, identify the user, frequency, required information and acceptance criteria. The operational list needs an order identifier, a reason for waiting and an owner. The monthly review needs a population definition and a consistent basis for comparison.

This role can also help resolve disagreement. The warehouse may want to measure time from receiving an instruction, while customer service wants time from payment confirmation. Both measures can be useful because they describe different sections of the process. Showing them separately may be appropriate. Forcing one ambiguous measure usually moves the disagreement into a meeting about the finished report.

The work may involve SQL and direct data investigation. It may also concern a system implementation, functional requirements or process changes with little reporting involved. I would not assume Business Analyst means an easier, nontechnical version of Data Analyst. Ask which kind of analysis matters in that team and which documents, decisions or tested changes the role actually produces.

The Data Analyst investigates the evidence

The Data Analyst can now examine the scale of the waiting problem. First, distinguish orders from items and events. Check missing dates, repeated records and orders still open. Then calculate measures and compare groups. Writing the query is necessary, but a query that runs successfully is not enough to justify the interpretation attached to its result.

Suppose 20 of 100 completed orders exceeded the agreed handling time. That is 20%. Another 15 orders remain open. I would not silently add those to completed orders or classify them as on time because a dispatch date is missing. They matter to the operational queue, while the historical performance comparison needs a separate rule for handling incomplete cases.

A useful analysis also explains what remains uncertain. Longer waiting times may coincide with an increase in products requiring more assembly work. That does not demonstrate that employees have become slower. The analyst compares appropriate groups, checks data quality and identifies the next question. Establishing a cause may require additional investigation or a different way of collecting information.

The output could be a brief note with a table, a recommended follow-up and code that reproduces the numbers. Every project does not need a dashboard. A one-off decision may be best served by a documented analysis. My guide to building an analyst’s dashboard discusses how to connect the presentation to the decision it supports.

The BI Developer builds something that works tomorrow

When the need returns each day, a reusable reporting solution becomes valuable. The BI Developer designs the model, measures, interactions and refresh process. Different report pages should use consistent definitions. The recipient should also be able to distinguish missing information from a genuine zero. Choosing chart colours is only one part of that responsibility.

Here, the model must connect orders, items and dispatch events. Repeating an order amount on every event can inflate a total without any additional sales. Microsoft’s guidance on star schemas in Power BI explains fact tables, dimensions and granularity. It offers a modelling foundation, rather than a ready-made design for every dataset or organisational need.

The solution also needs a clear indication of freshness. If the last refresh succeeded yesterday, a list labelled as today’s interventions may be misleading. Who notices a failure? Who investigates a source change? How does the user know the data is old? Ask those questions before delivery. A report without an owner can continue rendering while becoming less useful.

A BI Developer still needs to communicate with people. Someone must explain filter behaviour, demonstrate what a measure means and agree on a compromise between detail and readability. Understanding how the report is used helps prevent a technically correct result from being misinterpreted. Building the interface and understanding the business decision are closely connected pieces of work.

Handover depends on shared definitions

Problems often appear between stages. The Business Analyst agrees on “orders ready for processing”, the Data Analyst uses payment dates, and the BI Developer labels the result “delivery time”. Each person may do locally reasonable work while the combined result answers a different question. Shared vocabulary reduces this drift, especially when several teams contribute to the same solution.

At handover, I would record the measure definition, unit of observation, source, exception rules and several checkable cases. Include an order with two parcels, a cancellation after payment and a missing final event. The description should let someone verify the interpretation without depending on the colleague who remembers every meeting. A few specific cases are often more useful than pages of general statements.

In a small team, you may perform all these activities yourself. Separating them still helps. Record when an assumption changes and trace its effect through the analysis, model and report description. Otherwise, you may correct a formula while leaving an outdated label on the dashboard and older acceptance criteria in the project note. The inconsistency survives even without a formal handover.

Read job descriptions through their verbs

Highlight verbs in the responsibilities: clarify requirements, investigate causes, build models, maintain reports, lead acceptance testing. They suggest different kinds of work. Write an expected output beside each. If an advert combines everything, ask which activities take the most time and what a new employee would do during the first few weeks.

Request an example of a recent team project. Who framed the problem? Who accessed the data? Who checked the results? Who owns the solution after delivery? Those answers reveal the division of work better than a single claimed percentage of meetings or coding. The balance can change significantly between discovery, implementation and ongoing support.

Ask about boundaries too. Will you receive a prepared data source or build the entire flow? Is there someone to review your work? Who decides priorities when requests conflict? A broad role can offer useful learning, provided there is time and support. Combining three professions in one advertisement does not create three extra days in the working week.

You should also distinguish skills required immediately from skills you can develop. A team may need strong SQL on arrival but offer support with its reporting platform. Another may expect independent model design from the start. Ask for a concrete example of the expected standard. “Good technical skills” is much harder to assess than a sample task and its review process.

Try three small tasks on the same problem

I would also ask how the team decides that work is finished. Business analysis might be evaluated through agreed needs and acceptance criteria; data analysis through a reliable answer with stated limitations; BI work through a solution that continues functioning when data changes. If the advertised responsibilities and performance measures point in different directions, investigate that before accepting the role.

A vacancy may promise customer research while measuring success entirely through the number of reporting requests completed. That can be useful work, but its rhythm differs from a project allowing several weeks of focused hypothesis testing. Ask how users provide feedback and whether you can observe the report being used. Without that connection, a long technology list may still mean following instructions without learning whether the result helped anyone.

If you are choosing a direction, produce three small outputs for the order scenario. First, describe the manager’s need, current process and acceptance criteria. Avoid designing five report pages immediately. Establish which decision should become easier and which exception might change the user’s action. This gives you a practical taste of working with requirements.

Next, create a synthetic orders table and investigate waiting time. Show the denominator, distinguish open from completed cases and document limitations. A small dataset is enough if it contains meaningful exceptions. Make the calculation reproducible. You can then observe whether you enjoy investigating discrepancies and checking that a conclusion follows from the available evidence.

Finally, build a simple report that still answers the same type of question when the input data changes. Include freshness information and test an empty group and a missing date. Ask another person to find orders needing attention without your guidance. This checks both functionality and comprehension. The three outputs can become parts of one coherent portfolio project.

Choose the next skill from the work you want to do

I would start with shared foundations: understanding tables, basic SQL, data quality, measure definitions and clear explanations. They help you collaborate with people doing adjacent tasks. Then choose deeper practice based on the result you want to produce. Requirements analysis needs different exercises from reporting-model optimisation, even though both benefit from understanding the business process.

Changing between these roles is not automatically a promotion. Each has its own progression in experience and responsibility. A new title may signal a different specialism rather than greater seniority. Compare independence, problem complexity and the consequences of decisions. A label on a professional profile cannot tell you enough to judge development on its own.

After the three exercises, note which part you most wanted to improve. Did you return to the process discussion, the explanation of a discrepancy, or the model and report behaviour? Use that as a clue for the next project. A career choice becomes easier when it rests on completed work and feedback. You do not need to select an identity for the rest of your life.

Explain your project with clear boundaries

When presenting the project, separate your contribution from the wider process. You can say that you defined a measure, analysed exceptions and built a report with a freshness indicator using synthetic data. Show one point where you changed an initial assumption. That gives the interviewer a way to explore your reasoning. A dashboard screenshot reveals appearance but little about the decisions behind it.

If you did not implement a real scheduled refresh, describe that element as a plan. If one friend tested the report, say exactly that. Honest boundaries make it possible to discuss development without pretending you delivered a large corporate system. A small demonstration can be convincing when you understand its behaviour and can explain what real-world use would require.

I would choose an opportunity where the tasks, support and direction fit my current stage. The title helps locate a vacancy. A conversation about outputs helps evaluate the actual work. Across all three roles, connecting an audience’s need to evidence and a checked solution remains useful. Knowing which part you own makes that contribution easier to explain and improve.