Most people outside technology aren't quite sure what a Business Analyst does. It's not a project manager (though there's overlap). It's not a developer (though a good BA understands what developers need). The role exists in the space between operational reality and technical delivery — which happens to be where most software projects succeed or fail.
The statistics on project failure are grim and consistent. The most common cause isn't bad developers, unrealistic timelines or budget overruns. It's that the wrong thing was built. Requirements were wrong, incomplete, misunderstood, or changed without a process for managing the change. A project can be delivered on time and on budget and still be a failure — because it delivered the wrong thing.
A failure I've seen more than once
A growing business commissions a system. The developer is competent. Everyone is helpful. But nobody ever wrote down what happens when a renewal is disputed, or how the part-time admin's Tuesday-only workflow differs from everyone else's, or that 'client' means three different things to three different departments. The system gets built to a plausible guess, launches to polite silence, and six months later the team is back on spreadsheets — with the expensive system running alongside, maintained out of obligation.
Nothing in that story required bad technology. It failed in the gap between what people said they wanted and what the business actually needed. Closing that gap is the job.
What a Business Analyst actually does
Requirements elicitation — which is not asking people what they want. What people say they want and what would solve their problem are frequently different things. A user asks for a new report because the existing one doesn't show what they need; what they actually need is a dashboard, or an alert, or a process that makes the report unnecessary. Elicitation means watching the work, mapping the process, and digging past the request to the need underneath it.
Stakeholder management. Most projects involve people with different priorities, different vocabularies and different levels of technical understanding. The director wants visibility, the admin team wants fewer clicks, finance wants an audit trail. Someone has to surface those conflicts early — in a workshop, not in a UAT session three weeks before launch.
Documentation that earns its keep. Not documentation for its own sake — the right artefacts at the right level of detail: process maps, user journeys, acceptance criteria. 'When a renewal lapses, the account owner gets notified within one working day' is a requirement a developer can build and a tester can check. 'The system should handle renewals well' is not.
Translation in both directions. Developers don't always understand business processes; business users don't always understand technical constraints. Someone has to explain to the business why the feature they asked for is expensive, and explain to the developer what outcome the business actually needs. Done well, this is where the expensive misunderstandings die.
When you might not need one
Honesty matters here: for a small, well-defined project — a marketing site, a simple integration — dedicated analysis may be overkill. The case for it grows with the number of users, the number of processes affected, and the cost of getting it wrong. If a wrong assumption would be embarrassing, skip it. If a wrong assumption would be expensive, don't.
Why the maths favours it
The cost of a requirement error compounds with distance. Found in analysis, it costs a conversation. Found in development, it costs a week. Found after launch, it can cost the project — or the system's credibility with the people who were supposed to use it, which is harder to get back.
Analysis is the most commonly cut line item when budgets tighten — usually justified as 'we'll work it out as we go'. The projects that go wrong are very often the ones that made that call. Working it out first is almost always the cheaper plan.