Time For Performance in IT Contracts

June 30, 2001

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, bydoing so, would it risk putting itself into breach of contract withconsequential exposure to liability for outstanding fees and loss of profit?


From a supplier’s point of view, does failure by a customer toprovide essential information at a contractual milestone justify the supplierwithdrawing from the project? Or, if the supplier’s own performance is delayedby reason of a lack of co-operation on the part of the customer, who isresponsible when the final date for delivery is not met?


The Principles


The time for performance of a party’s contractual obligationsin 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 isusually to consider whether time for performance of one or more of theobligations under the contract is ‘of the essence’. Where time for theperformance of a contractual obligation is of the essence and a party fails toperform that obligation by the due date, the other party has three options:


1. It can accept the failure as a repudiation, thereby bringing the contractto an end. That party will usually be entitled to recover its losses, often inthe form of wasted expenditure.


2. It can grant an extension of time for performance, imposing a new datefor performance, which will generally be of the essence (Bucklandv Farmar & Moody [1979] 1 WLR 221). Any right to recover damages forlosses caused by the delay may be preserved.


3. It can elect to continue with the contract without imposing any new datefor performance, in which case performance must be within a reasonable time,pursuant to the Sale of Goods Act 1979, s29(3). As with the previous option, anyright to recover damages for losses caused by the delay may be preserved. If aparty chooses this option, it may subsequently give reasonable notice of a datefor performance, making time of the essence again (CharlesRickards Ltd v Oppenhaim [1950] 1 KB 616).


A simple failure to perform by a specified date which is not ofthe essence, although a breach of contract, does not entitle the other party totreat the contract as repudiated. However, a failure to perform within areasonable time may, depending on the construction of the contract, amount to arepudiation (Thomas Borthwick (Glasgow)Ltd v Bunge & Co Ltd [1969] 1 Lloyd’s Rep 17 at p28).


Where the contract does not expressly, or by necessaryimplication, fix any time for the performance of a contractual obligation, thelaw usually implies that it shall be performed within a reasonable time. In Hickv Raymond [1893] AC 22 at p32,Lord Watson remarked of this rule that it: “isof general application and not confined to the carriage of goods by sea. In thecase of other contracts the condition of reasonable time has been frequentlyinterpreted, and has invariably been held to mean that the party upon whom it isincumbent duly fulfils his obligation, notwithstanding protracted delay, so longas such delay is attributable to causes beyond his control, and he has neitheracted 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 thisquestion. In the absence of express agreement to the contrary, the courts of lawgenerally regarded stipulations as to time in a contract as conditions, breachof which would entitle the innocent party to terminate the contract (Metcalfev Fowler (1840) 6 M&W 830). By contrast, the courts of equity wouldgenerally give relief against forfeiture for failure to comply strictly withtime limits (Tilley v Thomas (1867) 3Ch App 61 at p67). The courts of equity made exceptions, however, whichincluded:




  • 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 Sala (1879) 48 LJQB 49).


Upon the fusion of law and equity, the effect of the JudicatureAct 1873, s25(7) (now replaced by the Law of Property Act 1925, s41) was topreserve the position which had obtained prior to the Act. Thus mercantilecontracts remained amongst the exceptions to the general rule that time was notof the essence. The justification for making an exception for mercantilecontracts was explained by Lord Lowry in BungeCorp v Tradex Export SA:


“The treatment of timelimits in mercantile contracts does not appear to be justifiable by anypresumption of fact or rule of law, but rather to be a practical expedientfounded on and dictated by the experience of businessmen”.


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


Application to ITContracts


(1) Recognising WhetherTime is of the Essence


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


Thus, while there are some similarities between IT contracts andcommodities contracts, there is no justification for assuming that the generalprinciple that time is of the essence in mercantile contracts should be extendedto IT contracts. Many IT contracts bear much closer resemblance to constructioncontracts where, as a general rule, stipulations as to time are not regarded asof the essence (Lucas v Godwin (1837)3 Bing NC 737). In our view, the proper approach to IT contracts is toscrutinise the contract as a whole and to determine, in respect of each disputedobligation, whether the timely performance of the obligation was of the essenceof the contract.


The parties are free to agree that time should be of the essenceand 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 outin it are merely the parties’ best estimates at the stage of entering into thecontract, this may be a good reason for the Court to hold that time was notintended to be of the essence.


Other clauses in the contract may lead the Court to theconclusion that time is or is not of the essence. In TheSalvage Association v CAP Financial Services Ltd [1995] FSR 654, it was heldthat a clause which provided for the extension of time of dates quoted fordelivery and completion of any stage of the contract, where the delay was causedby the act or omission of the customer or by causes beyond the control of thecontractor, supported and confirmed the view that time was of the essence. Sucha clause would simply not be necessary if time for performance was not acondition of the contract.


Liquidated damages clauses are frequently deployed in argumentin relation to the question whether time is of the essence. The cases suggestthat there is no general rule as to the significance of such clauses. In Lamprellv Billericay Union (1849) 3 Ex 283 at p308, the Court was persuaded that thepresence of such a clause indicated that time for completion of the works wasnot of the essence. However, in PacificOcean Shipping Corp v Sembawang Corp Ltd (1998) New Law 2980913705, thecourt held that there was nothing inconsistent between a liquidated damagesprovision and a contractual right to terminate for lack of resources based onanticipated failure to complete the contract in accordance with its terms.Tuckey J commented “If they keep italive the liquidated damages provision quantifies the loss which they canrecover; if they terminate the liquidated damages provision is irrelevant”.(Pacific Ocean is probably a casewhich turned on the unusual wording of the contract in question).


It is not always a simple matter in an IT contract to identifythe date for the performance of a particular obligation. In a contract for thedelivery and installation of hardware and package software this will often besimple, because a date for delivery of the hardware and for access for cablingis 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 ofgoods and services, some of which are affected by, or even contingent upon,obligations to be performed by the customer. Such contracts may include thefollowing 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 allof these obligations, but the nature of the obligations is such that theirperformance is often dependent on the co-operation of, or provision ofinformation by, the customer. This dependency may be exacerbated when theinitial definition of the customer’s requirements is vague or incomplete,where the customer’s own IT department is jointly responsible forimplementation, or where the contract suffers from ‘specification creep’.


In many contracts the prescribed dates for performance simplybecome unachievable for reasons which are not the fault of the supplier. In suchcircumstances, the supplier’s obligation may be converted from a date specificobligation to performance within a reasonable time. The determination of whatamounts to a reasonable time in IT contracts is a peculiarly difficult exerciseand 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 aproject is to be successful. In the recent case of AngloGroup plc v Winther Brown & Co Ltd (2000) 72 Con LR 118 at p142, HHJToulmin CMG QC commented that “it iswell understood that the design and installation of a computer system requiresthe active co-operation of both parties”. He went on to identify siximplied terms which were to be found in a contract for the supply of a ‘standardcomputer system’.


1. The purchaser must communicate clearly any special needs to the supplier.


2. The purchaser must take reasonable steps to ensure that the supplierunderstands those needs.


3. The supplier must communicate to the purchaser whether or not thoseprecise needs can be met. If they cannot be met precisely, the appropriateoptions should be set out by the supplier.


4. The supplier must take reasonable steps to ensure that the purchaser istrained in how to use the system.


5. The purchaser must devote reasonable time and patience to understandinghow to operate the system.


6. The purchaser and supplier must work together to resolve the problemswhich will almost certainly occur. This requires active co-operation from bothparties.


The first, second, fifth and sixth of these terms all have thepotential to affect the time for performance of a supplier’s obligations,because they place obligations on the customer the performance of which willfacilitate the performance by the supplier of its obligations. Indeed, it may beargued that the existence of such terms have a more fundamental importance, inthat they militate against a conclusion that time for performance of theobligations in the contract is of the essence. The greater the degree to whichthe 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 theessence.


(2) The 11th HourArgument


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


In St Albans City andDistrict Council v International Computers Ltd [1995] FSR 686; [1997] FSR251, the Council required a system which would enable it to fix the communitycharge figures by the end of February 1990, prior to the commencement of thecommunity charge legislation on 1 April 1990. One item which was to be deliveredwell in advance of February 1990 was software designed to create a register ofcharge-payers. The Council used this software in December 1989 to providepopulation figures on which it then based the community charge rates. Thesoftware was faulty, which caused the population figures to be overstated andcaused the community charge to be set too low, leading to a loss for theCouncil.


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


“Parties whorespectively agree to supply and acquire a system recognising that it is stillin the course of development cannot be taken, merely by virtue of thatrecognition, to intend that the supplier shall be at liberty to supply softwarewhich cannot perform the function expected of it at the stage of the developmentat which it is supplied”.


However in other cases such an argument has been moresuccessful. In Saphena Computing Ltd vAllied Collection Agencies Ltd [1995] FSR 616 at p652, Staughton LJcommented:


“… it is important toremember that software is not necessarily a commodity which is handed over ordelivered once and for all at one time. It may well have to be tested andmodified as necessary. It would not be a breach of contract at all to deliversoftware in the first instance with a defect in it … software is not acommodity which is delivered once, only once, and once and for all, but whichwill necessarily be accompanied by a degree of testing and modification.Naturally it could be expected that the supplier will carry out those tasks. Heshould have both the right and the duty to do so… ”.


St Albans was clearlya special case because the Council needed to start using the software prior tocompletion of the entire contract. In many complex IT cases, however, thereseems to be more scope for applying the approach taken by Staughton LJ, becauseit reflects the realities of software development and system implementation. Itis also reflective of the approach taken by the Court in the AngloGroup case.


(3) Milestones


Many IT contracts are structured around a series of‘milestones’ by which certain obligations must be fulfilled. Milestones areparticularly common in large IT contracts, as they provide evidence of progressin an area where progress may otherwise be very difficult to measure. In somecontracts, each milestone will carry with it a separate liquidated damagesclause and the provision for an extension of time relating solely to thatparticular portion of the contract works. Milestones are often of particularsignificance to the supplier, because they trigger payment.


There is, in our view, no basis for arguing that there should beany general principle as to whether the obligation to reach a milestone inaccordance with the contractual timetable should, or should not, be of theessence. The significance of milestones will vary from contract to contract andeven within a single contract. Some milestones will be on the critical path,others will not. Some milestones will involve completion of substantial phasesof projects, others will involve delivery of relatively trivial andnon-time-critical items. In most cases, the subject matter of the milestone willnot be of a wasting nature, or liable to great fluctuations in value. In somecases, like the St Albans case, thecustomer will intend to use the goods and services delivered by a milestoneprior to the final completion date. In other cases, whether or not thecontractor achieves a particular milestone on time will have no practicalimplications for the client.


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


Conclusion


Time for performance in an IT project is of enormous commercialimportance for both customer and supplier. The historical body of authoritywhich makes up the core of English case law in this area arose principally inthe context of commodities contracts and is not well suited to accommodate theparticular problems which arise in IT projects. A more natural analogy lies withconstruction contracts (in which stipulations as to time are not generallyregarded as being of the essence) because of their project-based nature and theneed for a co-operative relationship between the parties. Gradually a body ofauthority on the issue of time for performance is emerging which is specific toIT cases and in which the courts are showing a willingness to recognise andreflect the unique problems which arise in IT projects.


Duncan McCall and BenPilling are barristers and members of the IT Group at 4 Pump Court, Temple,London, EC4Y 7AN (www.4pumpcourt.com) and may be contacted through their clerksat chambers@4pump court.com or on020 7842 5555.