By Duncan McCall and Benjamin Pilling

The Problem

There is probably no single aspect of IT projects that creates more confusion, disputes, and ultimately litigation, than the question of contractual time for performance.

From a customer's point of view, if a project runs into delay, dare it cut its losses by terminating the project prior to completion? Or, by doing so, would it risk putting itself into breach of contract with consequential exposure to liability for outstanding fees and loss of profit?

From a supplier's point of view, does failure by a customer to provide essential information at a contractual milestone justify the supplier withdrawing from the project? Or, if the supplier's own performance is delayed by reason of a lack of co-operation on the part of the customer, who is responsible when the final date for delivery is not met?

The Principles

The time for performance of a party's contractual obligations in an IT contract may be defined in a wide variety of ways. Examples include:

  • At one extreme a party may be required to have performed all its obligations by a date prescribed in the contract. In some contracts this will be the full extent of the party's obligation. In others, the party may also be under an obligation to proceed "regularly and diligently" with its work towards the date for completion.
  • A party may be required to fulfil its obligations in stages or by milestones.
  • The time for performance of a party's obligations may be contingent upon some event, such as the provision by another party of certain information or equipment.
  • At another extreme, a contract may not make any provision for a date for final completion, perhaps because the customer's requirements are still not adequately defined.

In analysing any of these scenarios, the starting point is usually to consider whether time for performance of one or more of the obligations under the contract is "of the essence". Where time for the performance of a contractual obligation is of the essence and a party fails to perform that obligation by the due date, the other party has three options:

  1. It can accept the failure as a repudiation, thereby bringing the contract to an end. That party will usually be entitled to recover its losses, often in the form of wasted expenditure.
  2. It can grant an extension of time for performance, imposing a new date for performance, which will generally be of the essence (Buckland v Farmar & Moody1). Any right to recover damages for losses caused by the delay may be preserved.
  3. It can elect to continue with the contract without imposing any new date for performance, in which case performance must be within a reasonable time, pursuant to section 29(3) of the Sale of Goods Act 1979. As with the previous option, any right to recover damages for losses caused by the delay may be preserved. If a party chooses this option, it may subsequently give reasonable notice of a date for performance, making time of the essence again (Charles RickardsLtd v Oppenhaim2).

A simple failure to perform by a specified date which is not of the essence, although a breach of contract, does not entitle the other party to treat the contract as repudiated. However, a failure to perform within a reasonable time may, depending on the construction of the contract, amount to a repudiation (Thomas Borthwick (Glasgow) Ltd v Bunge & Co Ltd3).

Where the contract does not expressly, or by necessary implication, fix any time for the performance of a contractual obligation, the law usually implies that it shall be performed within a reasonable time. In Hick v Raymond4 Lord Watson remarked of this rule that it "is of general application and not confined to the carriage of goods by sea. In the case of other contracts the condition of reasonable time has been frequently interpreted, and has invariably been held to mean that the party upon whom it is incumbent duly fulfils his obligation, notwithstanding protracted delay, so long as such delay is attributable to causes beyond his control, and he has neither acted negligently or unreasonably".

The key issue is thus whether time is of the essence. Historically, the courts of law and equity took different approaches to this question. In the absence of express agreement to the contrary, the courts of law generally regarded stipulations as to time in a contract as conditions, breach of which would entitle the innocent party to terminate the contract (Metcalfe v Fowler5). By contrast, the courts of equity would generally give relief against forfeiture for failure to comply strictly with time limits (Tilley v Thomas6). The courts of equity made exceptions, however, which included:

  • cases where the parties expressly agreed that time should be of the essence;
  • cases where it was apparent from the circumstances of the contract that time was intended to be of the essence; and
  • mercantile contracts (Reuter v Sala7).

Upon the fusion of law and equity, the effect of section 25(7) of the Judicature Act 1873 (now replaced by section 41 of the Law of Property Act 1925) was to preserve the position which had obtained prior to the Act. Thus mercantile contracts remained amongst the exceptions to the general rule that time was not of the essence. The justification for making an exception for mercantile contracts was explained by Lord Lowry in Bunge Corp v Tradex Export SA8:

"The treatment of time limits in mercantile contracts does not appear to be justifiable by any presumption of fact or rule of law, but rather to be a practical expedient founded on and dictated by the experience of businessmen".

In other words, business people need commercial certainty, which is what can be achieved by making time of the essence for the performance of contractual obligations. As we shall see, however, law developed in the context of commercial contracts for the sale of commodities (often a one-off delivery or a series of scheduled deliveries of the commodity) does not always fit happily into the more complicated world of IT projects.

Application To IT Contracts

(1) Recognising Whether Time Is Of The Essence

Most IT contracts differ fundamentally from commodities contracts. IT contracts do often involve an element of sale of goods, whether it be hardware or software. But they frequently also involve the provision of services relating to design, development or implementation. Unlike commodities contracts, IT contracts are often project orientated and will require a supplier to co-operate not only with the customer, but with other parties, including other suppliers and consultants.

Thus, while there are some similarities between IT contracts and commodities contracts, there is no justification for assuming that the general principle that time is of the essence in mercantile contracts should be extended to IT contracts. Many IT contracts bear much closer resemblance to construction contracts where, as general rule, stipulations as to time are not regarded as of the essence (Lucas v Godwin9). In our view, the proper approach to IT contracts is to scrutinise the contracts as a whole and to determine, in respect of each disputed obligation, whether the timely performance of the obligation was of the essence of the contract.

The parties are free to agree that time should be of the essence and to express this agreement in the written terms of the contract. Where, however, the language of a contract indicates that the dates or periods set out in it are merely the parties' best estimates at the stage of entering into the contract, this may be a good reason for the Court to hold that time was not intended to be of the essence.

Other clauses in the contract may lead the Court to the conclusion that time is or is not of the essence. In The Salvage Association v CAP Financial Services Ltd10 it was held that a clause which provided for the extension of time of dates quoted for delivery and completion of any stage of the contract, where the delay was caused by the act or omission of the customer or by causes beyond the control of the contractor, supported and confirmed the view that time was of the essence. Such a clause would simply not be necessary if time for performance was not a condition of the contract.

Liquidated damages clauses are frequently deployed in argument in relation to the question whether time is of the essence. The cases suggest that there is no general rule as to the significance of such clauses. In Lamprell v Billericay Union11 the Court was persuaded that the presence of such a clause indicated that time for completion of the works was not of the essence; but in Pacific Ocean Shipping Corp v Sembawang Corp Ltd12 the Court held that there was nothing inconsistent between a liquidated damages provision and a contractual right to terminate for lack of resources based on anticipated failure to complete the contract in accordance with its terms. Tuckey J commented "If they keep it alive the liquidated damages provision quantifies the loss which they can recover; if they terminate the liquidated damages provision is irrelevant". (Pacific Ocean is probably a case which turned on the unusual wording of the contract in question).

It is not always a simple matter in an IT contract to identify the date for the performance of a particular obligation. In a contract for the delivery and installation of hardware and package software this will often be simple, because a date for delivery of the hardware and for access for cabling is usually agreed, and the software is usually pre-installed on the hardware. Problems tend to arise where the contract involves the provision of a mixture of goods and services, some of which are affected by, or even contingent upon, obligations to be performed by the customer. Such contracts may include the following elements, all of which may have a separate time for performance:

  • The development of a detailed functional specification after the contract has been signed.
  • The development of bespoke software, or the tailoring of COTS software.
  • Project management or other consultancy services.
  • Implementation services.
  • Training.
  • Data conversion.

A contract may provide for dates for performance of some or all of these obligations, but the nature of the obligations is such that their performance is often dependent on the co-operation of, or provision of information by, the customer. This dependency may be exacerbated when the initial definition of the customer's requirements is vague or incomplete, where the customer's own IT department is jointly responsible for implementation, or where the contract suffers from "specification creep".

In many contracts the prescribed dates for performance simply become unachievable for reasons which are not the fault of the supplier. In such circumstances, the supplier's obligation may be converted from a date specific obligation to performance within a reasonable time. The determination of what amounts to a reasonable time in IT contracts is a peculiarly difficult exercise and will depend in large measure upon expert evidence.

The Courts have identified the unique nature of IT contracts, and the co-operation which is required between customer and supplier if a project is to be successful. In the recent case of Anglo Group plc v Winther Brown & Co Ltd & BML (Office Computers) Ltd13 HHJ Toulmin CMG QC commented that "it is well understood that the design and installation of a computer system requires the active co-operation of both parties". He went on to identify six implied terms which were to be found in a contract for the supply of a "standard computer system".

  1. The purchaser must communicate clearly any special needs to the supplier.
  2. The purchaser must take reasonable steps to ensure that the supplier understands those needs.
  3. The supplier must communicate to the purchase whether or not those precise needs can be met. If they cannot be met precisely, the appropriate options should be set out by the supplier.
  4. The supplier must take reasonable steps to ensure that the purchaser is trained in how to use the system.
  5. The purchaser must devote reasonable time and patience to understanding how to operate the system.
  6. The purchaser and supplier must work together to resolve the problems which will almost certainly occur. This requires active co-operation from both parties.

The first, second, fifth and sixth of these terms all have the potential to affect the time for performance of a supplier's obligations, because they place obligations on the customer the performance of which will facilitate the performance by the supplier of its obligations. Indeed, it may be argued that the existence of such terms have a more fundamental importance, in that they militate against a conclusion that time for performance of the obligations in the contract is of the essence. The greater the degree to which the supplier is dependent on the customer in order to fulfil its obligations, the less appropriate and less practical it would be for time to be of the essence.

(2) The 11th Hour Argument

Often, the purchaser of new computer hardware and software will wish the new system to be delivered, installed and commissioned in time for a specific event such as a relocation, a restructuring, the commencement date of new legislation, or the introduction of a new production process. In such cases, the contract will require different elements of the system to be delivered at various stages of the project leading to a final date by which the system is to be up and running. It is open to a supplier to argue that the elements of the system which are to be delivered before the final date for completion merely represent the ongoing development of the whole system, and are not required to be bug free, and that the supplier's obligation to perform does not crystallise until the final date for delivery. The same argument may arise in a case where the purchaser rejects a system because of faults or delay during the development phase but prior to the date for final delivery.

In St Albans City and District Council v International Computers Ltd14 the Council required a system which would enable it to fix the community charge figures by the end of February 1990, prior to the commencement of the community charge legislation on 1 April 1990. One item which was to be delivered well in advance of February 1990 was software designed to create a register of charge-payers. The Council used this software in December 1989 to provide population figures on which it then based the community charge rates. The software was faulty, which caused the population figures to be overstated and caused the community charge to be set too low, leading to a loss for the Council.

In the Court of Appeal the supplier argued that because the supplier's obligation was to provide a fully functioning system by the end of February 1990, the parties had recognised that prior to that date the system was in a state of development, and, in the absence of negligence, the Council had impliedly agreed to accept the software bugs and all. The Court of Appeal rejected this argument. Nourse LJ stated:

"Parties who respectively agree to supply and acquire a system recognising that it is still in the course of development cannot be taken, merely by virtue of that recognition, to intend that the supplier shall be at liberty to supply software which cannot perform the function expected of it at the stage of the development at which it is supplied".

However in other cases such an argument has been more successful. In Saphena Computing Ltd v Allied Collection Agencies Ltd15 Staughton LJ commented:

"… it is important to remember that software is not necessarily a commodity which is handed over or delivered once and for all at one time. It may well have to be tested and modified as necessary. It would not be a breach of contract at all to deliver software in the first instance with a defect in it … software is not a commodity which is delivered once, only once, and once and for all, but which will necessarily be accompanied by a degree of testing and modification. Naturally it could be expected that the supplier will carry out those tasks. He should have both the right and the duty to do so …".

St Albans was clearly a special case because the Council needed to start using the software prior to completion of the entire contract. In many complex IT cases, however, there seems to be more scope for applying the approach taken by Staughton LJ, because it reflects the realities of software development and system implementation. It is also reflective of the approach taken by the Court in the Anglo Group case.

(3) Milestones

Many IT contracts are structured around a series of "milestones" by which certain obligations must be fulfilled. Milestones are particularly common in large IT contracts, as they provide evidence of progress in an area where progress may otherwise be very difficult to measure. In some contracts, each milestone will carry with it a separate liquidated damages clause and the provision for an extension of time relating solely to that particular portion of the contract works. Milestones are often of particular significance to the supplier, because they trigger payment.

There is, in our view, no basis for arguing that there should be any general principle as to whether the obligation to reach a milestone in accordance with the contractual timetable should, or should not, be of the essence. The significance of milestones will vary from contract to contract and even within a single contract. Some milestones will be on the critical path, others will not. Some milestones will involve completion of substantial phases of projects, others will involve delivery of relatively trivial and non time critical items. In most cases, the subject matter of the milestone will not be of a wasting nature, or liable to great fluctuations in value. In some cases, like the St Albans case, the customer will intend to use the goods and services delivered by a milestone prior to the final completion date. In other cases, whether or not the contractor achieves a particular milestone on time will have no practical implications for the client.

It is likely that, in the absence of express provision as to the status of an obligation to achieve a milestone, the courts will treat such terms as innominate terms, and the customer's remedies arising from failure to achieve the milestone will depend on the nature and severity of the breach.

Conclusion

Time for performance in an IT project is of enormous commercial importance for both customer and supplier. The historical body of authority which makes up the core of English case law in this area arose principally in the context of commodities contracts and is not well suited to accommodate the particular problems which arise in IT projects. A more natural analogy lies with construction contracts (in which stipulations as to time are not generally regarded as being of the essence) because of their project based nature and the need for a co-operative relationship between the parties. Gradually a body of authority on the issue of time for performance is emerging which is specific to IT cases and in which the Courts are showing a willingness to recognise and reflect the unique problems which arise in IT projects.

Footnotes

1[1979] 1 WLR 221

2[1950] 1 KB 616

3[1969] 1 Lloyd’s Rep 17, 28

4[1893] AC 22, 32

5 (1840) 6 M&W 830, 10 LJ Ex 84

6 (1867) 3 Ch App 61, 67, 17 LT 442, per Lord Cairns LC

7 (1879) 4 CPD 239, 48 LJQB 49, CA

8 [1981] 1 WLR 711

9 (1837) 3 Bing. N.C. 737, 744

10 [1995] FSR 654

11 (1849) 3 Ex. 283, 308.

12 (1998) New Law 2980913705, Commercial Court

13 (2000) 72 Con LR 118, 142, TCC

14 [1995] FSR 686, [1997] FSR 251 CA

15 [1995] FSR 616, 652

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.