Software development agreements: key points for developers
Winning a tender, or being selected, to develop a new piece of software for a client is a great boost for any software developer. You’ll no doubt have a standard method of project planning for sizable software development projects, from scoping, risk identification, change management to timeline development and final testing.
In planning the project however there is one step that is sometimes overlooked or may be rushed through and that’s getting a properly drawn up software development agreement in place, before any work commences.
The
software development agreement should:
- Define the development project
- Identify the responsibilities of both client and developer to achieve completion
- Manage client expectations
- Identify and manage risks and liability
The company commissioning the software will be investing a great deal, not only in terms of the time and money they will need to allocate to the project, but also in terms of the hopes they will have for the positive impact the software can have on their business. We all know that sometimes client expectations can be unreasonable, so the only real way to protect your interests is to have a properly drawn up agreement.
It is in the interests of both developer and client for the agreement to be fairly balanced to help the project run smoothly, but there are certain issues that a developer must cover in the development agreement.
1. Specification(s)
Whether the software development relates to a new piece of software or modification of existing software, the agreement should specify precisely, and in sufficient detail, what the project is to produce. This is important to identify the developer’s role and will go a long way towards reducing the scope for later disputes. The developer must obviously understand what the client wants the software to achieve in its business. The client may well have produced a specification setting out its business requirements for the software that it wants developing - that may be in outline or contain considerable detail.
In all but simple cases, it is preferable for the developer to prepare a technical specification as to how the client’s requirements are to be achieved. The technical specification should be accepted by the client and form part of the development agreement. The client will generally expect the developer to give warranties as to the performance of the software (see 7. Warranties below). The developer will be more comfortable in giving appropriate warranties about the software judged on its technical criteria and the developer’s performance can be more objectively measured against specific technical criteria for the software than against business requirements. The technical specification therefore fulfils several functions in that it can help in defining the developer’s obligations, managing the client’s expectations and risk management in terms of reducing potential areas of dispute.
2. Project plan
The agreement would preferably include a plan for implementation of the software development setting out the development stages with realistic timescales attached. The initial proposal or tender documentation may have contained such a plan. If so, that should be reviewed and included separately in the agreement with any necessary amendments. Although many of the deadlines will apply to the developer, there will be some deadlines for the client to meet including acceptance at various stages of the development. There may also be actions which the client needs to take on which the developer’s ability to perform may depend such as providing certain facilities, equipment or information. The developer will want to know that it has some leverage if the client does not perform such obligations on time as delay on one project may well have a knock on effect on the developer’s performance in other projects.
3. Client’s obligations
Matters to which the developer would expect the client to attend need to be set out together with any consequences of delay or failure to do so e.g. extensions of time for the developer. These might include such matters as providing information or facilities, making appropriate personnel available to liaise with the developer, acquiring and preparing any relevant equipment, ancillary software etc. ready for the installation and testing of the software being developed.
4. Change control
A procedure to control and manage changes to the agreed project is essential in any software development agreement. Otherwise changes may be agreed informally between the developer and client staff working on the project without being properly documented, rather than being approved at the appropriate levels within each business. Without a proper change control process changes can cause project costs to escalate and delay completion. Changes which are not properly managed are also a notorious cause of disputes.
5. Acceptance procedure
When the software has been developed, it would benefit both developer and client to be able to confirm that it meets the agreed requirements. This is typically measured by acceptance testing. The acceptance tests are usually drawn up and run by the developer, but the client may want to be involved in the testing rather than just receive the results. The agreement should also set out how acceptance can be assumed if the agreed standards are met, so that if the client declines to be involved or claims that the software does not meet the required standards the developer has an objective way of completing the project.
6. Pricing
Software development may be done on a fixed price basis, on a time and materials basis or some combination of these methods. Some mutually acceptable basis will need to be agreed and documented in the agreement. In many projects the developer is likely to want payment in instalments rather than waiting until the development has been completed before receiving any payment. The agreement should set out the basis and timing of the instalments. Where instalments are linked to completion of stages of development, clear criteria should be specified to avoid any disagreement as to whether a payment is due.
7. Warranties
The client will expect some assurance in the agreement about the quality of the software being developed. It would generally be unreasonable for a supplier to refuse to give any such assurances – commonly referred to as warranties – and a complete exclusion is likely to be invalid, but any warranties will need to be carefully drawn from the developer’s point of view to make sure they are appropriate. A carefully drawn specification in conjunction with a project plan, change control procedure and other appropriate detail will all help in defining the scope of any warranties given.
8. Limitation of liability
The developer will want to limit its liability for breaches of the agreement and its warranties in relation to the development. The limitation has to be framed in a legally acceptable way, (as a complete exclusion of liability is highly unlikely to be valid). The issue from the developer’s point of view is to achieve a balance between what is likely to be reasonable and acceptable in court if challenged by the client against accepting a level of liability with which the developer is comfortable. Limitation of liability is a difficult area. Software development contracts have given rise to many of the cases on limitation of liability which have come before the courts in recent years, so it is an area where the developer should give careful consideration and take appropriate advice.
9. Rights in the software
The client often takes the view that because they are paying for the software development it ought to own all the rights to it. That will not usually be either legally possible or acceptable to the software developer. It is unlikely that the whole of the software will be written just for the client – the developer is likely to use a combination of elements including modules that the developer has written previously or adapted from such modules, third party materials and some developed expressly for the client but which the developer may then want to use as the basis for future work. The developer can only pass to the client such rights as it itself has and should only do that to the extent it does not want to use such rights again in future. Rights granted to the client must be carefully drafted to protect the developer whilst allowing the client to use the software to the agreed level. If third party software is needed to use the software developed under the agreement, the agreement should make it clear that the relevant licences must be obtained and whose responsibility it is to do so.
10. Additional services
If the developer is providing other services in relation to the software development, such as training, the scope of that obligation should be set out. If there will be ongoing services such as updating, maintenance or support it may be preferable for those to be covered by a separate agreement or agreements which can be attached to the main development agreement.
Getting expert advice
This article can give only an indication of some of the main issues to be addressed in relation to software development agreements and can only deal with these in a general way. Software development is a complex technical area and gives rise to many legal issues. It is important to consider these carefully to avoid problems arising in relation to the project.
For advice in relation to software development agreements please contact Sue Mann.
Article added: 6 June 2012 © Cousins Business Law
This article is not intended to constitute legal advice, nor is it intended to be a complete and authoritative statement of the law, and what we say might be out of date by the time you read it. You should always seek legal advice to confirm whether or how any information in this article applies to your particular situation. We offer a free telephone consultation to discuss your particular circumstances.
For more articles and advice subscribe to the Cousins Business Law ezine here