6 common mistakes when concluding software development contracts
Once again, we want to touch on the topic when a software developer company does its work, but the customer does not want to pay for it. And judging by the number of publications on a similar topic, the relevance of this issue for domestic software developers is growing.
The situation described below is a life situation. At the time of writing this article, this situation has not yet received final positive resolution for the software developer company (we will call it the IT company, the company name cannot be disclosed at the moment), with which we have been working for over a year to recover the seven-digit amount of debt. Perhaps, this article will be useful for someone and will allow to avoid a similar fate, or will allow to minimize possible losses if the situation is not yet very bad.
At the end of 2014, an agreement was signed between the IT company and the customer for the implementation of 1C. It comes to the end of the year, and as always it happens, the customer wants everything quickly and as cheaply as possible. Ordinary situation. Preliminary negotiations were successful. It came to the conclusion of the contract. The contract was prepared by an IT company, its design was quite simple. This form of contract was used for quite a long time and did not cause problems until a certain point. At the request of the Customer, a number of changes were made to the contract. Since the deadlines for the execution of works fixed in the contract were tightened and in order not to delay the approval of the document, it was signed in the form in which the Customer wanted to see it.
The project is in full swing. A design has been carried out, the TZ has been prepared, and its coordination has begun. As it often happens, the Customer is in no hurry to agree on the project documentation. An IT company decides to start developing on the basis of an uncoordinated TK at its own peril and risk. It remains a little more than two weeks before the completion of the development work and the TOR is finally agreed. Terms of delivery of work while not officially shifted. It was already clear that it would not be possible to meet the deadline for a certain period. One of the customer's requirements was to start working in the new system immediately after the New Year holidays. The contractor decided to take a risk, to start exploiting part of the subsystems of the created software solution as planned, i.e. immediately after the New Year holidays, doing the preparatory work for this during the New Year holidays. But as is usually the case in a similar situation, a white fluffy animal crept imperceptibly. Going about IT, the company underestimated the inertia of the customer’s specialists, and also undertook to fulfill a number of jobs not specified in the contract, using for this part of the resources employed in development, which in turn reduced its speed. And the problems that arose during the trial operation of the implemented subsystems switched the remaining part of the developers to extinguishing fires. The development of the rest of the functionality actually got up. There was a crisis of management within the project team of the contractor. Relationships with the customer began to get worse.
')
At some point, the customer managed to find a common language, at least it seemed to IT companies. Terms of work have been passed long ago. At some point, signs began to appear that the customer was simply cutting the rope from the performer and was not going to pay. It became clear that the case smells like kerosene. Later, these suspicions began to be justified. Only at this moment it was decided to attract for consultations a specialist in contractual relations and the return of receivables.
In the process of analyzing the contractual and primary documentation, a number of significant errors were identified, which reduced to zero the chances of getting money for the work done. The outcome of the case, whether positive or negative, depends on the documents with which you approach the lawsuit, if it is impossible to avoid it. We are going to talk about what documents are needed and how to arrange them correctly in the next article, write in the comments to this article, if the question is relevant for you, it will be an incentive for us to write.
The first mistake is a streamlined contract subject. But it was formulated as follows: “... the Customer charges, and the Contractor undertakes to supply and implement the 1C: Enterprise 8 software in accordance with Appendix No. 2 ...”. Appendix 2 contained little specifics, in form it was a specification indicating the types of work and labor costs for them. Each of the parties interpreted the subject of the contract in its own way. The contractor company understood by this the refinement of the standard 1C: Enterprise configuration for the customer’s tasks, its configuration and implementation. The customer saw that 1C: Enterprise will be installed and configured without any modification. He proceeded from the literal meaning of the words and expressions recorded in the contract, the court adhered to the same point of view, ignoring the fact of creating a composite software product within the framework of fulfilling obligations under the contract.
Some court practice:
The second mistake is obviously not feasible deadlines for the execution of work. One of the customer's requirements was a very short time to complete the work. The customer wanted to start operating the system immediately after the New Year holidays. The process of negotiating the agreement was delayed, but the project deadlines have not been shifted. The first time delay occurred due to the fault of the customer, when he delayed the coordination of project documentation, he was not allowed to influence this contract. The possible internal conflict of interests between the services of the customer’s company was also not taken into account. In the process of putting the work conflict of interest made itself felt. Services responsible for the acceptance of work in their areas did not hurry to do it, referring to the current workload. Also, one of the key persons of the company, on whose initiative the project was launched, has lost interest in it. Which also contributed to organizational resistance. In the end, the deadline was exceeded by more than 6 months.
The third mistake is the absence of a detailed technical task. Created during the execution of works, the TOR for the development of a configuration based on the standard configuration of 1C: Enterprise 8 was not well developed. It contained only general information about the configuration being created, and also had links to the functionality (printed forms, some work algorithms, etc.) of the information system previously existing at the customer, and which continued to be operated at that moment due to the fact that the new information system was not yet fully prepared. During the project, the existing IS also continued to be modified by the customer’s specialists. Accordingly, the contractor had to make modifications to the created IP, taking into account modifications of the old system. All this together led to difficulties in the delivery of works.
The fourth mistake is that the contractor agreed to the customer’s requirements to introduce a number of conditions into the contract which was clearly not beneficial for himself, but since the deadlines were tight and the customer’s representatives did not want to agree on the terms of the contract, the IT company management decided to take the path of least resistance. Let me remind you that it was the end of 2014, sanctions, the absence of other orders, etc., the picture is typical for many small IT companies that clutch at any job and are guided by the principle “the main thing is to start, and then we will look at it”. The terms of the contract were formulated in such a way that for each day of delay in the execution of the work, the contractor had to pay a large fine. After some time, the amount of the penalty rose to such a level that the project's profitability became almost zero and was constantly striving to become negative. This was facilitated by a weak organization of work within the project, and the inability to quickly deal with the problems of the project due to lack of resources, which were calculated based on the amount of work predicted by the terms of the contract, and were not designed to increase it. Taking into account enslaving conditions, one had to compromise with the customer and fulfill all his wishes. The situation was also aggravated by the fact that the continuation of the project required external funding, the attraction of which was very difficult.
The fifth mistake is that the contract does not clearly define the procedure for accepting work performed. According to the contract, to confirm the fact of the work was enough to submit an act of acceptance, if there are objections from the customer, he had to provide the contractor with a reasoned refusal within the stipulated time period in the contract. After completion of each stage of the project, the contractor presented the acts of acceptance of works to the customer. The RP of the customer had to organize the acceptance of the work, employing relevant specialists for this. Due to the lack of necessary powers, the RP of the customer could not and did not want to influence the terms of acceptance of the work. The contractor also could not affect the terms of acceptance of work, since the contract did not specify the sequence of actions during the acceptance process and there was no customer responsibility for delays. The contractor had to make a lot of effort to deliver the work to the customer.
The sixth mistake is not clearly defined the rules of document circulation within the project. The parties did not agree on how they will exchange documents and information within the project. Paper documents within the project (project, primary, etc.) were handed over to the representatives of the parties personally in their hands without fixing the fact of their transfer. E-mail was also used for the prompt transmission of documents and communications, but this method of exchange was not provided for by the contract. Later, when it came to court, the parties did not have the opportunity to refer to documents and information transmitted by e-mail, and to prove the transfer of paper documents was not possible at all.
Some court practice:
We hope that this article will be useful for readers and the recommendations outlined in the article will help to avoid negative consequences and lengthy lawsuits.
If you have questions, ask. If someone got into a similar situation, write to the address itjus@yandex.ru , we will be happy to help, and agree on the terms.
The situation described below is a life situation. At the time of writing this article, this situation has not yet received final positive resolution for the software developer company (we will call it the IT company, the company name cannot be disclosed at the moment), with which we have been working for over a year to recover the seven-digit amount of debt. Perhaps, this article will be useful for someone and will allow to avoid a similar fate, or will allow to minimize possible losses if the situation is not yet very bad.
Prehistory
At the end of 2014, an agreement was signed between the IT company and the customer for the implementation of 1C. It comes to the end of the year, and as always it happens, the customer wants everything quickly and as cheaply as possible. Ordinary situation. Preliminary negotiations were successful. It came to the conclusion of the contract. The contract was prepared by an IT company, its design was quite simple. This form of contract was used for quite a long time and did not cause problems until a certain point. At the request of the Customer, a number of changes were made to the contract. Since the deadlines for the execution of works fixed in the contract were tightened and in order not to delay the approval of the document, it was signed in the form in which the Customer wanted to see it.
The project is in full swing. A design has been carried out, the TZ has been prepared, and its coordination has begun. As it often happens, the Customer is in no hurry to agree on the project documentation. An IT company decides to start developing on the basis of an uncoordinated TK at its own peril and risk. It remains a little more than two weeks before the completion of the development work and the TOR is finally agreed. Terms of delivery of work while not officially shifted. It was already clear that it would not be possible to meet the deadline for a certain period. One of the customer's requirements was to start working in the new system immediately after the New Year holidays. The contractor decided to take a risk, to start exploiting part of the subsystems of the created software solution as planned, i.e. immediately after the New Year holidays, doing the preparatory work for this during the New Year holidays. But as is usually the case in a similar situation, a white fluffy animal crept imperceptibly. Going about IT, the company underestimated the inertia of the customer’s specialists, and also undertook to fulfill a number of jobs not specified in the contract, using for this part of the resources employed in development, which in turn reduced its speed. And the problems that arose during the trial operation of the implemented subsystems switched the remaining part of the developers to extinguishing fires. The development of the rest of the functionality actually got up. There was a crisis of management within the project team of the contractor. Relationships with the customer began to get worse.
')
At some point, the customer managed to find a common language, at least it seemed to IT companies. Terms of work have been passed long ago. At some point, signs began to appear that the customer was simply cutting the rope from the performer and was not going to pay. It became clear that the case smells like kerosene. Later, these suspicions began to be justified. Only at this moment it was decided to attract for consultations a specialist in contractual relations and the return of receivables.
In the process of analyzing the contractual and primary documentation, a number of significant errors were identified, which reduced to zero the chances of getting money for the work done. The outcome of the case, whether positive or negative, depends on the documents with which you approach the lawsuit, if it is impossible to avoid it. We are going to talk about what documents are needed and how to arrange them correctly in the next article, write in the comments to this article, if the question is relevant for you, it will be an incentive for us to write.
Revealed errors
The first mistake is a streamlined contract subject. But it was formulated as follows: “... the Customer charges, and the Contractor undertakes to supply and implement the 1C: Enterprise 8 software in accordance with Appendix No. 2 ...”. Appendix 2 contained little specifics, in form it was a specification indicating the types of work and labor costs for them. Each of the parties interpreted the subject of the contract in its own way. The contractor company understood by this the refinement of the standard 1C: Enterprise configuration for the customer’s tasks, its configuration and implementation. The customer saw that 1C: Enterprise will be installed and configured without any modification. He proceeded from the literal meaning of the words and expressions recorded in the contract, the court adhered to the same point of view, ignoring the fact of creating a composite software product within the framework of fulfilling obligations under the contract.
Some court practice:
Article 431 of the Civil Code of the Russian Federation, when interpreting the terms of a contract by a court, takes into account the literal meaning of the words and expressions contained in it. The literal meaning of the terms of the contract in case of ambiguity is established by comparison with other conditions and the meaning of the contract as a whole.
If the rules contained in the first part of this article do not allow to determine the content of the contract, the real common will of the parties should be clarified, taking into account the purpose of the contract. This takes into account all relevant circumstances, including the negotiations and correspondence preceding the contract, the practice established in the mutual relations of the parties, customs, and the subsequent conduct of the parties.
The second mistake is obviously not feasible deadlines for the execution of work. One of the customer's requirements was a very short time to complete the work. The customer wanted to start operating the system immediately after the New Year holidays. The process of negotiating the agreement was delayed, but the project deadlines have not been shifted. The first time delay occurred due to the fault of the customer, when he delayed the coordination of project documentation, he was not allowed to influence this contract. The possible internal conflict of interests between the services of the customer’s company was also not taken into account. In the process of putting the work conflict of interest made itself felt. Services responsible for the acceptance of work in their areas did not hurry to do it, referring to the current workload. Also, one of the key persons of the company, on whose initiative the project was launched, has lost interest in it. Which also contributed to organizational resistance. In the end, the deadline was exceeded by more than 6 months.
The third mistake is the absence of a detailed technical task. Created during the execution of works, the TOR for the development of a configuration based on the standard configuration of 1C: Enterprise 8 was not well developed. It contained only general information about the configuration being created, and also had links to the functionality (printed forms, some work algorithms, etc.) of the information system previously existing at the customer, and which continued to be operated at that moment due to the fact that the new information system was not yet fully prepared. During the project, the existing IS also continued to be modified by the customer’s specialists. Accordingly, the contractor had to make modifications to the created IP, taking into account modifications of the old system. All this together led to difficulties in the delivery of works.
The fourth mistake is that the contractor agreed to the customer’s requirements to introduce a number of conditions into the contract which was clearly not beneficial for himself, but since the deadlines were tight and the customer’s representatives did not want to agree on the terms of the contract, the IT company management decided to take the path of least resistance. Let me remind you that it was the end of 2014, sanctions, the absence of other orders, etc., the picture is typical for many small IT companies that clutch at any job and are guided by the principle “the main thing is to start, and then we will look at it”. The terms of the contract were formulated in such a way that for each day of delay in the execution of the work, the contractor had to pay a large fine. After some time, the amount of the penalty rose to such a level that the project's profitability became almost zero and was constantly striving to become negative. This was facilitated by a weak organization of work within the project, and the inability to quickly deal with the problems of the project due to lack of resources, which were calculated based on the amount of work predicted by the terms of the contract, and were not designed to increase it. Taking into account enslaving conditions, one had to compromise with the customer and fulfill all his wishes. The situation was also aggravated by the fact that the continuation of the project required external funding, the attraction of which was very difficult.
The fifth mistake is that the contract does not clearly define the procedure for accepting work performed. According to the contract, to confirm the fact of the work was enough to submit an act of acceptance, if there are objections from the customer, he had to provide the contractor with a reasoned refusal within the stipulated time period in the contract. After completion of each stage of the project, the contractor presented the acts of acceptance of works to the customer. The RP of the customer had to organize the acceptance of the work, employing relevant specialists for this. Due to the lack of necessary powers, the RP of the customer could not and did not want to influence the terms of acceptance of the work. The contractor also could not affect the terms of acceptance of work, since the contract did not specify the sequence of actions during the acceptance process and there was no customer responsibility for delays. The contractor had to make a lot of effort to deliver the work to the customer.
The sixth mistake is not clearly defined the rules of document circulation within the project. The parties did not agree on how they will exchange documents and information within the project. Paper documents within the project (project, primary, etc.) were handed over to the representatives of the parties personally in their hands without fixing the fact of their transfer. E-mail was also used for the prompt transmission of documents and communications, but this method of exchange was not provided for by the contract. Later, when it came to court, the parties did not have the opportunity to refer to documents and information transmitted by e-mail, and to prove the transfer of paper documents was not possible at all.
Some court practice:
Clause 3 of Article 75 of the APC RF states that documents received via facsimile, electronic or other communication, including using the Internet information and telecommunications network, as well as documents signed with an electronic signature or other analogue of a handwritten signature, are allowed as written documents. evidence in cases and in the manner prescribed by the contract.
Resolution of the Federal Arbitration Court of the Moscow District of May 17, 2013. in case N A40-102005 / 12-57-977 denying the plaintiff the satisfaction of his claims, the court pointed to:
• a simple written form of document circulation between the parties stipulated by the contract;
• lack of conditions for the possibility of execution of the contract by electronic correspondence;
• the absence of references to electronic addresses determined by the parties as valid for the transmission of any information;
• the inability to establish the ownership of the address to the respondent and his staff;
• The email address is registered on the domain kameya.ru, which is available for use by an unlimited number of people.
Resolution of the FAS of the Far Eastern District of November 16, 2012 No. F03-5177 / 2012 rejected Claimant’s argument for the transfer of controversial claims to the defendant by e-mail. The reasons for this conclusion of the court were both the failure to provide evidence of the parties agreeing on the use of electronic documents in the claim procedure under the disputed contract and the fact that the transfer of claims by e-mail does not indicate that they were received by the claimant.
In custody
- Clearly formulate the subject matter of the contract in order to exclude its ambiguous understanding;
- The terms of reference or its substitute document should be formulated so that the parties to the contract have a common understanding of how the software being created should function, what the user interface should look like, the reporting system, what technologies should be used when creating software, etc .;
- Specify the feasible deadlines for the work, taking into account the time required for the coordination of project documentation and acceptance procedures. Consider an increase in the terms of performance of work, in case of delays on the part of the customer of deadlines for the coordination of project documentation or the execution of works in his area of ​​responsibility, as well as his responsibility for such actions or omissions;
- Describe the procedure for the delivery of work, documenting the very fact of the transfer to the customer of the result of the work and the project documentation (project, primary, etc.).
- Describe the order of communications, how the correspondence will be carried out during the performance of work, specify the full name of authorized persons, their email addresses, telephone numbers. Ask for confirmation of the presence of powers from proxies (power of attorney, the order to vest authority).
- In addition, when concluding a contract or when executing it, we recommend avoiding direct references to GOST or other regulatory documents, this will help to avoid abuses on the part of the customer if the software or project documentation you create does not fully comply with the requirements of GOSTs, unless of course this is not explicitly provided by the contract .
- And the last recommendation, do not succumb to the pressure from the customer either at the time of the conclusion of the contract or in the process of its execution, do not settle for conditions that are obviously unprofitable for you. Better give up the contract, save nerves and money. Work only with those who are ready to fulfill their obligations, and of course, fulfill them yourself.
We hope that this article will be useful for readers and the recommendations outlined in the article will help to avoid negative consequences and lengthy lawsuits.
If you have questions, ask. If someone got into a similar situation, write to the address itjus@yandex.ru , we will be happy to help, and agree on the terms.
Source: https://habr.com/ru/post/314944/
All Articles