Stay in the loop with the most important updates
Contact: Tijana Žunić Marić
Software Development Agreement (i.e., SDA) often shares the fate of Hollywood celebrity marriages. In the beginning, partners hold high expectations of each other and believe in the bright future ahead. However, after a while, the end seems inevitable, and the breakup can be turbulent and costly.
This is usually the moment when the contracting parties realize they haven’t understood each other since the very beginning, which indicates inadequate regulation of certain matters. With the SDA, every provision is crucial, and if not paid sufficient attention, a tiny detail may be the point of disagreement in the future.
Software Development Agreements are specific due to their complexity. A Master Software Development Agreement is always accompanied by Statements of Work, Instructions, Schedules, Licenses, and Service Level Agreements (“SLA”), which make these agreements complex legal acts, compiled of several different documents, often not in a coherent whole that leads to contradictions between several documents regulating the same project. When taking into account the fact that it is quite difficult to anticipate the technical requirements and specification for software development in detail, and that the initial cost estimate of the entire project is often imprecise, the hard fact that at least 50% of projects fail before the estimated completion date does not surprise.
The biggest hurdle service providers endure are late or missed payments, client’s attempt to extend the originally established scope of the project (known as the “scope creep”) with additional instructions, or when the service provider believes that the previously agreed-upon criteria for project deliverables are met, while the client believes otherwise. On the client-side, the problem arises when software delivery or project deliverable are delayed or if the quality of the delivered software does not meet the technical and/or functional specifications, which also may be the subject of disagreement between the parties.
Complications occur even more frequently when the service provider does not execute the project alone but engages subcontractors (known as the “one throat to choke” model). In these agreements, it is also very important to prescribe liability of the service provider for election and potentially work of those subcontractors, if he is the one electing them. The alternative model is to use a multi-vendor IT agreement, which, on the other hand, holds an exponential threat for eventual disputes, due to the existence of multiple service providers in charge of particular parts of the project and the complexity of legal matters.
Bearing in mind that these agreements are usually concluded for several years, what should also be considered are the challenges entailed by the market fluctuations (e.g. changes in labor cost/services/equipment, etc.). On top of that, the changes in the client’s business strategy, which does not have to be related to the execution of the SDA itself (for example, a change from the outsourcing to insourcing business model).
With all the abovesaid, it becomes quite a challenge to exit a Software Development Agreement with as little harm as possible to the contracting parties.
Generally speaking, if the disagreement between the contracting parties escalates, the parties have the following options:
Both technical and legal sides of the project should be considered in order to come up with the best possible commercial decision. Technical issues include what went wrong in practice – unrealistic deadlines, lack of resources, unforeseen costs, changes in the project scope, etc. Legal issues refer to how the agreement and the applicable law handle the issues of the matter.
To come up with a final decision, the technical level of the services performed so far needs to be determined. The classic questions that a client will wish to know the answers to are:
A special problem may arise when the client realizes that the service provider is not technically able to complete the project, but the project is currently in such a stage it would be inefficient (or even impossible) to have it completed by a new service provider. The client can then be locked in the Software Development Agreement and forced to make concessions to the service provider, just to be able to complete the project.
The practice has shown that the contracting parties are often unaware of all the rights, obligations, and responsibilities arising from the Software Development Agreement, although this is paramount to the success of the project.
For example, it may be clear that the one-year deadline for project completion has been broken, but it stays unclear who’s to blame for that delay. The following question is whether the service provider now must complete the project for no additional cost incurred to the client or does the client have to pay an increased fee for the changes he requested and that caused the delay?
When a problem occurs during a project, the most common provisions to help you decide whether to start with the new negotiations or to terminate the Software Development Agreement are:
Provisions that enable checking whether the execution of the agreement is consistent throughout its duration and to align the agreement itself is aligned with the changes in the project scope and cost. Benchmarking is a good formal way to revise the agreement while maintenance is in effect. This option allows the service provider to commit to adjusting the price for the software development service with the market price, in clearly specified time intervals. However, it is highly important to carefully stipulate this possibility in the Software Development Agreement, so as to provide benefits to both parties. If this provision is made solely with the client’s interests in mind, the service provider may not feel motivated to maintain a high standard of service, which will, in essence, lead to nothing more than a Pyrrhic victory in the end.
Almost every IT project involves changing certain elements, both technical and legal, so anticipating change control procedures is crucial. Contracting parties should agree on the procedure to be followed if a particular change is to be implemented and establish clear parameters for the acceptability of a particular change. However, one should be aware that the contracting parties may not have always followed the change control procedure stipulated in the agreement. In practice, during the execution of the agreement, contracting parties may have implicitly adopted different mechanisms for the change. Therefore, it is important to analyze all formal requirements for the change of control in the contract, as well as to hold the parties accountable for the duration of the agreement, to determine anything that may affect the legal stance.
The agreement should provide for the procedure that is to be followed in the event of termination of the agreement, which will clearly define the rights and obligations of both parties. Such provisions generally provide for the preparation of an “Exit Plan” or “Exit Management” or “Exit Schedule” regarding a list of all activities necessary to transfer to a new provider or the client’s in-house team.
For example, what happens to the equipment or access to the software that the client now has to hand over to the new service provider, and is the current service provider obliged to assist in such a transition? Depending on how intellectual property rights are regulated, the client should ensure the transfer of those rights from the service provider. Unfortunately, this is rarely the case because contracting parties are not prone to focusing on the termination of the agreement and transfer issues, as much as married couples dread talking about their prenuptial agreement.
If you are a client, you will wish to have contracted the option of engaging an additional service provider for your software development project. Clients are often advised not to outsource the entire project to just one service provider due to the simple fact that once a service provider has complete control over the project, termination of the agreement is much more difficult for the client. Besides, by introducing an additional service provider, the client has a stronger bargaining position, especially in terms of price.
When making the final legal decision as to whether the Software Development Agreement will endure or whether the exit is the right solution, it is important to pose a legal question as to what happens to intellectual property rights. It is paramount to clearly distinguish who will be the holder of intellectual property rights in software, materials, and documents, should the project stop at this stage?
If the client is not the rights holder in software as per the agreement, but the service provider holds the rights (in whole or in part), it is impossible to replace the service provider with another contractor who would continue where the first contractor left off.
It is not uncommon for the seemingly slight linguistic nuances to produce this effect. For example, using the future tense in a formulation (for example, “… will transfer intellectual property rights”) instead of the present tense (for example, “…transfers intellectual property rights”) can cause a problem. This happens even if the service provider is responsible for the breach of contract due to failure to execute the service, that does not mean that the client will acquire ownership of the intellectual property rights.
Besides, in the agreements drafted under the law of one of the federal US states, incorrect linguistic nuanced may lead to truly problematic results. For example, contracting parties often describe the software as “work made for hire”, believing that it will automatically transfer all ownership of the software to the client. However, under the US copyright law, the program code may not fall under the so-called “work made for hire”.
For the service provider, on the other hand, what matters is what will happen to the intellectual property rights on their previous projects, and how to separate the intellectual property rights that the provider already holds before entering into the project (i.e., Background Technology) from those arising from the new IT agreement.
It is the client who will insist on the precise regulation of the intellectual property rights, as, in the absence of explicit contractual standardization, our law (as well as the e.g., UK Law and many more around the world) protects the author of the work – in this case, the service provider as the creator of the software.
Unless the agreement clearly defines how to resolve any eventual disputes between the contracting parties, the contracting parties will need to look for an answer in the applicable law. The applicable law is one that is enforced by the client and the service provider. Software Development Agreements are often agreements with an international element, in which the contracting parties come from different countries. The contracting parties will find answers to all non-contractual questions in the legal regulations and case law of the respective country. There is usually the problem that a contracting party with stronger bargaining power will insist on the law applicable to be the law of the country from which the contracting party comes. When there is an escalation of disagreement between the contracting parties, the contractor who has accepted the applicable law of the other contracting party will be in a much more difficult position.
Upon weighing all the technical and legal aspects, the contracting parties come to a final decision on whether to continue their cooperation or the termination of the agreement is inevitable. If this is the case, the agreement needs to be completely updated following the new negotiations. If the commercial decision is negative, it is possible to terminate the agreement in whole or partially.
The first question to ask is whether there are any parts of the contract that are worth saving.
Partial termination generally comes down to whether responsibilities in the project can be separated at all. In complex contractual relationships, the key question will be whether, from the beginning, the contractual structure has been adjusted to allow for a partial termination. If this option has not been sufficiently considered and elaborated on while drafting the Software Development Agreement, there is little chance that it will be possible in practice.
If it is possible for one part of the agreement to endure, what follows is an addendum to the agreement defining which provisions have ceased to apply, followed by the adjustment of the other provisions with particular emphasis on the provisions that were subject of disagreement between the parties, which usually are the terms of payment, deadlines and exclusion and/or limitation of liability
You’ve considered all the options to proceed with the Software Development Agreement, but simply keeping the agreement in effect proves to be a greater burden and/or cost than a reasonable solution. The only solution then is to terminate the agreement. When you make that decision, not only are you not done with the project but are actually at the mere beginning. Just as the agreement (contracting and executing) is a serious and complex process, there now awaits an entirely new (and probably significantly more uneasy) one – termination of the agreement.
This is the time to activate the termination clause that you thought you may not even need. While termination by mutual consent is not a problem, the emphasis should be put on unilateral termination, i.e. the questions of who, when, why, and how can terminate the agreement unilaterally. With the Software Development Agreement, it is often not enough distinction between termination due to contractual breach and termination of the agreement for no particular reason, which can be a major omission if you find yourself in this situation.
Moreover, if you wish to terminate the Software Development Agreement because you consider that the other party has breached the contract, the key provision will be one that defines which breaches are considered the so-called, Material breach. Such a provision will set a scale of severity of breaches – serious breaches or breaches that have a serious effect. If such a provision is precisely defined, it will provide the answer to the question of whether the point of disagreement is a valid reason for termination i.e. you have the right to terminate the agreement.
The next question that arises is whether you will be entitled to claim damages for breach of contract by the other party and whether the amount of such damages is limited.
The answer to this question is provided in the limitation and/or exclusion clauses, which should be an integral part of any Software Development Agreement.
The service provider will often insist on negotiating an upper limit on the value to which the service provider can be held liable for damages, which should be proportionate to the SDA value. The client may be unpleasantly surprised to find that the provider has limited the amount of potential liability for damages to only a fraction of the actual damage suffered by the Client at the time of the escalation.
However, the responsibility for breaching certain provisions of the contract will often have unlimited scope. In the situation when you terminate the contractual cooperation, it will be very important for the client to be able to identify those areas. The liability of the service provider will be unlimited in respect of infringement of intellectual property rights, as the Client wants to protect himself from liability for damages against third parties in an amount unknown and unlimited. Stipulating unlimited liability is also typical with breaches of confidential information and trade secrets, which may include personal data.
All of the above indicates that the Software Development Agreement exit strategy will depend on a number of factors, one of the most significant of which will be the content of the agreement itself. In other words, the final decision will guide you to the mere beginning. That is why we emphasize the importance of the negotiation process and the drafting of contractual provisions in a quality manner, in the absence of which, there is neither a successful partnership nor an easy solution.