The decision of his Honour Justice Byrne in the Supreme Court of Victoria in the case ofIpex ITG Pty Ltd (in liq) v Melbourne Water Corporation (No 5) [2009] VSC 383 (11 September 2009), involved an IT service provider (Ipex) suing its customer (Melbourne Water) in respect of misrepresentations that were allegedly contained in Melbourne Water’s pre-contractual tender documentation. The case was brought under ss 51A and 52 of the Trade Practices Act 1974 with Ipex alleging that the misrepresentations constituted misleading and deceptive conduct.
Summary of allegations
The allegations concerned certain information provided by Melbourne Water as to the number of calls for assistance which its IT help desk had received over the six-month period prior to publishing its invitation to tender (ITT) and request for proposal (RFP). The information was, according to Ipex, inaccurate and incomplete and misled Ipex about the number of staff that it would have to deploy in order to meet the demand placed on the help desk (the help desk being within the scope of the services outsourced to Ipex). Ipex said that, as a result of being misled, it incurred costs and expenses which were not taken into account when it calculated its bid price and which Melbourne Water subsequently refused to pay.
Summary of decision
His Honour held that either (a) the alleged representation in question had not in fact been made, or (b) if it had been made, it was not proven by Ipex to be false, and/or (c) in any event, it did not mislead or deceive Ipex because Ipex didn’t rely on it. In other words, Ipex failed on all counts.
Features of output-based outsourcing
The true importance of this judgment for the IT community is to identify why Ipex lost the case so comprehensively. In my opinion, the fundamental reason is that this case relates to an output-based outsourcing project, not a traditional input-based project, and Ipex simply did not appreciate the important features of output-based IT projects which distinguish them from input-based projects. The case therefore highlights the need for IT service providers to appreciate and fully understand the nature and legal implications of these types of projects. The key attributes of output-based projects (if properly structured and if the contract is properly drafted) are as follows.
· The customer expresses its requirements in terms of its business requirements and in terms of outputs (or outcomes) – the customer is the master of its business, which it knows better than anyone, and it must articulate its requirements fully and unambiguously to the service provider – the customer therefore mandates ‘what’ it wants.
· Solution risk is transferred to the service provider – the service provider is the IT expert and must take responsibility for designing and delivering its IT solution, which should not be the customer’s risk – the service provider therefore decides ‘how’ it is going to meet the customer’s requirements – importantly, the customer should (ideally) not stray into prescribing any aspect of the solution.
· The charging mechanism is based on the service provider meeting the customer’s business requirements, so the customer pays only if its requirements have been met (this is the best way of demonstrating and receiving value for money (VfM)).
· The service provider is involved directly in managing (and transforming, where necessary) the customer’s business processes, through its control of the IT systems, in order better to achieve the customer’s requirements.
· The service provider typically participates in the success of the customer’s business within an agreed risk-reward incentivisation framework.
Features of the Melbourne Water project
A feature of Melbourne Water’s RFP was that it was expressed in terms that the successful tenderer would be required to provide ‘outcomes’ (or ‘outputs’). How the outcomes were to be achieved was, to a very large extent, a matter for each tenderer. This is entirely consistent with the statement above that ‘solution-risk’ is transferred to the service provider under an output/outcome-based outsourcing contract.
Another important feature was that the tenderers were required to submit a lump sum price for providing the outcomes.
Ipex was therefore required to assume most, if not all, of the risks involved in providing IT services for Melbourne Water over the three-year term of the project and, logically, Ipex was therefore required to include in its tender price an allowance for these risks (or take the risk of not doing so).
Six alleged misrepresentations
Ipex’s case was based on six alleged misrepresentations concerning the number of calls to Melbourne Water’s IT help desk during the six-month period prior to it issuing its RFP. This information was set out in the Help Desk Calls Table (HDC Table) which was included in the RFP.
First express representation: that the average number of monthly calls between October 1999 and March 2000 was 433.
Second express representation: that the additional information as to the categories, numbers and type of calls was accurate.
Ipex claimed that both these representations were inaccurate and therefore they were false. His Honour dealt with both of these alleged misrepresentations together.
The figures for total calls in the HDC Table varied from month to month from a low of 364 in March 2000 to a high of 527 in November 1999, but the average was 433 per month. However, from July 1997 to September 1999, the number of calls varied from a high of 980 in August 1997 to a low of 475 in December 1997. Although the general trend of the total number of calls per month was downward, the average over this period of 28 months was 723 per month. Furthermore, during the project itself, Ipex in fact experienced help desk calls averaging 675 per month.
On all of this evidence one might expect that Ipex had a solid argument that the HDC Table was misleading. However, Ipex’s argument was flawed principally because the HDC Table made it clear that the figures related only to the specific six-month period from October 1999 to March 2000. The fact that the average calls per month both before and after that period was higher did not establish that the information in respect of the specified period was wrong. Ipex simply did not have a ‘smoking gun’ to prove that the figures for the stated period were inaccurate.
A key aspect of an output-based project is that the service provider, knowing and appreciating that its customer is transferring solution-risk to it, must undertake due diligence (or take the risk of not doing so), in particular in relation to price-sensitive matters. Furthermore, the contract was a lump sum contract and Ipex bore the risk that its input costs may escalate (unless Melbourne Water’s requirements were to change, which they didn’t).
First implied misrepresentation: that the average number of help desk calls would be and would continue to be approximately 433 per month during the three- year contract.
The first of the implied misrepresentations was that Melbourne Water, by providing the historic figures of help desk numbers, made an implied representation that the average number of help desk calls would be, and would continue in the future to be, approximately 433 per calendar month. This allegation was based on what Ipex described as ‘a notorious industry practice’ that the number of help desk calls over a period of time remained constant providing there was no change to the IT environment.
Output-based outsourcing projects are not about ‘minding the keys’ or keeping the IT infrastructure ‘ticking over.’ The customer wants its service provider to be a pro-active manager of its IT systems in order to improve its business processes and its competitiveness and to deliver cost benefits. If Ipex seriously thought that the business and/or the IT environment would not change in the future then it had misunderstood from the outset the nature of the project and its role in the project. There was nothing in the RFP to lead Ipex to believe that Melbourne Water’s IT environment would remain constant over the three-year term of the contract and, to the contrary, the RFP itself warned tenderers that they must accommodate future changes in a ‘dynamic environment.’
The expectation of Melbourne Water was consistent with and reflected the expectation of all customers that award a tender under an output-based structure, ie they expect the new IT service provider to examine critically the current IT environment and recommend and make improvements. This was indeed one of Ipex’s functions under the RFP.
Second implied misrepresentation: that the information was a representative sample sufficient to allow Ipex to cost its tender price.
Ipex argued that, because Melbourne Water knew that the tenderers would calculate their tender price from the information contained in the HDC Table, it impliedly represented that the information was sufficient for that purpose (ie calculating their bid price). Relying again on the number of calls from July 1997 to September 1999 (723 per month), Ipex submitted that the monthly figures in the HDC Table for the six months from October 1999 to March 2000 were obviously not a representative sample and they misled Ipex when it calculated its costs.
However, a feature of an output-based tender process is that the customer allows (indeed, should require) tenderers to approach the achievement of the stipulated outcomes in their own way and to introduce innovation and change where they consider it to be cost effective. Changes of this kind are clearly likely to affect the number and type of help desk calls both in the short term and in the long term. In the short term the numbers might increase; in the long term, innovative changes should produce greater efficiencies and reduce the number of calls.
The fundamental flaw in this case was that Ipex’s costing methodology used a traditional input cost basis and it was therefore inappropriate for an output-based project. The evidence was that Ipex used a costing methodology that it had developed for an earlier project (referred to as the G8 tender). However, there was an important difference between the basis for the G8 tender and the Melbourne Water tender. The G8 tenderers were provided with the general number of help desk calls upon which they would calculate their costs and extra calls would warrant a price adjustment, ie the G8 customer did not transfer solution-risk in excess of the stated number of calls, quite the opposite, the risk reverted to the G8 customer.
His Honour emphasised (with respect, quite rightly) that the philosophy underlying the Melbourne Water tender was that the successful tenderer was to achieve an output (or outcome) in terms of the extensive performance requirements set out in the RFP. Assuming that the numbers of calls shown in the HDC Table was to be taken as a representative sample of the experience of Melbourne Water, it could (and should) therefore only be relied upon as indicative of the existing position. How this might be used for the purpose of predicting the future was a matter for the tenderers. In this sense it was therefore sufficient for them to calculate their costs.
First misrepresentation by silence: withholding relevant information and consciously not disclosing it.
Melbourne Water accepted that it did not disclose to (and consciously withheld from) Ipex additional information about help desk calls which it had received from July 1997 in monthly reports provided to it by its legacy IT services provider. Ipex submitted that the failure to disclose the prior help desk calls history meant that the limited information in the HDC Table was misleading – it contained only half of the story.
On the evidence, the period prior to October 1999 was all but irrelevant because of changes to Melbourne Water’s IT environment (and help desk requirements) that resulted from carrying out another project. It was therefore not misleading to withhold this earlier (and irrelevant) information. Indeed, arguably, it would have been misleading to have done so.
Second misrepresentation by silence: not responding to Ipex’s express requests for further specific information at a tender meeting.
The final allegation was based on the failure of Melbourne Water to provide information as to help desk calls sought by Ipex at a pre-tender meeting. It was accepted by Melbourne Water that certain requests for information were not answered at the meeting and, although they were deferred to another meeting, they were not later responded to.
Insofar as the various requests were relevant to help desk calls (which was not clearly the case), Melbourne Water chose not to provide the requested information because they took the view that it would be unhelpful for the tender process if tenderers were provided with the experience of the legacy provider. This would arguably lead them to follow the ‘old’ approach to providing IT services and the intent of Melbourne Water was to encourage tenderers to propose innovative solutions (a hallmark of output-based projects).
The judge accepted this explanation as being consistent with the inherent nature of the project and consistent with other aspects of the RFP. Accordingly, this allegation was also dismissed.
Conclusion
It is clear that Ipex did not fully appreciate the nature of output-based IT projects and how they differ from input-based projects.
Of course, an output-based procurement approach is not always appropriate for every type of IT outsourcing project. It is less likely to be appropriate for the procurement of off-the-shelf or commoditised IT systems and services, whereas it is likely to be a good candidate for longer term and high value projects and/or where the customer wants its service provider to be its IT ‘business partner’ and provide a service that:
- meets its business requirements measured in terms of outputs/outcomes, not inputs;
- offers demonstrable value for money, with payments linked to said outputs/outcomes, not inputs; and
- is managed pro-actively, ie the service provider is both required and incentivised to identify opportunities to increase the customer’s competitiveness, improve the customer’s business processes and deliver cost savings.
Some might say that that’s what IT projects should always be about.
Julian Gyngell is a Solicitor & Attorney at Kepdowrie Chambers Wahroonga New South Wales: julian@gyngellslaw.com www.gyngellslaw.com
