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.