John Warchus, IT and e-commerce partner with law firm Shadbolt & Co, explains how to guard against being caught short if your IT system fails
Construction organisations are facing IT projects of increasing size and complexity. This complexity means there is a real possibility of projects failing, paralysing the organisation and threatening commercial loss running to millions of pounds. Some simple steps can reduce this risk.

Precontract issues – the tender process: As with any technology service, it is important for the user organisation to carry out thorough initial planning, taking into account the views of end users. Focus on your firm's key requirements, make site visits and check client references given by suppliers. As part of the overall evaluation process, it is advisable to negotiate an initial trial period and/or a precontract benchmarking exercise to establish technical performance levels. Where there is a need for customisation or integration with your existing applications, require the potential supplier to demonstrate project management and development expertise – take nothing on trust!

Subject to contract
The contract: In light of recent judgements, it is important to keep in mind what constitutes a binding contract. Remember that a binding contract exists when all the essential terms have been agreed and that it is therefore important that a formula such as "subject to contract" (or equivalent) is used in negotiations. In addition, any important precontract statements or representations on which the user is relying need to be expressly repeated in the contract, because there will normally be an "entire agreement" clause that would otherwise prevent reliance on statements made by the supplier's sales team. After all, it is not the sales team that will have to implement a working system!

Limiting liability: The issue of liability limitation is particularly relevant to IT supply contracts because in the case of defective performance, the financial losses to the user could be even larger than wasted contract payments to the supplier. The IT supplier will be keen to limit its liability for both direct and indirect/consequential damages by an express clause. The validity and enforceability of a standard limitation clause is controlled by statute (The Unfair Contract Terms Act 1977, UCTA), which has been interpreted in a number of cases. Until recently, users were able to draw some comfort from the fact that attempts to limit the supplier's liability for direct losses to sums significantly less than the value of the contract were usually held by the courts to be unreasonable and invalid. The latest decision on limitation clauses in an IT supply contract, Watford Electronics v Sanderson, however, saw the Court of Appeal uphold a limitation clause and take a generally robust view as to when commercial parties will be seen as having "equal bargaining power", one of the important factors in deciding whether a limitation clause will be upheld. Users negotiating such clauses will therefore not be able to assume that a limitation clause is likely to be rejected by the courts in any later litigation; you should check that the clause is commercially acceptable.

The user must require the potential supplier to demonstrate project management and development expertise - take nothing on trust!

As UCTA only applies to standard terms of business, any negotiated limitation clause should be handled very carefully, because these clauses cannot be challenged under UCTA. Whatever is agreed between the parties will almost certainly be enforceable, significantly reducing the user's remedies.

Obligations
Service levels: You should ensure that there are sufficient guarantees of all important performance levels and/or functionality and that such obligations can be objectively measured. These obligations should be supported by express remedies in the event of breach. It is also essential to have an express right to terminate the contract in the event of serious breach by the IT supplier in performing the agreement, or in the event of major system failures after completion.