A well-drafted IT contract is an insurance policy for an IT project. Anyone involved in drafting and negotiating IT contracts should follow a certain methodology to achieve the optimum result. Of course, the methodology depends on the type of IT project and the services rendered. The drafting phase is the most appropriate time to tune the contract to the best advantage. This can save money and help to avoid further disputes when properly performed.
In order to tune the contract properly, it requires a good understanding of the technical and legal issues involved in the IT project and the type of problems that might arise during project implementation and afterwards. So the contract has to be specific, not general. Many managers overestimate their understanding of the technical side of IT projects and the legal risks associated, thus often excluding technicians and legal experts from drafting. But this limits the ability to assess possible risks and address them in the right way at the right time.
First of all, do not delay to start; contract negotiations in IT projects take longer than you may think at first. Do not leave contract drafting to the last minute. Contract problems multiply with rushing. So consider legal and technical risks at the contract design stage.
Secondly, set the objectives. Do not try to tune all contractual clauses to perfection at once. Use the return on investment method to identify the parts of the IT project which are most critical and profitable to you. Once these parts are identified, describe them in the contract. It is always useful to have several versions of the same contract clause during negotiations. Your objectives should be defined in a form accepted and agreed by all parties involved. For example, setting technical objectives and application of specifications are crucial for service level agreements.
In IT contracts it is vital to check the parts that foresee the scope of the license or transfer of copyright in the software created. Software developers are interested in maintaining the rights necessary for software distribution because individual software, once created for a particular company, may easily be applied elsewhere and later may be marketed as standard software. In contrast, the customer who financed software development very often does not want to leave any economic copyrights to the software developer. One of the most important parts of an IT contract is the detailed description of granted rights by using the software. In case of license grant you should check whether the license is exclusive or non-exclusive, for a definite or indefinite period; as well as which territory it covers; how many users will be able to use the software at the same time; on what conditions the customer will be able to transfer the software to third parties; whether the license gives a right to the customer to modify the software independently and so on. Here it is important to agree on the source code of the software, for example, to indicate whether the source code is part of the contract or not, because further development of the software depends on it.
Furthermore, it is also very important that the contract clearly provides quality requirements for software, warranties and liability, the duties of the parties in the process of software implementation, methods of project management, testing, dispute resolution, payment conditions, exit provisions, agreement on further maintenance of software, as well as the method of acceptance and transfer of interim and final work results. When accepting the final version of software the customer should confirm that the software corresponds to the technical specification provided in the contract and functions without substantial defects. Upon signature of the acceptance-transfer act the software cannot be refused because of the minor defects which normally always exist in software. Before accepting the final works of the IT software, it is advisable to agree on a certain period during which operation of the final version of the software will be tested.
For the software producer it is useful to narrow liability insofar as the law allows. Generally, liability is limited by a certain monetary amount and loss occurring only because of certain events. In the part which determines liability, laconic wording that damage is compensated in accordance with the law may appear to be more beneficial to the buyer.
All in all, the parties often underestimate the contract drafting process hoping that friendship may resolve all conflicts in IT projects. But life teaches us that when conflict arises parties tend more to rely on the contractual wording than on oral promises.
In order to tune the contract properly, it requires a good understanding of the technical and legal issues involved in the IT project and the type of problems that might arise during project implementation and afterwards. So the contract has to be specific, not general. Many managers overestimate their understanding of the technical side of IT projects and the legal risks associated, thus often excluding technicians and legal experts from drafting. But this limits the ability to assess possible risks and address them in the right way at the right time.
First of all, do not delay to start; contract negotiations in IT projects take longer than you may think at first. Do not leave contract drafting to the last minute. Contract problems multiply with rushing. So consider legal and technical risks at the contract design stage.
Secondly, set the objectives. Do not try to tune all contractual clauses to perfection at once. Use the return on investment method to identify the parts of the IT project which are most critical and profitable to you. Once these parts are identified, describe them in the contract. It is always useful to have several versions of the same contract clause during negotiations. Your objectives should be defined in a form accepted and agreed by all parties involved. For example, setting technical objectives and application of specifications are crucial for service level agreements.
In IT contracts it is vital to check the parts that foresee the scope of the license or transfer of copyright in the software created. Software developers are interested in maintaining the rights necessary for software distribution because individual software, once created for a particular company, may easily be applied elsewhere and later may be marketed as standard software. In contrast, the customer who financed software development very often does not want to leave any economic copyrights to the software developer. One of the most important parts of an IT contract is the detailed description of granted rights by using the software. In case of license grant you should check whether the license is exclusive or non-exclusive, for a definite or indefinite period; as well as which territory it covers; how many users will be able to use the software at the same time; on what conditions the customer will be able to transfer the software to third parties; whether the license gives a right to the customer to modify the software independently and so on. Here it is important to agree on the source code of the software, for example, to indicate whether the source code is part of the contract or not, because further development of the software depends on it.
Furthermore, it is also very important that the contract clearly provides quality requirements for software, warranties and liability, the duties of the parties in the process of software implementation, methods of project management, testing, dispute resolution, payment conditions, exit provisions, agreement on further maintenance of software, as well as the method of acceptance and transfer of interim and final work results. When accepting the final version of software the customer should confirm that the software corresponds to the technical specification provided in the contract and functions without substantial defects. Upon signature of the acceptance-transfer act the software cannot be refused because of the minor defects which normally always exist in software. Before accepting the final works of the IT software, it is advisable to agree on a certain period during which operation of the final version of the software will be tested.
For the software producer it is useful to narrow liability insofar as the law allows. Generally, liability is limited by a certain monetary amount and loss occurring only because of certain events. In the part which determines liability, laconic wording that damage is compensated in accordance with the law may appear to be more beneficial to the buyer.
All in all, the parties often underestimate the contract drafting process hoping that friendship may resolve all conflicts in IT projects. But life teaches us that when conflict arises parties tend more to rely on the contractual wording than on oral promises.