Successful project? Clear acceptation definition

Tomas Nielsen, CFO World

Information system implementation disputes almost always revolve around one thing – so-called project acceptance. Although not yet clearly defined in law or by judicial judgements, the term (acceptance) is almost regarded as a legal term now. A stumbling block indeed; if the parties fail to have the project acceptance process clearly defined, they, sooner or later, come across two issues: when the customer is obliged to accept the work and when the supplier is entitled to invoice the customer for the price of work.

Submitting the work for testing is not exclusive to the information technology market only; as a matter of fact, tests are expressly allowed for in Section 555 of the Czech Commercial Code. Nonetheless, to have the acceptance process clearly and correctly defined, one needs (or is highly recommended at least) to properly understand some legal terms mentioned in the Czech Commercial Code, namely "work completion" and "acceptance". First and foremost, the customer is not bound to accept semi-completed work (that is, defective or faulty work). In the field of information technologies, the work is submitted for acceptance; that is, an a contrario approach is adopted here - the customer is obliged to accept the work if the work submitted for acceptance is found during the acceptance process (duly) completed. However, the term "acceptance" is not addressed by the Czech Commercial Code at all; the work is supposed accepted when delivered. But what happens when the work is accepted, passes the tests, but subsequently is found defective? In such cases the work acceptance is not annulled; only the legal relationship between the supplier and the customer gets altered - the supplier's duty to complete and deliver duly completed work changes to his duty to remove the defects revealed (and, optionally, to compensate the customer for damage, etc.)

In practice, the acceptance itself should not only be formally mentioned in information system implementation contracts but rather its process be precisely defined. This has two fundamental impacts: if the supplier fails to prove during the acceptance process that the work submitted for acceptance is completed, there is no reason for the customer to accept the work (and pay the price agreed); otherwise the customer is bound to accept the work or else he is in default with payment. The abovementioned provision, however, is not mandatory, that is, the parties can agree otherwise; in IT, it has sense especially in respect of customized information systems, i.e. systems that are adjusted according to customers' individual requirements. Such an agreement (that the customer is bound to accept the work even if defective) should always go hand in hand with specific warranty terms and conditions stating that any defects revealed by the customer will be addressed following the acceptance.

Setting the acceptance conditions, the parties should primarily consider the abovementioned impacts and define the process accordingly; not forgetting about the practical risks that are often uncared for and that lead to disputes as well. The first one is the insufficient definition of supplier's duties and obligations prior to submitting the work for testing; meaning that the supplier can deliver semi-completed work to the customer and wait for his comments raised during the acceptance process informing the supplier about what the system is missing. The second risk is the insufficient definition of customer's duties and obligations; being constantly and repeatedly informed by the customer about new defects, the supplier becomes unable to have his work accepted (no strict conditions imposed on the customers here can be effective without the strict conditions imposed on the suppliers in respect of preparing the work for acceptance being defined first). The process of accepting the work, however, needs to be distinguished from verifying (checking) whether the work is implemented in accordance with the contract. The parties should be aware of and in their implementation contracts ideally split the project into several milestones (typically detailed performance specification, individual function/process models, pilot operation of individual functions, and system pilot operation). Structuring the mutual co-operation in this way provides for the protection of not only the supplier who receives feedback from the customer shortly after the inception but also of the customer who no more needs to be afraid of being flooded by information from the supplier and virtually left to complete the work himself as part of the acceptance process.

(Published in CFO World magazine)