Contracts to Implement Corporate Information Systems

Tomas Nielsen, IT Systems Magazine

A well-drafted contract is one of the keys to a successful implementation of any IT project. Although the parties sometimes approach the negotiation for a contract with the feeling that they will have to solve the potential issue decently anyway, the practice has shown that there are moments in the life of an IT project where an elaborate drafting process really pays off.

As the basis of the project, the contract for development of corporate information systems or provision of services often becomes subject of discussion if a more severe issue arises. Quite often, the parties seek any, though only formal, gap which would help them in resolving the dispute. Therefore, the contract deserves special attention in order to prevent long-winded disputes.

Another important element of the contract the parties tend to forget about is the necessity to clearly formulate the mutual requirements. Even though the supplier and the client mostly understand each other well, it is at the time of having to put down the agreement in writing that new questions arise.

Now, what should a good IT contract to implement the corporate information system and provide services include? First of all, the contracts have to unambiguously, clearly, and understandably specify the subject of performance and the implementation process. The corporate management not always has a clear idea about how the information system should function right from the beginning. Therefore, such projects usually comprise two phases - the analytical and the implementation phase.

From the contractual point of view, a situation where the elaboration of an analysis (meaning detailed assignment for the IT supplier) is delivered independently of the implementation - upon an independent contract - causes no vital problems. Nevertheless, the practice shows that the analysis is often a part of the implementation process as such. From the legal point of view, this means that the contract contains particular definition of a part of the performance (arrangements relating to the output of the analysis) and a more or less general definition of other performance (the implementation might be affected by the outcome of the analysis). In such cases, especially the question what will happen if the client refuses to take over the analysis should be solved. Or what will happen if the analysis proves it necessary to increase the price of the whole implementation?

The solution always depends on the particulars of the case. Sometimes, the contract might include the specification of the whole information system including reflecting the changes into the assignment provided the client accepts them within the analysis. Should the client not accept the analysis, the supplier proceeds pursuant to the original assignment. Alternatively, they might agree on the client's right to withdraw from the contract in the implementation stage, should he not agree with further procedure pursuant to the analysis, whereby in such case, he pays the supplier the price of the work done on the analysis. Of course, should the supplier breach his duties in the course of the analysis, i.e. the analysis would show deficiencies, the liability principle in relation to such defaults should be applied, including all the possible impacts (right to have the deficiencies removed, right to withdraw from the contract etc.). In order to be able to conclude that the analysis contains defaults, it is really necessary to set the parameters of the analysis.

In addition to the specification of the performance, the contract should always include also the process of taking over this performance by the client so as the client's right to a regular performance as well as the supplier's right to be paid the stipulated consideration for the regular performance are guaranteed. In case of implementation, the contracts should ignore the potential situations where e.g. the client fails to provide a timely necessary cooperation or starts to use the information system without its prior acceptance. Meanwhile, the client should take particular care that the written specification clearly states when the system shows deficiencies, i.e. when exactly he is entitled to request the supplier to have them removed. It namely often happens that the client realises only in the course of the implementation that he has a "different idea" about certain functionality, whereby the specification of the work does not include this idea. A very often made practical mistake is that the parties leave this question unsolved and refer to a future agreement; however, such agreement is not so easy to be reached at the end of the project. Quite often, such disputes are referred to the court.

A more complicated issue is the handing over of the performance in form of services. Where corporate information systems are concerned, this relates particularly to their maintenance, upgrades or customisation. The performance, meaning service, has a certain output in many cases. This output may be subjected to conditions similar to conditions for the taking over of the implemented system (hence, not the services but their outcomes are taken over). In other cases, the probably only measurable quality is the quality of the person providing these services and, of course, the workload. Both of the contracting parties should realise what the provided service relies on and how it might be evaluated; whether the service was provided duly or not. And to reflect this principle in the contract as unambiguously as possible.

A completely independent, but not less important chapter about similar IT projects is the regulation of copyrights, i.e. the client's rights to dispose of the information system. The licence agreement should always provide answers to essential questions like:

  • Who might use the information system?

This requires taking into account whether only the client's staff will access the system or, for instance, also the affiliated companies, contractual partners, clients, suppliers, etc.

  • What is the term of the licence agreement?

Usually, we distinguish between licences provided for the period of "existence of rights derived from property" (i.e. for the period during which the respective system is copyright-protected) and fixed-term licences (e.g. for two years).

  • Where might the information system be used?

Does the client operate really exclusively in the Czech Republic? Is he not thinking about potential expansion abroad?

  • How might the information system be used?

The contract should clearly state whether the client might add on or customise the system, to name a few.

The dispute resolution is an essential part of the contract. To let arbitration resolve the disputes which the parties are unable to solve by agreement is becoming more and more popular. Involving expert arbitrators, they allow for a quick and private resolution of disputes. Many implementation and service contracts underestimate also the clause on terminating the legal relationship. In case of implementation, the parties should clarify what impacts the potential withdrawal from the contract will have on the already provided performances, supplied licences etc. Subsequently, they should transform this agreement into a contract. With services, the situation might be a bit more complicated, as the client might be interested in retaining the information system and sourcing only the services from third parties. This should be accounted for when drafting the contract, not only in the part relating to the licences, but also in the provisions relating to the impacts of the termination of the contract. The change of the service provider very often requires certain cooperation with the current provider (e.g. with data migration).

Now, is there any recipe for drafting a good IT contract? Surprisingly, there indeed is. Although both suppliers and clients come across relatively complicated legal issues when drafting contracts, they should always act openly in negotiating for contracts. They should also try to negotiate for a win-win situation. In the Czech environment, and this applies twice as much to the IT marketplace, a series of contracts exhibits a fully incredible, although very critical deficiency - incomprehensibility. The authors of such contracts, whether educated in laws or not, very often with relatively complicated formulations try to put basically simple principles into the contract. In doing so they forget about the associated risks - if the supplier or the client do not understand the contract, this gives rise to a possible reason for a future dispute. If the contract is incomprehensible to the extent that it is absolutely not clear what shall be communicated by which provision, the contract (or minimally the respective provision) might become ineffective. Upon drafting contracts, the parties should also bear in mind that these documents must be understood not only by persons preparing them but also by the potential successors and, in case of a more serious dispute, the courts.