The Business Analyst Role in IT Projects: Bridging Business Needs and Technology

The operations director of a Laval distributor arrives at the first meeting with the solution already chosen: "We need a warehouse management module, like our competitor has." Nobody has described the problem yet. Three months later, it turns out the stockouts came from sales forecasting, not the warehouse.

That scenario is exactly what the business analyst role in IT projects exists to prevent.

Statistics cited come from public reports by PMI, IIBA, Gartner and McKinsey; effort benchmarks are PlanAxion observations.

According to PMI's Pulse of the Profession study on requirements management, nearly half (47%) of unsuccessful projects fail to meet their goals due to inaccurate requirements management.

What is the business analyst role in IT projects?

The business analyst role in IT projects is to understand the business problem, articulate its needs and requirements, then guide the client and the technical team toward a solution that fixes the problem rather than a symptom. The analyst stands between two worlds, business and IT, and the work moves constantly between them.

In practice, the analyst asks the right questions. They document assumptions, constraints, the core business needs, functional and non-functional requirements, and they pin down the client's objectives. IIBA defines business analysis as the practice of enabling change by defining needs and recommending solutions that deliver value to stakeholders.

The role sits inside a team. It complements the project manager, the architect and the functional experts described in our article on the key roles in a project team.

Why does the business analyst start with the problem rather than the solution?

The business analyst assesses the problem before any solution because a hurried client almost always favours the solution they already know, and a solution applied to the wrong problem produces a predictable backlash in the medium term. The analyst is first and foremost a specialist, and that mandate holds no matter how impatient the client is.

Through their expertise, the analyst is the users' ally. They define precisely the business domain the users operate in, then put their know-how at the users' service. They also foster collaboration within the team. A well-equipped generalist, they have what it takes to carry the mission.

The numbers justify the insistence. Gartner reports that 75% of ERP strategies are not strongly aligned with overall business strategy, leading to confusion and lacklustre results. Without someone whose job is to connect the business need to the solution, that alignment does not happen by itself.

How does the business analyst choose the working method: iterative, agile or waterfall?

The business analyst chooses the method based on their understanding of the business domain and the client's requirements, because iterative, agile and waterfall produce essentially the same deliverables by different paths. The content stays roughly the same; the way to reach the goal changes.

When building an IT system, the analyst relies above all on the study of functions and data, meaning what the user actually does in the system. Their tools serve to surface the rules, constraints and expectations placed on the system. Three methods recur in practice.

The iterative mode. Parts of the system are delivered at regular intervals. Each iteration chains needs analysis with activities leading to approximate solutions, which gradually build the final product.

The agile mode. Built on an iterative cycle, it reuses several artifacts of the previous mode and emphasizes the ability to adapt to shifting requirements. The names change, but it is still about describing what the user accomplishes with the system.

The waterfall mode. A sequence of stages where each phase must be validated before moving to the next. Less fashionable than agile, it remains suited to large projects and offers a precise view of delivery timelines.

A few benchmarks to frame the stakes:

• 47% of unsuccessful projects fail to meet their goals due to inaccurate requirements management (PMI, Pulse of the Profession, 2014).
• 75% of ERP strategies are not strongly aligned with overall business strategy (Gartner, 2026).
• 45% average budget overrun on large IT projects, with strategy and stakeholder management as the leading cause (McKinsey and University of Oxford, 2012).
• Up to 100% performance improvement from having the right experts, able to interpret data patterns and exercise judgment (McKinsey and University of Oxford, 2012).
• Six knowledge areas structure the BABOK Guide, the global standard for business analysis (IIBA).
• 1 business analyst for every 2 to 3 major processes in a mid-sized software package implementation, based on PlanAxion observations.

Why must you understand the present before designing the future?

You must understand the current business situation before thinking about solutions, because every client and every user has particularities the analyst must decode to adapt the tool and get the most out of it. Imagining the future without examining the current business process is ill-advised, and yet it is the temptation of every rushed project.

The key is to involve the client and listen to their needs until they share their real expectations. The analyst investigates, builds scenarios and measures their effects. They also dig into existing systems to find the exceptions and limits, the ones nobody mentions in workshops because they have become invisible.

There is a method to this. We described it in our guide on assessing business needs using industry best practices. McKinsey also notes that integrated business and IT teams, present from requirements definition through testing, avoid misunderstandings at phase transitions.

A client almost always knows which solution they want; the business analyst's job is to discover which problem they have.

What makes a good business analyst?

A good business analyst is a specialist who enjoys dissecting problems to find solutions, who commands both business and information technology, and who can explain technical concepts to a non-technical audience. They show leadership by holding their ground between the client and the IT team.

They speak both camps' language, interpret what each one says, and understand the system's limits and constraints. They work closely with the architect, whose solutions architect role in 2026 we have described: one articulates the need, the other designs the technical answer.

Their ultimate challenge: lead the client to the right solution without losing sight of the source of the problem. That is what avoids the classic case where you deliver exactly what was asked for, and the problem is still there.

Does every IT project need a business analyst?

Yes, as soon as the project touches a business process, because requirements management is involved in nearly half of failures according to PMI, and nobody else on the team holds that mandate full time. A project manager runs the schedule; an architect designs the solution. Translating the need is a discipline of its own.

Frequently asked questions

What is the difference between a business analyst and a project manager?

The project manager is accountable for schedule, budget, resources and risks. The business analyst is accountable for content: understanding the problem, articulating needs and requirements, and making sure the solution answers them. The two collaborate constantly, but assigning both roles to the same person usually weakens the second one.

What skills does a business analyst need on an IT project?

Dual competence in business and information technology, the ability to explain technical concepts to a non-technical audience, and enough leadership to hold a position between the client and the IT team. IIBA structures these skills in the BABOK Guide, the global standard for the practice, around six knowledge areas.

Does the business analyst have to choose between agile and waterfall?

No. They choose the method based on the client's context, the stability of requirements and the size of the project. Iterative, agile and waterfall produce essentially the same deliverables, describing what the user does in the system, by different paths. A good analyst masters all three and can explain why they recommend one.

Why do projects fail because of requirements?

According to PMI, 47% of unsuccessful projects fail to meet their goals due to inaccurate requirements management, a problem tied to scope creep, poor communication and insufficient stakeholder involvement. A dedicated business analyst reduces that risk by framing the problem before the solution and documenting the assumptions behind every requirement.