Business Analyst

A business analyst works out what an organisation actually needs before anyone spends money building it. They sit between the people with a problem and the people who will solve it, and their job is to make sure the solution fixes the real problem, not just the one someone described in a meeting.

What a business analyst does

Business analysis is the practice of helping an organisation change well: understanding how it works today, where it wants to be, and what has to change to get there. A business analyst (BA) does that by asking questions, watching how work really gets done, and writing down what they find in a form other people can act on.

A BA is usually not the manager who sets the priorities, and not the developer who writes the code. They are the one who makes sure those two people are talking about the same thing. In a typical week that means:

• interviewing the people who do the work and the people who pay for it;
• mapping processes, step by step, as they happen today;
• spotting where work gets stuck, duplicated or lost;
• turning what they learn into requirements a team can build and test;
• checking afterwards that what was built solved the problem.

In smaller companies a developer or product manager often does this work without the title.

Why the role exists

Plenty of projects go wrong without a single bug. The code works; it just does the wrong thing, or the right thing for the wrong reason. The gap usually opens in one of three places.

• Wants versus needs. A manager asks for 'a dashboard'. What they need is to stop hearing about late orders a week after the customer does. A dashboard might be the answer, or an alert might, or a change to who owns each order.
• The business versus its users. The business wants fewer support calls. Users want to finish a task without phoning anyone. The two are related, but they lead to different designs.
• What people say versus what they do. Ask someone how a process works and you get the official version. Watch them do it and you find the workaround, the extra spreadsheet and the sticky note.

A good BA closes these gaps before development starts, when changing direction costs a conversation rather than a rewrite. Without that work, a team can build exactly what was asked for and still miss what was needed.

How the work goes

Every organisation runs this differently, but the shape is much the same.

Understand the problem

Start with the outcome, not the solution. Useful early questions:

• What is going wrong, and how do you know?
• Who is affected, and how often?
• What would 'fixed' look like, in something you could measure?
• What has already been tried?

These questions often show that the problem is different from the one on the ticket.

Map the current process

Next, the BA maps how the work happens today, often called the 'as-is' process. That can be a whiteboard sketch, a swimlane diagram showing which team does each step, or a formal notation such as BPMN (Business Process Model and Notation). The notation matters less than the honesty: the map should show what people really do, workarounds included, not what the procedure manual says.

Find the bottlenecks

With the process written down, the problems tend to stand out: a step that waits on one person, data typed in twice, a hand-off where information gets lost, a manual check that exists because nobody trusts a system. Each is a candidate for change, and each has a cost the BA can estimate, usually in hours a week or errors a month.

Define the change

Finally, the BA describes the 'to-be' process and the requirements that get the organisation there. This is where the documents come in.

The documents, and what each is for

Documents are not the goal; shared understanding is. Writing things down forces precision, and settles arguments when memories differ.

Requirements

Requirements say what a solution must do and how well it must do it. They usually come in two kinds:

• Functional requirements describe behaviour: 'The system sends a reminder email when an invoice is 7 days overdue.'
• Non-functional requirements describe qualities: 'The report loads in under 3 seconds', or 'Only finance staff can see salary data.'

A good requirement is specific and testable. 'The system should be fast' is a wish. 'Search results appear within 2 seconds' is a requirement someone can check.

User stories

Agile teams often write requirements as user stories: one sentence from the point of view of the person who benefits.

As a warehouse manager, I want to see today's late orders in one list, so that I can chase them before customers call.

A story names who, what and why. The 'why' matters most, because it lets the team suggest a better 'what'. Each story also needs acceptance criteria, the conditions that must hold before it counts as done:

Given an order is past its promised date
When the manager opens the late orders list
Then the order appears with its customer and delay

Workflows and diagrams

A workflow diagram shows the steps, decisions and hand-offs in a process. It is often the quickest way to get a room to agree on how something works, or to discover that they don't. Expect plenty of arrows: each one is a hand-off, and hand-offs are where problems live.

A worked example: the morning spreadsheet

A small online shop has a routine nobody questions. Every morning, five people in customer service export yesterday's orders from the shop platform, paste them into a shared spreadsheet, check each one against the courier's tracking export, and colour the late ones red. It has been done this way for years. The manager asks for 'a button that does the spreadsheet automatically'.

A BA would not start by building the button. They would:

1. Watch and time the work. Sit with the team for a morning. If each person spends 40 minutes on it, that is over three hours of staff time every day.
2. Ask what the output is for. It turns out the only thing that matters is the list of late orders, which a supervisor reads mid-morning and emails to the courier.
3. Map the process. Both sources, the orders and the tracking data, can already be exported automatically. The copying and pasting adds nothing.
4. Agree what 'fixed' means. Late orders chased before 10am, and nobody copying data by hand.

The requirements that come out are not 'automate the spreadsheet'. They are closer to:

• By 8am each day, produce a list of orders past their promised date, with their tracking status.
• Send the list to the supervisor, and flag orders more than 3 days late.
• No manual data entry, and the list must match the shop platform's order records.

The developers now know what to build, and it may not involve a spreadsheet at all. The manager knows why it matters: hours of staff time back every day, and faster answers for customers.

The 'small change' problem

Stakeholders, meaning anyone with an interest in the outcome, often ask for a change that sounds tiny: 'just add a field', 'just let customers pick a delivery date'. Part of a BA's job is impact analysis, tracing everything a change touches before anyone agrees to it.

Letting customers pick a delivery date touches the checkout form, the stock system (will the item be available by then?), the courier booking, the confirmation email, the refund rules when a date is missed, and the reports finance runs. None of that makes it a bad idea. It makes it a project with a real cost, and the stakeholder deserves to know that before it is promised.

When a project keeps absorbing requests like this without weighing them, that is scope creep. A clear, agreed set of requirements is the main defence.

How a BA differs from neighbouring roles

These roles overlap, and in a small team one person may do several. The difference is the question each one answers.

Common mistakes

• Writing the solution into the requirement. 'Add a dropdown' is a design decision. 'Let the customer choose one of five delivery slots' leaves the team room to find the best design.
• Only talking to the person who asked. The requester is one stakeholder. The people doing the work, and the people downstream of it, often understand the problem better.
• Documenting for its own sake. A long specification nobody reads helps nobody. Match the detail to the risk: more for payments or regulation, less for a small internal tool.
• Treating requirements as fixed. Needs change once people see working software. Revisit the requirements, and record why they changed.
• Dropping the 'why'. Without it, developers can't make sensible trade-offs, and nobody can tell later whether the change worked.

Key takeaways

• A business analyst works out what an organisation needs, as opposed to what it asked for, before money is spent building it.
• The core loop is: understand the problem, map how work really happens, find the bottlenecks, then define the change.
• Requirements, user stories, workflows and diagrams exist to create shared understanding between the business, its users and developers.
• Impact analysis turns a 'small change' into an honest estimate before anyone commits to it.
• The payoff is fewer wasted builds: the team delivers what was needed, not just what was requested.