Gajus - Fotolia

Get your contract right at the start

With a recent spate of courtroom IT battles, it is worth taking a step back and asking how expensive and distracting litigation can be avoided. The answer often lies at the very beginning of the project, when initial contracts were drawn up

With a recent spate of courtroom IT battles, including WH Smith suing Fujitsu Seimens for £4.5m, it is worth taking a step back and asking how expensive and distracting litigation can be avoided.

The answer often lies at the very beginning of the project, when initial contracts were drawn up.

For an IT contract to work the project teams and the legal advisers for each party must work closely together to ensure that it corresponds with the project's method.

Some require the contract to describe deliverables and functionality in detail. This applies where the method involves the delivery of an application or infrastructure in one piece after lengthy and distinct planning, design and delivery stages - often dubbed a waterfall method.

Dynamic systems development method (DSDM) projects are much more flexible and deliverables will be supplied incrementally. It is essential these differences are reflected in the contract.

Robust procedures to accommodate changes that inevitably occur during a project must be set up. Some changes may be agreed orally and recorded in minutes of meetings while major changes will be made in writing.

Once again, the method will determine how changes are made. For instance, in a DSDM contract many important decisions will inevitably be made during the course of the project which cannot be defined at the start. The contract must allow for this.

Just as the contract cannot be divorced from the project, so the project cannot be divorced from the internal workings of the respective parties. Both users and suppliers must develop good internal procedures. For instance, both parties' IT staff must know the level of their authority and understand that their decisions and representations can be contractually binding.

Acceptance of the final project also varies according to method. In waterfall projects, testing and acceptance will take place at the end of the project.

In a DSDM contract only the "must haves" and most of the "should haves" contained within a time box will be working satisfactorily. The contract will need to recognise this difference.

Whatever method is used, there is a legal duty on the part of the customer to co-operate with the supplier in resolving difficulties. Users cannot just sit back and wait for the supplier to deliver.

Limitation of liability clauses need to be drafted carefully as the courts will exclude clauses they deem to be unreasonable. To be valid, a limitation of liability needs the input of both parties and the limitation figure should balance the cost to the customer of a system failure with the need of the supplier to limit exposure.

It is common practice for consequential loss to be excluded. But it is often difficult to define what loss is direct and what is indirect or consequential. A simple financial limit of liability leaving out reference to consequential and indirect loss has the advantage of certainty and may be more easily enforced.

Dispute resolution must be addressed in the contract. Although it may seem pessimistic in the build-up to a major project, the contract should anticipate conflict between the parties.

Problems need to be dealt with immediately and cannot wait for a long court process. A contract should provide an escalation procedure to enable problems to be resolved at an early stage. Only in the final analysis should the matter go to arbitration or litigation.

Normally, the supplier will want to retain intellectual property rights. However, the customer may want to ensure that the supplier cannot install an identical system into a competitor. Careful consideration as to how intellectual property is dealt with in the contract will be needed.

A contract is not something that is simply drafted by a lawyer and put in a drawer and forgotten about. It is part and parcel of the management of the project. It helps to manage the relationship of the parties and to facilitate the successful conclusion of the project.

I am not saying drawing up contracts is fun and I know the required legal discussion may take time you would rather spend on other work. But I can guarantee that it is better to get it right from the start than to face the nightmare of a prolonged court battle.

Richard Abbott is a lawyer specialising in IT contracts for Berg & Co, Manchester.

Read more on IT legislation and regulation