Software Development Agreement is Heading for the Rocks…What’s Your Exit Strategy?

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 been able to see eye to eye since the very beginning, which indicates inadequate regulation of all the matters. With the SDA, every provision is crucial, and if not paid sufficient attention, a tiny detail may sow the seed of discord between the parties 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. 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 incorrect, the hard fact that at least 50% of projects fail before the estimated completion date does not come as a surprise.

The biggest hurdle service providers endure are with late or missed payments, when the client attempts 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.

Complications occur even more frequently when the service provider does not execute the project alone but uses subcontractors (known as the “one throat to choke” model). 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 usually last 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 poses quite a challenge to plan the exit strategy from a Software Development Agreement with as little harm as possible to the contracting parties.

single vendor it contract
multi vendor it contract

Making the Right Commercial Decision

Generally speaking, if the relationship between the contracting parties escalate, the parties have the following options:

  • to start with the new negotiations, modify the Software Development Agreement and keep it in effect on the basis of “let’s give it another go”;
  • to break up the business relationship, terminate the Software Development Agreement on the basis of “we’ve tried everything and it’s still not working out”;
  • to partially terminate the Software Development Agreement and continue cooperation on the basis of “there has to be a silver lining”.

Both the technical and legal side 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, change of the project scope, etc. Legal issues refer to how do the agreement and the applicable law handle the issues of the matter.

Question No. 1: Where are We From The Technical Standpoint?

To come up with a final decision, the technical level of the services performed by that point has to be determined. The classic questions that a client will wish to know the answers are:

  • What stage are we in? For example, are we in the stage of designing the project architecture, development and design stage, testing stage, deployment stage, etc?
  • How late are we? How much of the project has to be reduced in order to meet the contractual deadline?
  • Is it more important to maintain the scope of the project or to meet the deadline?
  • Is the service provider able to complete the project? Does the system design allow for a new provider to be hired in a short deadline?
  • How much will the additional investment total?

A special problem may arise when the client estimates that the service provider is not technically able to complete the project, but the project is currently in 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.

Question No. 2: What is Stipulated in the Software Development Agreement?

software development agreement, software development contract

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. The following question is whether the service provider now must complete the project at no additional cost incurred to the client or does the client have to pay an increased fee for the changes 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:

1. Checkpoints

Provisions that enable checking whether the execution of the agreement is consistent throughout its duration and that 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 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.

2. Change Control Procedure

Almost every IT project involves changing certain elements, both technical and legal, so anticipating change control procedures is vital. 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, as well as to hold the parties accountable for the duration of the agreement, to determine anything that may affect the legal stance.

3. Right to Hire a New Service Provider

If you are a client, you will wish to have contracted the option of introducing an additional service provider to your software development project. Clients are often advised not to outsource the entire project to just one service provider due to a 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 moves to a stronger bargaining position, especially in terms of price.

4. Exit Strategy and Transfer

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 does the current service provider have to assist in such a transition? Depending on how intellectual property rights are regulated, whether 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 divorce on their wedding day.

5. Intellectual Property Rights

When making the final legal decision as to whether the Software Development Agreement will endure, 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), there is no possibility of replacement 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 pose quite 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 can 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 in their previous projects, and how to separate the intellectual property rights that the provider already holds (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.

6. What is the Applicable Law?

Unless the agreement clearly defines how to resolve any eventual disputes between the contracting parties, the contracting parties will need to seek 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 from. When there is an escalation in relations 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.

Commercial Decision

it outsourcing contract, it outsourcing agreement

Upon weighing all the technical and legal aspects, the contracting parties come to a final decision whether to continue to work together. 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.

A. Partial Termination – Not All is Doom and Gloom

outsourcing contract, outsourcing agreement

The first question to ask is whether there are parts of the contractual relationship 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 when drafting the Software Development Agreement, there is little chance that it will be put into practice.

If it is possible for one part of the agreement to endure, what follows is an addendum to the agreement and defining which provisions have ceased to apply, followed by the adjustment of the other provisions with particular emphasis on the provisions on the terms of payment, deadlines and exclusion and / or limitation of liability

B. Breakup – Because We’ve Tried it all and It’s Not Working Out

software development agreement

You’ve weighed in 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 but are actually at the mere beginning. Just as the agreement (contracting and executing) is a serious process, there now awaits an entirely new (and probably significantly more uneasy) process – termination of the agreement.

This is the time to activate the termination clause that you thought you might 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 difficult to distinguish 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 believe that the other party has breached the contract, the key provision will be one that defines which breaches are considered as 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 you have the right to terminate the agreement with the other party.

software development contract 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 there is a limit to the amount of that damages.

The answer to this question is provided in the limitation and/or exclusion clauses, which should form 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 responsibilities for defaulting certain contractual obligations will often have an 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 breach of confidential information and trade secret, 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 it is impossible to stress enough the importance of the negotiation process and the drafting contractual provisions in a quality manner, in the absence of which, there is neither a successful partnership nor an easy solution.

NEWSLETTER

NEWSLETTER

CONTACT

CONTACT