314

This case note reports on the lessons of RACVInsurance Pty Ltd & Anor v Unisys Australia Ltd& Ors (2001) VSC 300 (24 August 2001)compared with Anglo Group plc v Winther Brown& Co Ltd & BML (Office Computers) Ltd [2000]EWHC Technology 127 (Toulmin CMG QC; 8March 2000).

In the Australian decision of RACV v Unisys,Unisys was found to have engaged in misleadingand deceptive conduct in pre-contractualnegotiations for the supply of a complexdocument management system to RACV. Thecontract entered included effective exclusionclauses, but the Court did not have to deal withthe contract claims and the consequences of theexclusion clauses, as it found almost all damagesclaimed by RACV recoverable under the TradePractices Act 1974.

Conventional reviews of this decision so farhave concluded that it illustrates how ill-advised itis of those acquiring complex computer systems toexecute standard form contracts of suppliers andthe need to ensure contracts are preceded byrigorous tendering process and evaluations, withrequirements reflected in express contractualwarranties.

This article does not seek to question thisadvice, other than to say that such wise nostrumsare not always easy to comply with in informationtechnology implementations in the way they maybe in other industries, and that what happened inthis matter would not necessarily have beenavoided had such advice been rigorouslyimplemented. Nor does this article seek to criticiseor excuse the conduct of one party or another.Perhaps I try to redress the balance a bit byexplaining Unisys’ point of view, but there can beno doubt that Unisys clearly did a very poor jobindeed, at least in its first attempt to perform itscontract in this matter.

Each party had good reason for the position ittook, which led to this matter being fully heardand judgment handed down. The outcome in thismatter should not be regarded as obvious or self-evident, as this article tries to explain, and

everybody in commerce has reason to be deeplyconcerned by the reasoning behind the decisionmade.

By contrast, the English decision in AngloGroup v Winther Brown highlights theresponsibilities of the customer in an ITimplementation, and emphasises that the customercannot sit back and wait for the supplier to fail, asit will then be at risk of being the cause of its owndisaster.

A. RACV v Unisys - backgroundIn 1990, RACV Insurance Pty Ltd (RACV) decidedto computerise its paper-based insurance claimshandling procedures. The idea behind the projectseemed sensible enough. It was to capture digitalimages of claims documents and all subsequentdocumentation relating to the claim, along withcomputer records relating to the claim, and storingthese together in such a way that, for example,instead of a claims officer handling a file going toa physical storage location, seeking out andbringing back a paper folder, and dealing with itand returning it, all these things could be done inseconds with the documents and relatedinformation being summoned up on the computerscreen of the claims officer. This would lead tofaster processing, better service to RACV clientsand savings and efficiencies within RACV. RACVofficers had seen such a system working in otherinsurance companies, and Deloittes professedexpertise in implementing such systems.

B. Request for informationBy 30 March 1993, following committee reportsand advice from Deloittes, RACV issued a Requestfor Information (RFI) to nine potential vendors.The RFI set out in broad terms the objectives ofthe project. It included a number of “majorconsiderations” as well as minimum or mandatoryrequirements of the required solution, including(among many) “on-line storage of all current,active claims, and near line storage of all inactiveclaims within a pre-determined time frame,” but itdid not define these expressions or quantify its

Case report 3 - Australia

In any IT implementation what are the responsibilities of the customer? - RACV vUnisysPeter Knight, Clayton Utz

Computer Law & Security Report Vol. 19 no. 4 2003 ISSN 0267 3649/03 © 2003 Elsevier Ltd. All rights reserved

One wonders

whether any

tenderer in any

other industry

would expect to

be judged on its

ability to divine

the “business

requirement” of

its customer!

315

performance requirements in any relevant way. Inthis regard, it is worth noting, in passing, thatmany of the so-called mandatory and minimalrequirements were gradually abandoned, andpresumably replaced by others, as the processcontinued, as is quite usual in the RFI/RFP/Tenderprocess as it is experienced in the IT industry.These documents often explore possibilities, andare expected to be somewhat flexible in a waywhich would be considered inconceivable in otherindustries perhaps. It is also noted that the RFIwent on to specify its “evaluation criteria” – anumber of vague criteria including “the ability todemonstrate an understanding of and focus on thebusiness requirement of the project.” Onewonders whether any tenderer in any otherindustry would expect to be judged on its ability todivine the “business requirement” of its customer!

One of the recipients of the RFI was Unisys.RACV was already using Unisys products andservices in other areas within its organisation. Inresponse to the RFI, Unisys gave a presentationand demonstration of its “InfoImage” system toRACV on 4 May 1993. Unisys demonstrated itssoftware and, naturally enough, with no data thesystem performed in an instantaneous fashion.Unisys expressed its confidence in being able tomeet the requirements of RACV with itsInfoImage system. However, since at this time, sothe Court found [par 72], no specific requirementsof RACV had been precisely defined; thisdemonstration was taken to be of a general kindonly. After attending demonstrations by othervendors, Unisys was short listed for the projectalong with four other vendors.

C. Request for proposalIn June 1993, RACV issued a Request for Proposal(RFP) to the short-listed vendors, giving moredetails of the business requirements of RACV,particularly the need for a quick and reliablesystem for the retrieval of files and documents.Importantly, the RFP stated that it was mandatorythat the proposed solution be able to provide “on-line” access to open claims and “near line” accessto inactive claims within a predetermined timeframe. The RFP defined “on-line” access to involveresponse times of 2-4 seconds, and “near line”access to involve maximum response times in thevicinity of 20 seconds. The RFP called for aprototype demonstration.

Unisys was given some access to RACVexisting systems in order to enable it to develop its

proposal and prototype demonstration. It thenforwarded its Response to RACV on 5 July 1993(“the July response”). The July response referredto certain sections of the RFP (as was required)and represented that the system designed by Unisyswould be able to meet RACV’s requirements.However, the July response opened with an“Executive Summary” which stated:

As Unisys has had limited access to RACV, this

document does not represent a firm

recommendation nor final proposal to RACV

Insurance. Unisys strongly recommends, however,

that RACV and Unisys undertake a joint

Requirements Definition Study in order that

Unisys may gain a comprehensive understanding

of the RACV insurance requirements, and so

deliver a proposal based on a clear financial

business case.

These reservations were repeated in subsequentsections of the July response, and making clearthat a final configuration, and costing, woulddepend on the further Requirements Definitionand the limitations of the July response. Havingsaid that, however, Unisys was unqualified in itspresentation of the InfoImage solution as capableof meeting all of RACV’s requirements referred toin the RFP, or designed to do so, or supporting orallowing such requirements to be met so as tooptimise the results of use, at least in the technicalsections of the RFP, subject to a criticalqualification placed in section 10 of the Julyresponse, a section titled “Product, Support andServices”. In the first paragraph, under a heading“Terms and Conditions,” Unisys stated, afteragain stating that all statements in the Julyresponse were based on then available informationand was subject to the completion of aRequirements Definition:

Unisys is not at this stage able to commit to

any response time or availability levels as set out

in this request for response as we will require

further information regarding response time

criteria including number of users, definition of

what is being measured etc. With respect to

availability we will need to review availability in

the context of the support plan being contracted

for and the configuration over which availability

is being measured. Any response times or

availability levels which are finally negotiated will

only be measured on the system we are

contracting to supply.

In respect of this disclaimer, it should be notedthat the Court was ultimately very critical of its

Case report 3 - Australia

316

placement and wording. The Court effectivelyignored all the prior warnings in the July responsein focussing on this disclaimer (presumablybecause the legal advisers of the parties did so intheir representations). The RACV witnesses said,and the Court accepted, that although they sawthe disclaimer, its placement suggested to themthat it related solely to “response times” in thesense of attendance at a user site to correct atechnical fault in operations. This, it is notdoubted, may be true with respect to the non-technical witnesses, but RACV was an experiencedIT user, with its own IT personnel assessing theJuly response, advised by specialist advisers inDeloittes, and it is difficult to accept this in thecase of such personnel. For such personnel, suchan interpretation in respect of the words “responsetime” would be absurd in the context of areference to “response time criteria includingnumber of users, definition of what is beingmeasured” but presumably the learned Judge wasnot aware of this. One can understand thedilemma in which RACV found itself – it wastrying to cover a lot of standard, user-drivenservice level issues in a single all encompassingprovision, not surprisingly under a heading whichreferred to “Products” as well as “Support andServices” and making clear its intendedcontractual, exclusionary effect by a heading of“Terms and Conditions.”

Unisys was in a very difficult position. As alltechnical IT people know, including, one has nodoubt, the RACV IT personnel and their Deloittesadvisers, an accurate forecast of performance of asystem in terms of response times is impossible,even absurd, until the final design of the system,number of users and size and nature of databasescan be known. Response times in terms of specificsecond ranges are, furthermore, almost invariably,not indicative of precisely what the customerrequires. This is not to question the importance ofthese performance issues to RACV, as this wasmade clear, but it makes it understandable whyUnisys would try to avoid any form of predictiverepresentation. It is clear that it believed it hadmade this clear, in conjunction with its warningsthroughout the July response and its chosenlanguage. It is equally clear that the warningsgiven by Unisys, even if they were less than clear orideal (just as the RFP, like all humancommunications, was at times less than clear orideal) should have set off alarm bells at leastamong RACV’s technical advisers, although theCourt accepted they did not.

D. Prototype demonstrationUnisys was ranked last in the initial assessment ofresponses by RACV. A prototype demonstration,consisting of just two or three PCs connected to ajukebox, was conducted on 4 August 1993. Again,not surprisingly, document retrieval was shown tobe virtually instantaneous. However, the RACVwitnesses agreed that the demonstration wasconcerned with showing functionality and notperformance, and the Court accepted that theUnisys personnel giving the demonstration avoidedgiving any assurances about response times ormeeting RACV’s “requirements”, and made clearthat short response times of 2 – 4 seconds shownin the demonstration occurred because documentswere being retrieved from hard disk (or sub-secondif in cache), that is on-line, and that documentsstored on optical disk, that is near line, would takelonger, “up to 20 or 30 seconds” – perhaps 10seconds depending on the then state of the opticaldisk, whether on the reader or racked in the jukebox.

Notwithstanding all this, the Court ultimatelyaccepted that RACV personnel left thedemonstration with an expectation that, regardlessof the ultimate size and nature of operation of thesystem developed by Unisys, it could achieve nearinstantaneous response times. This was so, again,notwithstanding the fact of RACV’s IT experienceand the advice of Deloittes. The principalconsultant from Deloittes also attended thedemonstration. While he later expressed notechnical reservations, he did make the point toRACV that the response times demonstrated maynot be indicative of the response times in actualproduction. The court found that this expertadvice was not detrimental to the plaintiff’s casebecause the consultant used the term “may”,rather than expressly stating that RACV “wouldnot” or “could not” expect to attain thedemonstrated response times.

E. ContractBy 24 August, RACV had evaluated Unisys to beranked first on the criteria of user requirements,support, prototype demonstration, projectmanagement, and technical requirements (butexcluding cost). In reply to a letter from RACVdated 29 September, Unisys subsequently reducedits costs and reconfirmed its suitability for theproject in a submission and presentation on 15October 1993 (“the October response”). Given thatRACV entered into negotiations with another

Case report 3 - Australia

Each of the

parties proceeded

to contract; on

entirely different

understandings

and expectations

317

supplier first, which negotiations broke down onthe issue of cost, it would be fair to say thatRACV’s final decision was substantially influencedby cost considerations.

Unisys was requested to provide, and didprovide a draft form of contract, along with aProject Management Plan (PMP) that RACVdistributed internally on 23 November. Thecontract was essentially Unisys’ standard contract,which included an express exclusion clause, whichprovided that if either party was entitled todamages “regardless upon which basis the claim isbrought whether it be negligence, breach ofcontract or misrepresentation” its recovery wouldbe limited to the greater of $100 000 or the totalvalue of charges paid under the contract in the 12month period preceding the date the faultoccurred, provided that liability for “indirect losswhich may include loss of profits, actual oranticipated” was excluded entirely. Naturally, thisclause probably put paid to any action based onthe contract in this matter, but could not be takento contractually limit a claim for misleading ordeceptive conduct in breach of section 52 and/orsection 53 of the Trade Practices Act 1974, on wellestablished grounds.

The PMP related largely to the carrying out ofthe proposed Requirements Definition Study, andincluded amongst its express objectives:

1. A clear picture of the system – including

topology and functionality. 2. Detail of document

image types and volumes, retrieved to which

work stations and when. … 12. Performance

objectives.

The PMP and the July response and theOctober response were expressly incorporated intothe contract by reference – but it is to be notedthat the parties took care not to include the RFIand RFP. In the circumstances, given the expressterms of the July response, the PMP and theexclusion clause, it would be hard for an externaladviser, not familiar with the evidence but familiarwith computer industry transactions, that theparties were taking care to leave the issue ofperformance, including response times, to adetermination after something was known of thespecifics of the system to be built and what wasrequired of it in a real, operational environment.

Indeed, RACV requested very few changes, andthere was no evidence of specific negotiationsabout performance requirements. The contract didnot contain any guarantee regarding systemresponse times. Despite this, the Deloittes

consultant supported the contract, stating in aletter dated 26 November that Unisys hadexhibited the best solution to implementing asystem that would meet the requirements ofRACV. The court found that there was no evidencethat those who negotiated the contract thoughtUnisys’ position was other than that set out in theJuly and October responses.

The court, however, found that the “gap ininformation” in respect of “performanceobjectives” covered by the PMP were vagueexpressions and therefore should not be construedas negativing any previous specific representationwith respect to response times. Unisys had the RFPand was aware of the response time requirementscontained in it, and the number of users and thevolume of documents stipulated in it. The Courtfound that the representations made by Unisys inthe July response and the October response werestill influencing RACV’s actions.

It seems, therefore, that each of the partiesproceeded to contract; the written agreement wassigned on 24 December, 2003, on entirely differentunderstandings and expectations of what theywere about.

F. Functional specification andacceptanceThe project proceeded with the detailed study ofRACV’s requirements, resulting in a FunctionalSpecification, a document of over 700 pages in fivevolumes, created by RACV, completed in March1994. Indeed, there was even a question as towhether RACV had provided the FunctionalSpecification to Unisys! It may be regarded assurprising that, given that this document, createdby RACV, included not one word regardingperformance in the sense of response times, theCourt (and counsel representing the parties,appeared to regard this an relatively insignificant.Be that as it may, Unisys insisted on furtheranalysis being carried out to specify RACV’srequirements so as to enable design of the solutionto be implemented, resulting in a WorkflowNarrative document, completed in May 1994. Thistoo, notwithstanding RACV’s involvement in itspreparation and signoff, included not one wordregarding performance in the sense of responsetimes. Incidentally, it is not surprising to note thatthe Workflow Narrative highlighted some changesin RACV’s requirements, as it business practiceswere changing throughout this process.

Unisys proceeded to create the required system

Case report 3 - Australia

318

and, after acceptance testing and the signing of anAcceptance Signoff by RACV on 27 March 1995,the system was put into production use on 12 April1995.

However, it was not disputed that the systemas built by RACV was almost worthless – acomplete failure. Although it included therequired functional characteristics, under theload of even the most minimal actual useperformance and functionality problems wereencountered from the outset, and grew insignificance as the number of users and volumeof material on the system increased. In short,Unisys had delivered a system which did notwork to the requirements of the contract. RACVbegan to handle all new claims in the old paper-based way on 27 June 1995. Despite vagueassurances by Unisys that the system could berectified by the end of January 1996, RACVstopped using the system completely by 15August 1995. RACV implemented a short termsolution to the problem in November of thatyear.

Had RACV terminated the project at thattime, we might have little to argue about in thismatter. However, RACV invited and allowedUnisys to fix the system, which Unisys proceed todo, by an intensive effort entirely at its own cost,over the ensuing year. The facts appear to be that,at least for the purposes of the judgment of theCourt, by the time that RACV terminated thecontract on 27 June 1996, apart from a number ofminor errors which would normally be classified assupport issues, the system as finally created byUnisys met the requirements of the FunctionalSpecification and Workflow Narrative, as agreed,but was slow. It was slow because Unisys haddesigned the system in such a way that not allactive claims files were stored on hard disk or incache, but could well be on optical disks fromwhich they would have to be retrieved, withresponse times in those cases of sometimes morethan 20 to 30 seconds.

On 20 December 1996 it brought legalproceedings against Unisys for misleading ordeceptive conduct under s. 52 of the TradePractices Act 1974 (Cth) (TPA) and, in thealternative, breach of contract.

G. FindingsIn short, in a long and occasionally ramblingjudgement, the Court found:

■ That Unisys had engaged in misleading anddeceptive conduct, representing that:

(a) the system it would implement wouldhave specific response times for activeclaims files of 2-4 seconds, and archived,inactive claims of no more than 20seconds and/or

(b) to put the matter in a slightly differentway, the system it would implementwould have active claims files stored inhard disk or in cache and inactive claimsfiles in some form of optical disk storagewhich would ensure prompt recovery andthat Unisys had in fact, knowing of theresponse time requirements of RACV, sodesigned and built the system so that allor a great part of the active claims fileswere in fact stored in optical disk jukeboxes, from which inevitably retrievalwould be slower than that required byRACV.

■ That RACV had relied upon suchrepresentations.

These findings should be regarded as extremelytroubling by all suppliers of technically complexproducts requiring substantial implementationprocesses.

First, one could ask what more could asupplier do than Unisys did, in circumstanceswhere Unisys made crystal clear that arequirements analysis was required, short of nottendering at all or advising the customer not toacquire the system? This was not a case whereUnisys actually knew or had any reason tobelieve that its InfoImage product was unsuitablefor RACV – there was no such finding orsuggestion. The fault lay in how the system wassubsequently put together. Unisys may not havecommunicated itself perfectly, but it wasunreasonable, it is submitted, for the Court tofind that Unisys was evasive or less than frank inits proposals, looked at as a whole. RACV, amature, sophisticated and experienced IT user,did nothing to include response times as specificrequirements of the contract, when given anopportunity to do so. Yet the Court found thatthese requirements were nonetheless essential toit, without agreement as to which RACV wouldnot have contracted with Unisys at all, andassumed that RACV was obviously correct inrequiring just those response times, years beforethe system, processes and data requirementswere known – indeed using language of

Case report 3 - Australia

The customer and

the supplier

should work

together to

resolve the

problems

319

“essential purpose” almost as it is used inmistake and frustration cases. Was that a reasonfor imposing so high a standard upon thetenderer? There were other “mandatory”requirements of the RFP which weresubsequently not sought by RACV (as is oftenthe case). These computer systems are verycomplex, and offer a great deal of functionalitywhich is never referred to, but which may haveinfluenced RACV in its selection of Unisys asmuch as the vague allusion to response times,and one must remember that cost was asignificant deciding factor. If the learned judgewere to refer to the mistake and frustrationcases, he might have been more cautious infinding response times to have been “essential”and “fundamental” when so much otherfunctionality was available.

Secondly, why is a statement or conductmisleading or deceptive when it is believed to betrue, but turns out to be wrong as a consequenceof the project to which it relates being badlyimplemented? It was in this area of theinterpretation and application of section 51A ofthe Trade Practices Act 1974 that the judgment, orthe evidence presented to the Court by Unisys, wasexceptionally weak. The onus was on Unisys toshow that it had reasonable grounds for makingthe representations (which it denied, of course,making its position a little difficult). On any viewof the evidence recited in extraordinary detail bythe Court, Unisys’ task should have been an easyone because, initially at least, it appears to be self-evident.

Finally, whilst the Court accepted the evidenceof the RACV witnesses in regard to reliance, itseems to have done so labouring under theimpression that the response times specified in theRFP was self-evidently necessary and reasonable,notwithstanding any subsequent development oruse required of the system to be implemented.However, complex technologies such as that ofUnisys are not like televisions bought off the shelfand what is required of them and how they can beexpected to perform depends enormously upon theinter-relationship of a myriad of complexelements. The Court assumed that, had Unisysmade clear that it was not making a commitmentto response times, then RACV would not havedealt further with it. In my respectful opinion,based on 20 years experience in the IT industry,that is not correct – especially having regard to thefact that I do not believe Unisys was saying that it

would not commit to response times, it was sayingit would commit to response times only after itknew what it was required to implement – and atthat time RACV itself did nothing to make clear toUnisys that response time commitments were required.

H. The UK Winther BrowndecisionAn interesting comparison may be made to anEnglish decision in Anglo Group plc v WintherBrown & Co Ltd & BML (Office Computers)Ltd [2000] EWHC Technology 127 (ToulminCMG QC; 8 March 2000). In that case, whichalthough a contract case showed many similarissues to those in RACV v Unisys, the Court didnot succumb to the temptation of effectivelyimposing de facto the burden of making goodthe wishes of the customer upon the supplier.The legal relationship between the customer andthe supplier, the Court found, becomes moresophisticated as modifications to a packagedsoftware system are required. The Court foundthat it is well understood in the legal and ITworld that the design and installation of apackaged software system requires the active co-operation of both parties. The duty placed onthe customer goes beyond merely setting out,prior to implementation, what it wants thesystem to achieve.

As a consequence, the Court held that a termcan be implied in contracts for the supply of astandard packaged software system that thecustomer should:■ Communicate clearly any special needs to the

supplier;■ Take reasonable steps to ensure that the

supplier understands those needs; and■ Devote reasonable time and patience to

understanding how to operate the system.Correspondingly, the supplier should:■ Communicate to the customer whether or not

those precise needs can be met and if so howthey can be met. If they cannot be metprecisely the appropriate option should be setout by the supplier;

■ Take reasonable steps to ensure that thecustomer is trained in how to use the system.

In addition, the customer and the suppliershould work together to resolve the problemswhich, in the Judge’s words, “will almost certainlyoccur”. The decision in Winther Brown suggeststhat this may go as far as the customer meeting thecost of implementing a solution to a problem or

Case report 3 - Australia

320

even changing aspects of its business practices toaccommodate the new system., in order to avoidexcessive modifications to the software. If theparties do not co-operate, in the Judge’s view, it islikely that the customer will not gain the desiredresults from the system.

The decision in Winther Brown represents ashift in the balance of responsibilities between thecustomer and the supplier as it makes clear thatthis co-operation cannot simply be half-heartedand superficial.

I. ConclusionIn short, whilst the decision of the Court inRACV v Unisys may have been correct, thereasons given took insufficient account of therealities of the computer industry, or the Courtwas not effectively made aware of those realities,as a consequence perhaps of the complexities ofthe facts and legal issues which were presented. Itis disturbing, in that case, that RACV did notcommunicate its performance requirements,notwithstanding they were fundamental to it, atthe time that Unisys clearly expected it to do so –in the in the PMP or Functional Specification. Itis even more disturbing that RACV let Unisys setabout fixing the problems, at its own expense,over an extended period of time, before decidingto throw the entire solution away, based uponthese same performance requirements. We do notdoubt that the solution was unsatisfactory – buthow much responsibility should RACV haveshouldered in these circumstances – and doesAustralian law allow for such a provision in thesesorts of cases?

In a recent article by Professor WarrenPengilley appearing in the Australian Business LawReview, titled The Ten Most Disastrous Decisionsmade Relating to the Trade Practices Act (2002) 30ABLR 331, Professor Pengilley includes among histargets the decision of the High Court in Gates vCity Mutual Life Assurance Society Limited [1985]ATPR 40-666, in which the Court found that themeasure of damages in respect of a breach ofsection 52 of the Trade Practices Act in pre-contractual negotiations should be the same asthat for the common law tort of deceit, that isreliance losses but not expectation losses. Whilstone can appreciate Professor Pengilley’s point ofview, so long as Australian Courts regard section52 as breached as easily as the Court found inRACV v Unisys, to thereby bypass the rigours ofcontract law and the consequences of the need to

respect the bargain made between sophisticatedcommercial organizations, then it would be themost profound injustice to impose upon thesuppliers of complex information technologies theextra burden of making good the loss of“commercial expectations” of their customerswhere things go wrong, regardless of good faithand good intentions.

Peter Knight, Partner, Clayton Utz, Sydney,Australia. Email: pknight@claytonutz.com

Case report 3 - Australia