What a Business Analyst actually brings to a software project

Most people outside of 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). It exists in the space between operational reality and technical delivery — and it's where most software projects either succeed or fail.

The statistics on software project failure are grim and consistent. The most common reason isn't bad developers. It isn't unrealistic timelines or budget overruns (though both contribute). It's that the wrong thing was built. The requirements were wrong, incomplete, misunderstood or changed without a proper process for managing the change. A project can be delivered on time and on budget and still be a failure if it delivers the wrong thing.

What a Business Analyst actually does:

Requirements elicitation. This is not simply asking people what they want. What people say they want and what would actually solve their problem are frequently different things. Good requirements gathering involves understanding current processes, identifying pain points, mapping user journeys, and translating operational reality into a form that developers can work from.

Stakeholder management. Most software projects involve multiple people with different perspectives, different priorities and different levels of technical understanding. Someone needs to manage those perspectives, resolve conflicts in requirements, and ensure that the people who will use the system are represented in the design decisions. That's the BA.

Documentation. Not just writing things down, but creating the right artefacts at the right level of detail — user stories, process maps, functional specifications, acceptance criteria. These are the contracts that prevent misunderstandings between what was asked for and what was built.

Translation. This is perhaps the most undervalued contribution. Developers don't always understand business processes. Business users don't always understand technical constraints. Someone needs to translate in both directions — explaining to the business why something they've asked for is technically expensive, and explaining to developers what the business outcome actually needs to be.

Why it matters:

The cost of getting requirements wrong compounds. A missed requirement found in analysis costs an hour to fix. Found in development, it costs a day. Found in testing, it costs a week. Found after launch, it can cost the whole project.

Investing in proper requirements analysis before development starts is one of the highest-return activities in any software project. It's also the one most commonly cut when budgets are under pressure — which is usually why those projects then go wrong.