Although there are many aspects to consider when drafting software development contracts, I have decided to draft my top 5 as they are the critical aspects that I have seen developers to overlook or not properly address in their development contracts. These tips are therefore by no means exhaustive list.
Scope of Works
It is essential to have the scope of works properly described before development commences. In software development contracts, the scope of works usually attaches to a schedule to the contract itself – and the contract imports that as part of the contract. Without a proper scope of works completed there is risk of significant project creep.
It is in some cases it is – but in others it’s not. For example, the vast number of software developers use Lean methodology when developing software applications. Therefore, the exact scope in many projects cannot be identified from the outset.
Which brings me conveniently to the next point, below.
However, if your company is completing the scope of works, you should describe how the scope of works will be carried out. For example, if you are using Lean Software Development methodology you should identify whether you are using Scrum, Extreme Programming or Kanban.
Given that many software developers follow Lean methodology – build, measure, learn – the project scope is meant to change through iterations. I mean, we’re not building a house here, were building software. Because developers often create a prototype, get some feedback, change the specs, create version 1 of the software, get more feedback and iterate some more, it is often difficult in the real world to draft the exact specs right away.
That is why it is critical to build the methodology that is being used into the software development contract – whether it be Kanban, Extreme Programming, Scrum or other means. All of the iterations must be considered and how it is to be carried out. The contract needs to facilitate the interactive approach. There is an art to developing a contract with the development methodology in mind. This is where a lawyer with a technology background (shameless plug) can facilitate an agreement that helps the project move along slowly, rather than a ‘building and construction type’ contract that is fixed and archaic.
Having the right clauses in place for assignment of IP is critical. The IP that is being transferred must be properly identified and exactly when it is transferred. Ideally, the intellectual property in the source code should be assigned upon the completion of the contract. Software developers should be aware that if the client is drafting the contract, savvy technology lawyers will draft the contract so intellectual property passes to the client upon its creation.
Further, there is more intellectual property than just source code that may need to be assigned. If your company is creating graphics, videos or animations those artistic works should be identified in the software development contract. In fact, you also should decide whether the scope of works document itself also vests in the clients.
Once you identify the intellectual property that is to be assigned, you must determine when it is to be assigned. Most companies assign the copyright upon final payment, while some software companies require a certificate of assignment. as well as payment, before IP assigns to the client.
Software development contracts that are prepared by the client, sometimes contain clauses that assign intellectual property, including copyright, upon creation. This can be problematic for software developers, as such clauses could mean that developers must hand over the code (and ownership) before final payment is made.
Drafting indemnities are always a tricky part of negotiating any contract. Although it goes without saying that you need to be indemnified, it is important to know what you want to be indemnified for. For example, if the client insists on using a third-party software application as part of your software or to integrate into a third-party application into your software, it is important that the client indemnifies you for anything that goes wrong with this software. For example, if the third-party software’s API is not properly documented – or insufficient for the required purposes, then indemnities must be drafted to protect your company from things outside of your control such as the operation or availability of third-party services or software.
Other important areas of indemnification include for data loss, delay due to contract variations and more.
While were on the topic of indemnities, and if the client is drafting the contract, be sure to check that it doesn’t bind the directors to the contract in their personal name. Client-drafted software development contracts often bind the directors personally, by including the director in the definition of “Contractor” or otherwise nominating them as a ‘key person’ in the contract, which holds significant personal responsibilities. That is a significant issue that could put you and your personal assets at risk.
It is a pipe dream of some clients who want to restrain software developers from working for competitors. This happens, for a period perhaps if the developers have a 5 year contract with a large mining company, for example. However, being restrained from working on a particular type of software or within a specific industry, is not realistic.
However, restraints can be put in place to prevent clients from poaching coveted coders from the developer’s team. Therefore, it is important to put restraints in development contracts so the hardworking devs don’t get seduced by offers of a cushy job in the client’s head office. It makes for an awkward situation that you must avoid.
It goes without saying that you should also limit client contact with the devs. All communications are to go through the project lead. That’s a rule.