Staying out of Trouble in Software Development and Technology Contracts

Staying out of Trouble

Whether as a buyer or seller of software services, if you have been in the software development industry for any stretch of time you will be well aware that contracts can go wrong for both commercial and legal reasons. Today’s technology services cast a wide net. They not only incorporate software license agreements but also embrace security systems, supply chain management, billing, customer relationship management, communications software and a host of others. Basic principles of contract law apply to all contracts. When products and services vary, so should the contract to deal with them properly. There are a number of areas that should be taken into consideration in each and every contract to avoid problems arising and make the most of the relationship – for both the supplier and customer. But too often these issues are not dealt with adequately or worse, ignored, which leads to uncertainty, disputes and potentially the ultimate failure of an otherwise profitable relationship. Some of the most important, yet often neglected areas come under the following headings.

Defining the Services

Behind price, the most important part of a technology contract will be the services to be performed. System specifications and performance capabilities should be stated clearly and precisely. Ambiguously worded requirements are an open invitation to ‘scope-creep’ and a permit for other uncertainties to be imported, so absolute clarity is needed in defining:

• What services are to be performed?
• When they are to be performed?
• By what means can it be unequivocally stated that the particular contract works should be and are complete?
• When does the supplier become entitled to payment?

Time frames for design, implementation, installation, integration, candidate testing and debugging cycles, beta (“bugs expected to appear”) testing, technical documentation, and user documentation should be catered for, preferably on a timeline. It makes sense to plan the implementation over time, rather than expect an instantaneous and flawless performance at go-live. And to add a context and background to the performance-to-contract, it will assist to name the operating environment, any existing or new hardware, network infrastructure and database management systems involved.

Updating the Services

In outsourcing and procurement contracts, updating technology and service performance on a periodic basis usually makes sense for the introduction of new technologies over the life of the contract. Benchmarking service performance provides an objective basis to assess industry standards over time and sets a reference point for improvements to services. Catering for service improvements helps preserve the relationship, as the customer receives increasing productivity and return on investment. Services provided under a contract otherwise typically deteriorate over time, leading to customer dissatisfaction. In most cases, the customer should be entitled to receive the benefit of improvements to technology over time.  Flexibility should be built into the agreement to vary services where hidden costs arise. Tied in with this concept is the ability for the parties to change the services delivered over time, and setting out a change-control procedure in the contract assists for this purpose.

Poorly Drafted Contracts

The contract should be in plain English, readily understood by commercial people and mindful that verbosity and complexity are usually the enemies of clarity. Properly drawn contracts facilitate commercial negotiation and dramatically reduce legal costs.  Standard contracts dealing with technology products and services should match the nature of the services to be performed. For instance, a software development contract is not suited for delivery of packaged software, and outsourcing agreements are not suited for delivery of special purpose database management systems because the nature of these transactions is completely different. Though it seems obvious that it does not serve the interests of either party to introduce ambiguity in the contract by using a document inappropriate for the purpose, it happens.  Savvy in-house technical staff may be well placed to decide whether the document is suited to the nature of the product or service, if advisors are not competent to make a sound assessment.

Some of the danger with technology contracts arises due to the way contracts are interpreted. Once signed, the actual intentions of the parties in the agreement are largely discarded – the law imputes an objective intention to the parties with the result that the document will be interpreted in law differently from what the parties intended. The paramount need at all times is for clarity, clarity, clarity, in that order.

Intellectual Property

The fact that intellectual property rights are intangible does not prevent them from being dealt with like any other property and so, just as any other asset, they may be traded, sold, licensed, assigned or used as security. Copyrights, database rights and know-how created during the course of a technology contract should be dealt with explicitly to ensure that the party who should own the intellectual property does actually own it, rather than leaving the matter to chance. Getting it wrong may mean that using data requires payment of fees. And remember, consultants and freelancers are the first owner of intellectual property unless an exception applies.

In the case of software development, some provision for open source code should be incorporated, to either exclude its inclusion into the project altogether, or manage its inclusion after vetting the terms upon which the code is made available.  A customer will probably want to include an indemnity that they will be protected if the deliverable infringes a third party’s intellectual property rights. And the supplier would be prudent to exclude their liability where the customer combines their deliverable with another product that infringes a third party’s rights.

Acceptance testing

In software development contracts, acceptance testing should cater for expected peak periods; and warranty periods should commence after acceptance. The customer may wish to obtain a warranty period for free rectification of defects.

Warranties and Indemnities

Warranties are essentially statements by a party as to a state of affairs at the time of the contract. Unless specifically excluded, statutory warranties will form a part of a B2B contract, however, the parties have the option of excluding all warranties other than those set out in the agreement. Although perhaps not an ideal approach, but as a minimum, warranties should be included to the effect that the deliverable is free from errors; is compatible with existing hardware and software infrastructure; and complies with the documentation produced.

Limitations and Exclusions of Liability

These clauses remove or set a cap on the liability of either party in the event of some failure to perform their obligations. Usually both parties will have a legitimate interest in limiting or excluding liability, and the key is to strike a balance between the interests of the supplier and the customer. Inappropriate inclusions or limitations of liability may extinguish a legitimate claim for losses sustained for a breach of contract or through negligence.

Managing People

Depending on the services to be provided and the degree of integration of staff from different companies, management of staff may be key to avoiding the supplier becoming a competitor and having  their entry into the market being funded, in effect, by the contract fees. If the customer wants to avoid this kind of novel surprise, some attempt should be made to maintain exclusivity during and after the agreement has ended by catering for confidentiality of information and know-how, restrictions on competition in the same market and the post-contractual movement of employees, customers, consultants and suppliers. Courts are generally averse to anti-competitive provisions, so such  provisions need to focus on legitimate commercial interests and go no further than necessary.

Exit Management

In the anticipation of entering into a contract, parties often overlook the back-end of the contract and how the parties will close their relationship. There is a good argument that, regardless of how the contract comes to an end, the service provider should assist the customer in a smooth change-over to a new provider. It may be sensible for the service provider to agree to provide its services after termination for a set period for time, either on a time and materials basis or against a payment regime set out in the agreement.

Information Security and Data Protection

Where personal data is moved between parties during the course of a contract, the obligations of either party need to be made clear with respect to the handling of the data and whose responsibility it will be to comply with the Data Protection Act. Providing services online heightens security risks, and a service provider should be in a position to warrant that adequate data protection mechanisms are in place.

Fault Logging and Managing Failure

An imperative in project management and managing liability is to maintain an audit trail. A failure to perform services or define losses sustained cannot be proven without evidence, and genuine claims fail without it. If software is involved, faults logs should describe the fault, its date and time, the program executing, version and release, other memory resident processes running at the time and the error messages generated. It may be in both parties’ interests for a contract to provide that audit logs for processes performed by the system be implemented and regularly archived. Regular backups of data are essential for commercial reasons and provide evidence of liability.

Service Levels

In outsourcing arrangements, where reliance is placed on a third party to perform, business continuity is key. Service levels set standards for response times, system availability and error rectification times. Failures by the provider to adhere to service levels usually result in service level compensation through some measure of credit to the customer for failing to meet these minimum contractual delivery standards. Such a mechanism may add management overhead to the contract, but the alternative of exchanging allegations of breach of contract is far less desirable.

Closing Remarks

I suspect you may have been surprised by some of the areas highlighted, but there are many others. Contracts are living documents that set out and regulate legal relationships and if well drawn up, will benefit both parties. One of the most neglected, yet the critical requirement towards assuring the success of any contract is the balancing of the parties’ responsibilities.  A contract that works is likely to be mindful of the commercial interests of both parties; lopsided agreements, where one party bears the lion’s share of the risk and expense to make the service work should be steered well clear of as they have the greatest propensity to engender recrimination and mistrust. Getting the contract terms and structure correct at the start of the agreement should avoid subsequent business discontinuity - and have the added bonus that your solicitors can then have only have one bite at the cherry.

Leigh Ellis is a specialist information technology and intellectual property solicitor in London. He commenced life as a software engineer after completing an undergraduate degree in computer science. He then completed a Master of Laws, focussing on intellectual property rights in software. He provides legal advice on intellectual property litigation.