By definition, a Business Analyst is someone who analyzes the existing organization and design of systems (whether business processes or IT systems) and helps to define the improvements needed. In an IT project, the BA's role is to understand the high-level requirement statement(s) in the project charter, deep dive into the client's business processes and prepare the product scope and project scope. Generally this role is performed at the vendor's side, either by the Project Manager himself or by a specialist BA who has more likely than not worked his way up from a technical role
But sometimes, especially in international projects, one finds the Business Analyst role being played by someone at the client side. This may be an employee of the client organization, or a contractor appointed by the client management to speak to their employees and note down their detailed requirements. The intention is to save the additional time and effort of requirements gathering by the vendor, by giving them everything they need to know. But if you are the PM from the Vendor organization, this is not necessarily good for you. In fact, it can do more harm than good
Since the client's BA has already given you a detailed set of requirements, their management expects you to jump right into finalizing the scope (if not executing the project). This means you or your BA cannot try and find any crucial points that their BA may have missed. Hence you are more likely to face issues with scope approvals, or worse, with scope verification. Also you miss the chance to personally interact with the client employees and understand the power structures and political relationships within their organization, which would have helped you later in the project
