Customer’s often have template agreements that they use for purchasing a variety of goods and services. However, suppliers should be careful to ensure the terms are appropriate for the provision of software, which raises a distinctly different set of issues from the purchase of other goods and services.
Specification
Customers want to purchase a usable product that is delivered by a specified end date for an agreed cost and which has a realisable business benefit.
This assumes that the customer can accurately detail what it needs, that the supplier knows what to build to meet those needs and that the solution will produce the business benefit anticipated by the customer. However, these assumptions are often flawed.
The customer might have an idea of what its business requirements are or the function that it wants the software to fulfil but it may not be concerned about how the solution is delivered. Alternatively the supplier may not know how it can meet the requirements of the customer and there may need to be a process of ‘trial and error’ during a development phase.
However, while the specification is not formulaic, suppliers need to make sure that their contractual obligations are carefully linked back to the customer’s requirements in the specification. Otherwise the supplier may find itself liable for the breach of an unintended contractual consequence.
Integration
Furthermore, suppliers should consider how the software will be assimilated into the customers’ existing system and whether it needs to interface with any other computer programs. IT solutions are rarely as straightforward as providing an isolated piece of software. Suppliers need to consider the hardware and operating system on which the software is intended to operate, the networks to which they are to be connected and the sources of the data which they are intended to process.
The contract and pricing should include any development work required by the supplier to ensure the application can be integrated with the existing system and details of the intended environment in which the software will operate.
Consequences for failing to deliver a live or operational solution can be severe so suppliers should ensure that any assumptions on which the operation of the software is based are clearly detailed to avoid any disjoint in the parties expectations.
Acceptance Tests
Acceptance tests are the most common way of monitoring the success of the solution against the agreed requirements in the specification. It is therefore imperative that the acceptance criteria are detailed in the contract so IT businesses and their customers know what criteria the solution must meet as its developed or integrated with the software.
Acceptance tests should be directly linked to the specification as these are the agreed requirements. If a customer has set out how it wants the software to operate in the specification then the acceptance criteria should not be based on the achievement of undefined user requirements.
As payment is often linked to acceptance, you should ensure the customer is not able to delay or prevent the solution passing the acceptance tests which would subsequently delay payment. Make sure tolerances are built in for minor discrepancies which shouldn’t prevent the solution passing the tests, the ability to rectify any errors without a financial penalty and deemed acceptance if the customer unreasonably withholds any confirmation of acceptance.
Customer’s obligations
Delivering complex solutions will inevitably require active involvement from the customer and ‘customer contracts’ often fail to address this. We have already touched on two areas that require customer involvement: detailing the environment and infrastructure on which the application will operate to ensure it can be integrated to the existing system and detailing the acceptance criteria which should be based on the specification.
However, the supplier may also be dependent on the customer (or a third party on the customer’s behalf) providing other information, or perhaps a licence to integrate or use a piece of third party software.
IT businesses and their customers should be careful in using a template contract with a tailored specification for the provision of software. The legal terms should accurately reflect what has been agreed commercially and the two should not be disjointed.
If commercial terms are agreed in isolation of any discussions around the legal terms this can lead to an increase in the price of the project if the risk allocated to the supplier is higher than that originally priced.
