Software Development Contracts

This guide is based on UK law.

Overview

Where a business needs bespoke software solutions, the rights and obligations of a software developer and of the business (the software user), will be set out in a software development contract.

There are two approaches to software development which can be known as conventional and prototype approaches.

Under the conventional approach, there will be a detailed specification of what the user requires from the outset. The prototyping approach is more flexible. Although there will still be a specification, it will be less detailed and the user requirements are developed along the way, working with the developer.

This guide discusses the implications for the software development contract arising out of these two rather different approaches.

The contract differences will include those relating to the software user's requirements, change controls, acceptance criteria, project management and charges.

Requirements and change control

It is important to define the user's requirements in the contract. For the conventional approach, this document may well be a long, detailed and definitive statement. It may itself be the subject of a separate contract.

Once the development work is under way, it is inevitable that changes will be required. For a project of any complexity, the software will rarely be implemented as originally specified. A change control procedure will facilitate the steps of suggesting, documenting, pricing and implementing variations, and this should be set out in the contract.

However, where the requirements are not initially well-defined and are being developed through prototyping, the objective for the user can be stated only at a high level, by means of a short concept statement or guide. This too should be identified in the contract. As part of the iterative process, it will be interpreted creatively by the supplier, with the active co-operation of the user. It will be discussed and refined as the work progresses, until both parties agree that the objective has been achieved. Change control procedures are irrelevant because the process assumes constant change.

Acceptance criteria

For conventional development there should always be acceptance testing by the user. The user has to be sure that before final payment, the system or software is performing according to its requirements. Yet to define the tests themselves at the time the contract is made is likely to be impossible. Nevertheless, the formal procedure for acceptance, allowing for repeat testing, and the deadline by which the tests should be completed, ought to be set out in the contract. If the user does not carry out the testing completely or uses the software operationally, then acceptance should be deemed to have taken place, for the supplier to be entitled to payment.

For prototyping, the process of acceptance is ongoing, and implementation will take place when the user is satisfied that it has a useful system which meets its objective.

Project management

It is essential for project management procedures to be agreed and specified in the contract. Prototyping relies heavily on effective project management, because the method of working allows for uncertainty and encourages changes of direction, and this must be managed. For traditional software development, lack of project management is at the heart of many project failures. It is therefore crucial for each party to establish agreed procedures for management and review in the formal contract.

Charges

It is usually difficult to be aware of all the variables in assessing costs accurately at the outset of development. Some conventional development is carried out for a fixed price. As a general principle this is inadvisable, and variations which arise will probably be more highly priced than where the basis for charging is on the time spent. It may be possible to place a cap on the price. Suppliers tend to prefer this latter method, which gives them more certainty for cash flow. This is the normal method of charging used for prototyping contracts.

Estimated pricing is based on time costs, with a margin for error. The supplier will alert the user if the estimated figure is being approached, or if radical changes are made as the application unfolds, causing significant cost increases. The user can then make its decision about more or fewer resources or features and the extent of functionality.

Any questions? Please contact struan.robertson@out-law.com / 0141 249 5422 or one of our other contacts.