Hong Kong Society for Rehabilitation v Cadia Ho t/a Resolution Software Consultants  HKCFI 752 is only the second IT project failure case to go all the way to judgment in Hong Kong. Coincidentally, the other case, Cadia Ho v Xerox (Hong Kong) Limited  HKCFI 89, involved the very same Mr Ho. He made a remarkable recovery against a far better resourced opponent in the first case, but perhaps made a poor choice of battle the second time around.
The Society provides the ‘Rehabus’ bus service in Hong Kong that provides bus and taxi type services to the disabled. There are fixed routes, as well as ‘dial a ride’ type services on both ‘sole’ and ‘group’ bases. The Society, which handles many hundreds of requests per day, decided back in 1997, to computerise its manual bus allocation and routing system.
After various discussions between the Society and Mr Ho’s company (RSC), the parties signed a Purchase Order for the supply by of a rostering software product called ‘Roadshow’ and certain customisation services. The Society claimed that it made all its needs known to RSC, including that the system had to handle ‘group’ as well as single orders.
The PO did not have a project schedule as such, but it did provide for stage payments, with 60% up front and two further payments. The last was due on the final day of 1997 and the judge concluded that the parties intended that the system would be ready by then.
Shortly after the PO was signed, RSC discovered that some 300 man days of customisation work was required rather than the 40 odd they had originally expected. This was disclosed to the Society and after certain discussions the parties agreed that some of the less important features of the system would be delayed under a new timetable so long (the Society said) that the main features would not be delayed.
On a subsequent progress report RSC noted for the first time that the capability to handle group orders was marked ‘pending, wait for later decision’. The Society queried this and it then became clear that RSC had no way to solve the inability of the system to handle group orders.
RSC then purported to deliver the system in accordance with the new timetable on a PC that was placed in the Society’s office. The system on the PC could not run group orders and was never put into use by the Society.
The Society eventually wrote to RSC setting a two month deadline for the completion of the system. That deadline was not met and the Society terminated the contract and sued for the return of its 60% deposit. RSC counterclaimed for the second stage payment and the cost of certain customisation work.
The features of this case are all too familiar to IT lawyers used to dealing with failed IT projects. RSC’s main defence was that so often heard from defendants in IT cases that it was the ‘scope creep’ in the Society’s requirements that lead to the delay and the inability of the supplier to provide what was required. But despite a lack of written evidence the judge had little time for that line of argument, holding that it was inconceivable that the Society would not have disclosed a key element of its requirements to RSC.
The judge found that the Society’s deadline had been reasonable and it had been entitled to terminate when it did. He ordered RSC to return the 60% payment.
There are a number of useful points to take away from the case. The first is a practical one. Even in small IT projects, a set of milestone payments should be agreed that map to logical staging posts in the life of the project. This will incentivise the supplier properly. Too large a payment up front can leave a disappointed customer not only having to start a project all over again, but having to sue to get back money that it should never have handed over in the first place.
The second is the usefulness of the common law right of every customer faced with a delay to serve a notice making time of the essence. Normally undertakings as to time in contracts for IT projects will not be ‘of the essence’, so a mere failure by the supplier to meet a time deadline will not lead to an automatic right on the part of the customer to terminate for breach. In this case, while the payment milestones gave an indication of when the project was meant to be completed, there was not even a fixed timetable against which performance could be measured.
However, where a project is running late, the customer can serve a notice giving the supplier a reasonable date by which to complete the delayed work. If that date is not met, the customer will be able to terminate for breach. It will normally be a much safer and more certain course to follow than simply treating accumulated delay as repudiatory and terminating without giving the supplier a chance to remedy the problem.