The work requested from our Client was the adaptation and implementation of an ERP system of 12 modules for the needs of a large Belarusian enterprise. The project did not even reach the stage of acceptance testing and stalled at the stage of technical documentation approval.
It would seem that software implementation projects have the same attributes: there is time, there are resources, and there is a volume of tasks set by the customer. What can go wrong? If we consider this case, turns out all of the above can go wrong even if you have accumulated expertise on the “domain” (field) of the customer.
Where the dispute began
As a rule, business analysts are those in IT sector dealing with the client's requirements (as well as their expectations). This is them who, having read PMBOK and Karl Wiegers’ books from cover to cover, conduct numerous interviews with client representatives, work with stakeholders, do modeling and prototyping, prepare Vision & Scope and other documents required for the start.
But to successfully pass this stage, the efforts of business analysts alone are not enough. Continuous support and result-oriented interaction from the customer's team is required.
How the dispute developed
The contract with the customer assumed a stage-by-stage execution of works with a stage-by-stage payment. The initial prepayment was meant for the ERP manufacturer's license and some backlash to advance the start of work.
The contractor dispatched his employees to the customer's site to study his business processes in order to draw up the technical requirements of the project (blueprint).
Blueprint development was very problematic.
First, the integrator's team got the feeling that there was no necessary project support from the customer's team (low executive discipline, constant project bureaucratization).
Second, the was a language barrier (the hired translators were unable to accurately translate technical aspects).
Third, the contractor also turned out not to be fully prepared for the peculiarities of the Belarusian legislation (in terms of accounting, tax, personnel records).
As a result, blueprints were made out of time. The customer did not accept them, referring to non-compliance with the requirements.
It was though not fully clear which requirements exactly, since these requirements are formed by the customer at the stage of business analysis.
To the barrier
The parties began to exchange pre-trial claims and eventually ended up in court. The customer offered to postpone the payment date to the final stage (after all the work is completed). The contractor did not agree to this, referring to the principle of the stage-by-stage execution of works and stage-by-stage payment established by the contract.
As a result, the customer of the ERP system filed a lawsuit demanding the return of the advance payment and referred to the fact that the project was not implemented due to the contractor’s fault.
Having sorted out the complex twists and turns of the relationship between the parties and a large amount of technical information, we prepared the position of the contractor, and also filed a counterclaim demanding the payment for the prepared blueprints and linking the failure of the project with the fault of the customer.
Having questioned many of the customer's arguments, we were able to make him interested in the negotiations in order to settle the dispute peacefully.
В конце концов в ходе переговоров нам удалось найти точки соприкосновения между подрядчиком и заказчиком, и судебный процесс был закончен взаимовыгодным мировым соглашением, по которому:
In the end, during the negotiations we managed to find common ground between the contractor and the customer, and the trial ended with a mutually beneficial settlement agreement according to which:
- the customer retains the results of work (blueprints) and the ERP system license;
- the contractor has an advance payment that will compensate the costs of prepared blueprints and licenses purchased from an ERP manufacturer.
- This case contained no objectivity in terms of the task and the result of the work. There were no objective quality criteria that were equally clear to both sides of the project. In a situation where quality requirements are stated (and approved) by the customer himself, it is worthwhile to meticulously record the result of each negotiation. It is true that this does not give you any guarantees of a completed project. This will give a reasoned position in court and the prospect of getting earned money faster than the opponent sees it, Artur Skrebets, the lawyer of Arzinger-Attorneys, sums up.



