The role of the business analyst in IT projects: bridging the gap between needs and technology

The operations director of a Laval-based distributor arrived at the first meeting with the solution already chosen: "We need a warehouse management module, just like our competitor." No one had even described the problem yet. Three months later, it was discovered that the stock shortages were caused by sales forecasts, not the warehouse.

It is precisely to avoid this scenario that the role of the business analyst exists in IT projects.

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

According to the PMI Pulse of the Profession study on requirements management, nearly half (47%) of failed projects miss their objectives due to inaccurate requirements management.

What is the role of the business analyst in an IT project?

The role of the business analyst in an IT project is to understand the business problem, formulate the needs and requirements, and then guide the client and the technical team toward a solution that addresses the root cause rather than just a symptom. They sit between two worlds—business and IT—and their tasks constantly navigate between the two.

In practical terms, they ask the right questions. They document assumptions, constraints, essential business needs, functional and non-functional requirements, and identify the client's objectives. The IIBA defines business analysis as the practice of enabling change by defining needs and recommending solutions that deliver value to stakeholders.

This role is part of a team. It complements the roles of the project manager, the architect, and the functional experts described in our article on key roles in a project team.

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

The business analyst evaluates the problem before any solution because a client in a hurry almost always favours the solution they are already familiar with, and a solution applied to the wrong problem produces a predictable backlash in the medium term. They are, first and foremost, a specialist, and their mandate holds firm despite the client's urgency.

Through their expertise, they are an ally to the users. They precisely define the business domain in which they operate and then put their know-how to work for them. They also foster a collaborative climate within their team. As a well-equipped generalist, they have what it takes to carry out their mission.

The numbers justify this insistence. Gartner reports that 75% of ERP strategies are not strongly aligned with corporate strategy, leading to confusion and disappointing results. Without someone whose job it is to link business needs to the solution, this alignment does not happen on its own.

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 essentially produce the same deliverables, but through different paths. The content remains largely the same; the way of reaching the goal changes.

When developing an IT system, the analyst relies primarily on the study of functions and data—that is, what the user actually does in the system. Their tools are used to identify the rules, constraints, and expectations for the system. Three methods are common in their practice.

The iterative approach. Parts of a system are delivered at regular intervals. Each iteration involves requirements analysis and activities leading to approximate solutions, which gradually build the final product.

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

The waterfall approach. A succession of steps where each phase must be validated before moving on to the next. Less trendy than agile, it remains well-suited for large-scale projects and offers a precise view of delivery timelines.

A few key figures to put the issue into perspective:

• 47% of failed projects miss their objectives due to inaccurate requirements management (PMI, Pulse of the Profession, 2014).
• 75% of ERP strategies are not strongly aligned with corporate strategy (Gartner, 2026).
• 45% average budget overrun for large IT projects, primarily caused by strategy and stakeholder management (McKinsey and University of Oxford, 2012).
• Up to 100% improvement in project performance thanks to the right experts, capable of interpreting data and exercising 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 implementation, according to PlanAxion’s observations.

Why must we understand the present before designing the future?

You must understand the current business situation before thinking about solutions, because every client and user has unique characteristics that the analyst must decipher to adapt the tool and get the most out of it. Envisioning the future without having examined the current business process is ill-advised, 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 true expectations. The analyst investigates, develops scenarios, and measures their effects. They also dig into existing systems to find exceptions and limitations—the ones no one mentions in workshops because they have become invisible.

This approach has a method. We described it in our guide on assessing business needs based on industry best practices. McKinsey notes that integrated business and IT teams, present from requirements definition through to testing, avoid misunderstandings during phase transitions.

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

What is a good business analyst?

A great business analyst is a specialist who enjoys breaking down problems to find solutions, possesses expertise in both business and information technology, and knows how to explain technical concepts to a non-technical audience. They know how to engage stakeholders by acting as the bridge between the client and the IT team.

They speak the language of both camps, interpret what each side says, and understand the system’s limits and constraints. They work closely with the architect, whose role as a solutions architect in 2026 we have described: one formulates the need, the other designs the technical response.

Their ultimate challenge: getting the client to consider the right solution without losing sight of the source of the problem. This avoids the classic scenario where you deliver exactly what was requested, yet the problem remains.

Do you need a business analyst for every IT project?

Yes, as soon as the project touches a business process, because requirements management is a factor in nearly half of all failures according to PMI, and no one else on the team has this mandate full-time. A project manager manages the schedule; an architect designs the solution. Translating needs is a profession in its own right.

Frequently asked questions

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

The project manager is responsible for the schedule, budget, resources, and risks. The business analyst is responsible for the content: understanding the problem, formulating needs and requirements, and ensuring the solution meets them. Both collaborate constantly, but assigning both roles to the same person generally weakens the latter.

What skills should a business analyst have for an IT project?

A dual skillset in business and information technology, the ability to explain technical concepts to a non-technical audience, and the capacity to engage stakeholders while acting as the bridge between the client and the IT team. The IIBA structures these competencies in the BABOK Guide, the global standard for the practice, across six knowledge areas.

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

No. They choose the method based on the client’s context, the stability of the requirements, and the scale of the project. Iterative, agile, and waterfall essentially produce the same deliverables—describing what the user does in the system—but through different paths. A good analyst masters all three and can explain why they are recommending a specific one.

Why do projects fail because of requirements?

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