In IT projects—especially those delivered for the public sector—we increasingly see a situation where there’s a business analyst on both sides of the table. One represents the contractor (the vendor), the other a public institution (the client). And although, in theory, they speak the same professional language, they very often don’t understand each other. Why?

The analyst on the vendor side focuses on gathering requirements as precisely as possible, translating them into analysis documentation, and communicating with the development team (architects, developers, testers). Their goal is to deliver a solution within scope, budget, and schedule.

Meanwhile, the analyst on the client side—especially in a public institution—operates in a world shaped by legal constraints, stakeholder expectations, procedures, and audits. For them, a “requirement” is not just a system function, but also a legal justification, a societal need, alignment with state policy, and the ability to enforce it under scrutiny and control.

When the vendor’s analyst says, “we need a backlog with user stories,” the client’s analyst may hear, “you want a simplified description instead of a formal requirements document compliant with a regulation.” When the client asks for “stakeholder approval,” the vendor may not realize this means formal sign-off by the management of a state unit—not just an informational meeting.

The vendor thinks in terms of MVP and delivering value quickly. The public-sector client thinks in terms of completeness, compliance with tender documentation, and whether not a single point of the specification (SIWZ) has been missed. For one side, fast progress is success; for the other, the lack of a director’s signature can mean acceptance is put on hold.

Vendors work in an agile, iterative way, using collaboration tools. Public institutions often have limited access to such tools, and online meetings are formal and minuted. For one side, communication means a daily stand-up; for the other, it’s a written request and a project manager’s signature.

The key is empathy and awareness that the same role can look completely different depending on where it sits in the project structure. At the start of cooperation, it’s worth agreeing on definitions of key terms, expectations, and communication style. A good idea is also a workshop along the lines of “let’s understand each other’s constraints and goals,” with an outcome such as agreeing a DoR (Definition of Ready) and DoD (Definition of Done).

Understanding starts with a conversation. And a conversation starts with the assumption that the other side isn’t trying to make the project harder—they’re just looking at it through a different lens. And that’s exactly why one business analyst doesn’t always understand another.

#businessanalysis #publicsector #requirementsengineering #MVP #collaboration #governance #compliance #digitaltransformation