Software projects fail for many reasons. They go over budget, miss deadlines, and get shelved after launch. But the most expensive failure mode is quieter: the project ships, works technically, and still does not solve the problem it was built to solve. Teams built the wrong thing. This is the gap that a business analyst exists to close.
If you are planning a software project and unsure whether you need a business analyst, this guide explains the role clearly, how it differs from a project manager or product manager, what skills to look for when hiring, and when bringing one in actually changes outcomes. If you are ready to hire, see our business analyst and project manager hire pages.
What a business analyst does
A business analyst (BA) acts as the bridge between the people who have a business problem and the team that will build the solution. They work closely with project managers and feed requirements directly into custom software development teams. Their job is to understand the problem deeply, translate it into precise requirements, and ensure the development team builds the right thing rather than a technically correct version of the wrong thing.
In practice, this means a BA spends most of their time:
- Interviewing stakeholders to understand current processes, pain points, and goals
- Documenting requirements in formats developers can act on (user stories, use cases, process flows, data models)
- Identifying gaps and conflicts in requirements before they become expensive code changes
- Facilitating workshops between stakeholders who have different, sometimes competing, priorities
- Reviewing delivered features against original requirements to confirm they meet the intent, not just the specification
A good BA is the reason your development team does not spend three sprints building a feature that a two-hour stakeholder conversation would have revealed was the wrong solution.
Business analyst vs project manager: the key difference
These two roles are often confused, and sometimes combined in smaller organisations. The distinction matters.
A project manager is responsible for delivery: scope, timeline, budget, resources, risk, and communication. They ensure the project is delivered on time and within budget. They are primarily focused on how and when.
A business analyst is responsible for requirements: understanding what the system needs to do, why it needs to do it, and ensuring the delivered system does it correctly. They are primarily focused on what and why.
On a well-run project, both roles exist. The project manager keeps the machine running. The business analyst ensures the machine is pointed at the right problem.
In practice, many small and mid-sized software projects ask one person to do both. This works when the project is well-understood and stakeholders are aligned. It breaks down when requirements are complex, stakeholders have conflicting priorities, or the business domain is unfamiliar to the development team.
Business analyst vs product manager
The BA and product manager (PM) overlap significantly in product companies. Both define what gets built. The difference is scope and focus.
A product manager owns the product vision, roadmap, and market positioning. They decide which problems to solve at a strategic level and prioritise features against business goals and customer needs.
A business analyst operates at a more tactical level: once the PM has decided what feature area to build, the BA drills into the detailed requirements, edge cases, integration points, and acceptance criteria that make implementation possible.
In agencies and bespoke software companies, the business analyst role is common. In product companies, the same work is often absorbed into the product manager role. Clarity on which role you actually need depends on whether you are building a product or delivering a project.
What skills should a business analyst have?
Core skills
Requirements elicitation: The ability to ask the right questions in the right order, draw out unstated assumptions, and uncover requirements stakeholders did not know they had. This is partly technique and partly interpersonal skill.
Documentation: A BA produces documents that others act on. User stories, functional specifications, process flow diagrams, data dictionaries, and acceptance criteria need to be precise enough that a developer in a different time zone can implement them without a three-hour call.
Domain knowledge: A BA who understands your industry can spot requirements gaps that a generalist would miss. A BA working on a healthcare project who understands clinical workflows will ask different questions than one who is learning the domain from scratch.
Stakeholder management: Most software projects involve stakeholders with different, sometimes contradictory, priorities. A BA facilitates alignment without letting any single stakeholder derail the project.
Analytical thinking: Requirements analysis means spotting inconsistencies, edge cases, and unintended consequences before they become code. This requires systematic, precise thinking rather than creative problem-solving.
Tools and methods
A working BA should be proficient with:
- Process mapping tools: Lucidchart, Miro, draw.io, or Visio for workflow and system diagrams
- Requirements management: Confluence, Jira, or Azure DevOps for documenting and tracking requirements
- Collaboration: Workshops, structured interviews, and user journey mapping sessions
- Agile methodologies: User story writing, backlog refinement, sprint planning, and acceptance criteria in Scrum or Kanban environments
- Data analysis: SQL or Excel for validating data-related requirements and reviewing test data
Formal certifications such as CBAP (Certified Business Analysis Professional) or PMI-PBA signal serious investment in the discipline, though practical experience often matters more than credentials.
When do you actually need a business analyst?
A business analyst adds the most value in specific situations. Not every project needs one.
You need a BA when:
- The project involves multiple stakeholders with different priorities and no single decision-maker
- The business domain is complex and unfamiliar to the development team (healthcare, financial services, manufacturing, legal)
- Requirements are unclear, contested, or changing rapidly
- The system must integrate with multiple existing systems
- The project has a fixed budget and a failed first attempt is not recoverable
- You have experienced failed or over-budget projects in the past due to scope creep or misunderstood requirements
You probably do not need a dedicated BA when:
- The project is a straightforward extension of an existing system with clear, well-understood requirements
- The development team has deep domain expertise and direct access to stakeholders
- The project is a prototype or MVP designed to test assumptions quickly rather than deliver a production system
- The founding team can personally fulfil the requirements role with direct input to the development team
How to hire a business analyst
Offshore vs local
Business analysis is one of the roles that works extremely well offshore. The work is primarily asynchronous, documentation-driven, and communication-heavy in structured formats. Strong BAs in Pakistan, India, and Eastern Europe work across time zones routinely, particularly on projects with UK, US, and Australian clients.
An offshore BA costs $1,500 to $3,000 per month compared to $7,000 to $12,000 per month for a senior BA in London or Sydney. For many projects, the offshore option delivers equivalent quality at a fraction of the cost.
What to look for in an interview
Ask candidates to:
- Walk you through a requirements document they have produced for a previous project
- Describe a situation where stakeholder requirements conflicted and how they resolved it
- Explain a domain they had to learn quickly and how they approached it
- Write a user story with acceptance criteria for a simple feature you describe on the spot
Look for precision in their writing, structured thinking in their explanations, and evidence of successful delivery rather than just theoretical knowledge.
Watch for red flags
- A BA who cannot produce a clean requirements document under pressure
- Candidates who have only worked in environments with perfect, pre-defined requirements
- A tendency to document what stakeholders say rather than what they mean
- Resistance to challenging stakeholder assumptions
The cost of not having a business analyst
The most common objection to hiring a BA is cost. The counter-argument is straightforward: the cost of building the wrong thing is always higher than the cost of discovering what the right thing is before you build it.
Development time costs money. Rework costs more than initial build. A three-month project that ships the wrong feature and requires a two-month rework has cost the same as a five-month project, plus the opportunity cost of the delayed delivery, plus the stakeholder frustration that damages the relationship.
Studies of software project outcomes consistently find that unclear or misunderstood requirements are the primary cause of cost overruns, delays, and outright project failure. A BA who clarifies requirements before sprint one begins is not an overhead. They are risk management.
A business analyst is not a luxury for complex enterprise projects. They are a practical investment in any project where the cost of building the wrong thing exceeds the cost of the BA's time. For most custom software projects above $50,000, that calculation comes down clearly in favour of bringing one in from the start. Read our guide on how to write a software brief to understand the document a BA produces, and our staff augmentation vs outsourcing breakdown to decide how to engage one.