DACB's technology lawyers support their clients from a wide range of sectors with complex tech sourcing deals. In this two part series, Aneeqa Kisil explores some of the major issues in IT contracts for buyers and suppliers recently encountered by the DACB team. This first article explores three key considerations for customers throughout the project lifecycle.
The beginning: customer requirements and obligations
A technology customer ought to be able to rely on its chosen supplier's expertise and professionalism. However, successful technology contracts usually require significant efforts on the customer side as well, commencing with the outlining of customer requirements prior to entering into an agreement and continuing on through the project with the provision of testing and feedback. Whilst customer involvement is even more important when an iterative agile development methodology is followed (and a traditional detailed specification cannot be drafted at the outset), the case of Anglo Group Plc v Winther Browne & Co Ltd  All ER (D) 294 sets out a cautionary tale for customers in the purchase of commercial off the shelf software. One paragraph of the late HHJ Toulmin CMG QC's judgment makes clear that all contracts for standard software packages include an implied term requiring the customer to:
- clearly communicate any special needs to the supplier;
- make reasonable efforts to ensure that the supplier understands those needs;
- spend time and patience in working out how to use the technology; and
- work with the supplier to resolve any issues that arise.
The judgment went against the customer as it had failed to co-operate actively with the supplier, including failing to provide any proof of its special needs or to accept reasonable workarounds proposed by the supplier.
The middle: the change control procedure
Changes in scope/function are inescapable in technology projects, resulting from changes in customer requirements, improvements to supplier services or unforeseen delays on either side. The inclusion of a contractual change control procedure endeavours to ensure that such changes are agreed in a way that is contractually binding and clear.
Change control provisions need to be well considered to enable the parties to put these into operation easily and efficiently where required; overly complex, lengthy processes mean that the parties might side-step the provisions altogether, relying instead on informal and undocumented approaches to more quickly forge a way forward. From the customer perspective, failure to use the contractual change control procedure leads to a risk the change will not be recorded accurately and so not meet customer requirements, potentially leading to significant additional spend and delay.
Careful consideration needs to be given to the usability of the change control procedure including the setting of appropriate 'thresholds'; as there are likely to be categories of dynamic change which can be pre-empted and minor change which can be dealt with quickly with a 'fast-track' approval process. Again, from the customer side, if the contract can be clear that certain minor requests are not chargeable this will minimise unexpected costs considerably.
The end: exit plans
At the outset of a contract, where a productive relationship between the parties may be envisaged for several years hence, it can be tempting to ignore the drafting of exit provisions or rely on vaguely drafted agreements to agree, with a supplier required to provide 'reasonable assistance' or similar. However, from a customer's point of view, once a contract has ended it will usually no longer have the right to use the supplier's software or materials without an express licence provision stating this. There is also no obligation for a supplier to provide transition services upon termination or expiry of an agreement unless these are drafted in.
Therefore, it is imperative that the customer gives serious thought to what it is likely to require following exit. As well as the need for licences to 'background' (pre-existing) intellectual property rights that are owned by the supplier, special consideration needs to be given to on-going supplier 'foreground' (created during the project) intellectual property rights licences; or extortionate fees or the threat of an infringement claim may result.
Even if the customer is happy to cease use of the supplier's software, thought needs to be given to the extraction and provision of customer data from a supplier system to the customer in a useable format. Suppliers are usually willing to give this transition assistance support, but will expect to be paid: our recommendation is that costs are agreed at the outset of a contract in accordance with the supplier's standard rate card.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.