Quality Contracts as Important Investments Protecting Tools

Companies’ interest in building an information system in support of processes has been rising year after year irrespective of a company’s sphere of business, thanks to the new business policies of suppliers and to technological development almost regardless of a customer’s size. The information systems in support of the supplier-customer relations (the so-called ERP or SCM systems), relations with customers (CRM) or a company’s economic transactions generally, are now being offered in several forms from package solutions, where the system is in fact “only” set up for the company’s needs, to customised systems up to applications developed completely on a turn-key basis.

The building of an information system represents a relatively complicated process which is why it is important that already from the beginning of a project, that is, during negotiations on the manner of implementation and anchorage in the contract on the supply of the information system, both parties proceed responsibly and so avoid any future problems. The part of the project when a contract is concluded with a customer is underestimated by many supply companies. The most traditional argument is: “No contract will help us implement the project. Mutual cooperation is necessary, a contract is only a formality.” This opinion is correct with one reservation. If there is a dispute between the parties a contract suddenly becomes the most important weapon for both parties. For this alone it is recommended not to underestimate a contractual arrangement.

Rationality vs Desire to Succeed

One of the basic problems with respect to the building of an information system is the suppliers’ attempt to obtain an order at any rate. Although the risks of such an approach are brought to attention at nearly every IT conference, the problems with this approach persist.

The results of the desire to succeed are often contracts with a very vague definition of the subject of performance and with a price reaching the border of carrying-capacity. It has two negative impacts: there can exist (as is often the case) the non-agreement of the parties with respect to the idea of what is to be supplied. The parties tend to use formulations such as “standard functionality” or “system in support of the company’s standard processes.” However, when doing so they do not realise that by the word “standard” the supplier understands that what is common to companies operating in the same market while for the customer only its processes are standard (to the exclusion of internal non-standard processes).

The second problem is the economic necessity that the supplier minimise all costs, in particular those which will appear only additionally in the development of the information system. Such a situation is not in the interest of the IT company which supplies the system, but it definitely harms the customer as well. For this reason it is necessary when negotiating a project and contract that the parties act frankly and realistically.

Moreover, it is necessary to (bilaterally) count on the fact that the description of an information system cannot often completely express the application complexity. The company processes which are to be supported by the IS usually differ, at least in some details, from the other ones and are still developing. Each information system is then de facto a unique work.

Project Processing as Part of Performance

It is evident from what has been mentioned above that for the specification of an information system building project it is usually necessary to carry out a thorough analysis of a specific situation on the part of the customer. The product of this is then the description of the project, sometimes identified as the blueprint or target concept.

Just the fact that the description of an information system is processed as late as part of contractual performance distinguishes IT from other branches, including the building industry which it is, nevertheless, often compared with. It is absolutely necessary in a contract that the contracting parties count on such specifics. The description of an information system in the contract may significantly differ from the description in the project (the analysis often discloses the needs for further modifications of the application, in particular in the user interface).

The additional specification of the subject of contract performance can usually be reflected in particular in the price of the project (thus, the contract should count on the possibility of adjustments of the price if it appears from the blueprint that the system will be more robust and the extent of works will be more extensive compared to the original presumption) but also in the supplier’s ability to fulfill the customer’s requirements (the contract may, for example, contain limits which cannot be exceeded by the specification of the subject of performance, or an arrangement on the possibility to withdraw from the contract). The manner in which suppliers may fight against the risks mentioned is not easy if the contract is to be balanced and is not to represent, for example, the risk of significant exceeding of the original budget for the customer.

The processing of the blueprint should be regulated in detail in the contract because the project itself represents considerable value for the customer (to whom it describes the internal environment) and a considerable volume of work for the supplier’s qualified consultants. For this reason it can be recommended that the contract do not omit provisions relating to the eventual right to use the project documentation (processed under the contract) on the part of the customer in case of the premature termination of the contract and of course to the supplier’s eventual right to the payment of the price for this part of performance.

Work Handover and Takeover

One of the most problematic parts of the information system building project is the determination of a bilaterally just process of the takeover of the work. An almost standard part of this process is the testing of the delivery in the form of acceptance procedure.

Practice shows that the apparently most important parameter of the acceptance procedure must be its applicability. In contracts suppliers often regulate a very complicated and sophisticated procedure to find, at the moment of a dispute as to whether the information system was delivered and thus the right to the payment of the price was created, that their project manager failed to fulfill even an inessential formal element of the procedure. Although formal mistakes in the acceptance can be sought only exceptionally, neither the cost associated with a long-term recovery of a claim is in any case a meaningful investment. The system handover process should be really agreed in a manner that it be performable by both parties. It is then up to each party to perform its obligations arising from the contract.

In the arrangements on the acceptance specific mistakes quite often appear between which in particular some “agreement on agreement” stands in front. These provisions are those such as “the parties will agree on the specific criteria of acceptance and the acceptance procedure process.” The contract often lacks an arrangement on how to proceed if the parties fail to arrive at an agreement. Nevertheless, it is really useless to deal with such an issue in court because the court will not decide whether a system was properly handed over, but only in what manner it should be accepted. Thus, a judgment does not bring peace between the contracting parties and is only the pre-stage of another dispute.

Liability for Damage

Identifying liability for damage has a completely specific nature in contracts on information system building. There are several reasons for this. The most essential is that unlike most other parts a relatively complicated legal institute, which is the subject of the extensive theoretical considerations of legal experts, is concerned. The Act (in the given case the Commercial Code) regulates this issue with several provisions from which the parties cannot depart.

From the damage perspective in particular the following facts are essential:

- The damage is understood as the actual damage and lost profit which occurred in consequence of a breach of an obligation by a contracting party (damage is also the harm incurred by the aggrieved party in connection with the fact that the party had to incur costs in consequence of the breach of an obligation by the other party).

- The liability for damage is stipulated by law and cannot be contractually limited.

- The contracting parties are obliged to prevent the occurrence of damage.

Several facts that suppliers sometimes do not completely clearly realise follow from the above. The first is that the damage really constitutes only three forms of decreasing the contracting party’s property and liability arises in fulfilling the following conditions: a contracting party breached its obligation (irrespective of whether it was stipulated by contract or by law), the other party incurred damage, and there is a causal relation between the breach of the obligation and damage.

The contracting party may release itself from the liability for damage only in some cases. The first is that the damage occurred in consequence of the circumstances excluding liability (as defined in Section 374 of the Commercial Code). Others are cases where the failure to fulfill its obligation was caused by an aggrieved party’s action or by insufficient provision of cooperation.

One of the problems of Czech legislation is that the Commercial Code does not enable liability for damage to be limited. Unlike the relations between entrepreneurs and consumers (in particular natural persons) such a break through the principle of contractual freedom is ununderstandable since in business legal relations it is difficult to find a rational reason why the Code de facto protects the customer as a weaker party and does not enable an agreement that the maximum amount of damage one party will be obliged to pay to the other is the amount specified.

In particular in the sphere of information technologies the damage caused by a defect in only a small (and relatively cheap) application may reach immense dimensions; even the customer can admit that with regard to the price of the application it would not be just if the supplier was liable to the full extent. In this respect the only possible tool of defense against claims for compensation for unreasonably high damage needs to be drawn attention to, which is the institute of liability for damage the contracting party could not have foreseen in the conclusion of the contract.

Thus, in connection with liability for damage it can be recommended that the contracting parties sufficiently exactly specify the mutual obligations it is in particular suitable that a clear arrangement on the customer’s cooperation exist.

In many contracts liability for damage is secured by the institute of contractual penalty. A relatively complicated (and in the term of such complexity often underestimated) institute is concerned. It is important to draw attention to at least one basic difference between compensation for damage and payment of a contractual penalty. The difference is the liability of the party breaching a contractual obligation. As already mentioned, in case of damage a party may release itself from liability if it proves that it breached the obligations in consequence of the circumstances excluding liability. This does not in principle apply to the contractual penalties.

Other Specifics of IT Contracts

In the formulation of a contract on information system building it is also necessary to deal with other issues arising more or less from the legal regulations. It is not, for example, possible to leave aside the granting of particular licences to use the computer program supplied within a project. The contracting parties should agree on the scope of use, the duration period of the licence and its territory or quantity limitation. It applies as follows – if the contract does not contain the details mentioned, it is necessary to derive them from the purpose of the contract. The supporting provisions of the Copyright Act can be applied according to which (unless the contract stipulates otherwise or anything else arises from its purpose) the licence is granted for a maximum period of one year for the territory of the Czech Republic and with respect to the “usual” quantity.

Another important arrangement is an agreement on guarantees being the guarantees for legal and factual defects, hidden defects, and defects that arise only upon supply of the information system. Here, the Act provides (unlike in classic consumer contracts) the parties with relatively large freedom. Despite (or maybe because of) this it is possible to see a situation where IT suppliers have no clear idea of what defects can be guaranteed and in what manner and so many contracts are pretty unclear in this part (with all associate risks).

Of course, the overview mentioned is not an exhaustive guide on how to create contracts on information system supplies. There are many other issues the contracting parties should clarify in their negotiations and appropriately contractually regulate. We can only wish to all suppliers that the projects implemented by them be supported by transparent actions and the need for propping upon contractual arrangements be really minimal.

Tomáš Nielsen

ROWAN LEGAL