QUEENS BENCH DIVISION
TECHNOLOGY AND CONSTRUCTION COURT
133-137, Fetter Lane,
London, EC4A 1HD
B e f o r e :
| ASTEA (UK) LIMITED|| Claimant|
|- and -|
|TIME GROUP LIMITED|| Defendant|
Sa'ad Hossain (instructed by Halliwell Landau for the Defendant)
Crown Copyright ©
H.H. Judge Richard Seymour Q. C. :
"(a) Contract capability
ServiceAlliance will record information on the computer screen that tells the customer that a contract exists with a third party for maintenance of a certain product. If you take a simple example of a washing machine, perhaps the owner of this washing machine pays a [sic] £100 a year for one of our customers to maintain and fix the machine whenever necessary. Astea's product allows a customer to take a call from the owner of the washing machine to say that it is broken, the system checks as to whether a contract exists, and also whether it is still in date, and if all is in order the call is logged, and the customers determine whether billing is appropriate or not. This really represents the front end of the system, which allows the customer to get the money in the door.
(b) Call handling and despatch
This element of the product moves the system onto the next stage, and allows a customer to perhaps write onto the system that (in the washing machine example) there is water spilling onto to [sic] the floor. This detail is logged into the system, and so is the fact that an engineer is required to visit the client. The system itself will search for a field engineer at the correct skill level who can be available at the requested time, and that engineer can then be booked through the system. There are lots of clever options in this aspect of the product, and it is possible to send information that is logged to the engineer on his hand held terminal, and the opposite is true such that the engineer can record details of what he did on any particular visit, and return this information to despatch, or he can log it against the costs. This information (such as the types of visits that the engineers have been called out to do, the remedial work that is required, and so on) can all then be analysed so that the customer is able to become more client focused, and also on a very practical level can monitor stock. This would become relevant where the information coming back from the engineer is that he has had to for example replace a rubber seal that was broken. The system then knows that this was the part that was required for the job, which brings me onto the third core element.
(c) Spare parts
Astea's product will allow a customer to track spares, and also has a programme which can automatically reorder certain parts, to maintain a minimum level at all times. This is really the logistics module, which will not only record details of where the spare parts are, but also which engineer may have reasonable access to them and handle the job."
"This ServiceAlliance License and Support Agreement is between Astea UK Ltd with its registered office at Trent House, University Way, Cranfield Technology Park, Cranfield, Bedfordshire MK43 0AN, UK ("Astea") and Time Group Limited, with its registered office at Time Technology Park, Burnley, Lancs, BB12 7TG ("you" or "the client"). Intending to be legally bound, you and Astea agree to the terms and conditions stated in this Agreement."
"You and Astea agree that Astea will provide, and you will purchase and pay for, support and maintenance services for the foregoing software at Time Technology Park, Burnley, Lancs (the "Central Site") for the period ending on 16th May 2001 under the terms and conditions stated in this Agreement."
There followed a table in which it was set out that the licence fees payable amounted to £170,400.
"Reference is hereby made to that certain ServiceAlliance License and Support Agreement No SA170400001 dated ……… (the "Software Agreement") by and between Astea UK Ltd. ("Astea") and Time Group Limited ("you"). This Schedule shall become valid and binding upon the parties only after it is signed by Astea and you. In the event that any of the terms and conditions of this Schedule conflict with the Software Agreement, this Schedule shall control for all purposes. In accordance with the Software Agreement, Astea shall provide the Services listed below upon the following additional terms and conditions."
In a table entitled "Description of Services" below the words just quoted were set out:-
"ServiceAlliance Implementation Services Up to 72 days
Modifications to AllianceLink for Tetra CS/3"
The stated "Total Value of Services" in the table was £60,000.
Services will be invoiced bi-monthly following performance of the services together with travel and living expenses, if applicable and are due and payable within 30 days of invoice date.
The standard unit of charge is one day, which provides 7.5 hours of work. Standard working hours are from 9.00 am to 17.30 pm local time, with a one hour break for lunch. Hours worked in excess of 7.5 per day will normally be charged at pro-rata rates, although if the total hours in a week does not exceed 37.5, then the additional charges will not be made.
No charge will be made for travel time to or from the place of work where the total time travelled does not exceed 2 hours. Any time in excess of 2 hours will be billed at pro-rata hourly rates. Where long-haul, overnight flights of greater than 5 hours are made, we expect that our staff should have the opportunity for 4 hours rest before commencing work. This time will be billed to the customer.
All expenses for travel, accommodation and subsistence will be the responsibility of the customer."
"Charges for out-of-pocket expenses will be invoiced as incurred by Astea. All invoices are due and payable within thirty (30) days after invoice date unless otherwise noted in this Agreement or on the invoices. Late payment charges will be imposed at the rate of 1.5% per month. Astea will also have the option to extend, on a day-for-day basis, the related delivery schedule for each day an invoice is past due."
"If either party to this Agreement defaults in the performance of any of its obligations under this Agreement or any of the Schedules or Addenda attached to this Agreement and such default is not corrected within thirty (30) days after receipt of written notification of such default from the non-defaulting party, then the non-defaulting party may terminate this Agreement (or, if applicable, individual Schedules or Addenda to this Agreement) immediately upon delivery of written notice of termination to the defaulting party. If you are the non-defaulting party, you will be reimbursed for the unused portion of the Software Support Fee as of the termination date."
"Astea warrants that the Packaged Software will operate in substantial conformity with the Materials (a) for a period that will end ninety (90) calendar days following the Delivery of the Packaged Software (the Applicable Warranty Period), and (b) during the current Support Period. This warranty does not apply to any third party software or Packaged Software that has been altered or modified in any way by you. You acknowledge that you have had sufficient opportunity to review the Materials prior to the execution of this Agreement and understand the capabilities and limitations of the System. You agree to provide all reasonable assistance requested by Astea in identifying, researching and documenting the circumstances of any non-conformance of the System. During the warranty period set forth in this Section 10.0 Astea agrees to provide you with Packaged Software support services at no additional charge."
"Other than the warranties expressly stated in this agreement, Astea neither makes nor grants any warranties, representations or conditions, express or implied. Astea expressly excludes all implied warranties, representations and conditions, including specifically any implied warranty arising by statute or otherwise in law or from a course of dealing or usage of trade. Astea hereby excludes any and all implied warranties, representations or conditions of non-infringement, merchantability, merchantable quality, or fitness for any purpose, particular, specific or otherwise."
"The following Addendum shall modify the terms and conditions of that certain Master Software Agreement dated as of 14 July 2000 by and between Astea UK Ltd., with its registered office at Trent House, University Way, Cranfield Technology Park, Cranfield, Bedfordshire MK43 0AN, UK and Time Group Limited, with its registered office at Time Technology Park, Burnley, Lancs. BB12 7TG, United Kingdom, and each of the schedules and agreements attached thereto and incorporated by reference therein (collectively, the "Master Software Agreement"). Capitalized [sic] terms used but not otherwise defined herein shall have the respective meanings ascribed to such terms in the Master Software Agreement. Any term or condition of the Master Software Agreement in explicit conflict with the terms or conditions of this Addendum shall be deemed to be specifically and expressly superseded by the provisions hereof."
"Except as provided in section 12 hereof, your sole and exclusive remedy for any damage or loss in any way connected with the System, this Agreement or any of the schedules, Addenda, amendments or attachments hereto, or for any damage or loss in any way connected with the enhancements, Software Support or any other material, information or services furnished by Astea hereunder, whether or not caused by Astea's breach of warranty, negligence or any breach of any other duty, shall be, at Astea's option, replacement of the System or enhancements, re-performance of the Software Support or services, or return or credit of the appropriate portion of any amounts received by Astea from you with respect to the System or Software Support. In no event shall Astea's liability exceed the amounts received by Astea for the System or Software Support under this Agreement during the twelve (12) month period immediately preceding your claim for recovery hereunder, even if Astea is advised of the possibility of such damages. You agree that Astea shall not be liable for any special, indirect, punitive or consequential damages hereunder, including but not limited to, loss of use or the loss of data or information of any kind, however caused, or failure of the System to work or perform in any way, or any liability to end-users or to third parties.
No indemnification of any kind is provided by Astea hereby to you or any other person, except as expressly provided in Section 12.0 below."
"Section 15.0 In addition, the parties hereto agree to the following points of clarification and understanding regarding the Agreement….
15.4 The payment schedule shall be 1/3 on execution of the Agreement, 1/3 on delivery of the System, and 1/3 on 1st September 2000.
15.5 Provided Time Group has provided timely assistance and cooperation [sic] on its part, the scheduled date of implementation by Astea shall be 1 August 2000…."
The sums claimed by Astea in this action
The defences raised on behalf of Time
"7. Further, it was a term of the Master Software Agreement that the Claimant would provided "ServiceAlliance Implementation Services" in respect of the System provided under the Software Agreement part of the Master Software Agreement. The said ServiceAlliance Implementation Services were agreed between the parties and are contained in and/or evidenced by the following documents copies of which are attached to this Defence and Amended Part 20 claim:
(a) The document entitled "Time Computers – ServiceAlliance Business Requirement Call Centre System Integration" ("the BRD") dated 11 July 2000, produced by Mr. Ian Dundas, European Product Manager of the Claimant and agreed by the Defendant. The Defendant will rely on the BRD for its full terms meaning and effect. The BRD provided, inter alia, that "This requirement covers the integration requirements between [the Defendant's] call centre system [Pulse], ServiceAlliance and Sage Tetra's CS/3 Product." Together with the further BRD's [sic] produced by Ian Dundas on 11 July 2000 relating to the integration of ServiceAlliance with Tetra CS/3 and referred to in paragraphs 6(a)-(d) of the Defendant's further information.
(b) The document entitled "Service Centre ServiceAlliance Requirements Time Group Limited" produced by the Defendant and agreed by the Claimant setting out the agreed minimum requirements of the Defendant for phase 1 of the Implemented System and the further requirements to be completed in subsequent phases.
(c) The document entitled "Issues for Time Group Limited/Service Alliance Project" dated 7 July 2000, produced by the Claimant and agreed with the Defendant setting out those tasks to be completed in phase 1 of the Implementation Services and those further tasks to be completed in subsequent phases.
8. Further or alternatively, it was an implied term of the Master Software Agreement:
(a) by Section 14 (2), (2A) and (2B) of the Sale of Goods Act 1979, that the Implemented System, including both the System and the disk containing the software necessary for the implementation of the System would be of satisfactory quality and reasonably fit for all purposes for which goods of the kind in question are commonly supplied;
(b) by Section 14 (3) of the Sale of Goods Act 1979 and/or at common law, that the Implemented System, including both the System and the disk containing the software necessary for the implementation of the System would be reasonably fit for its purpose, such purpose being the fulfilment of the requirements set out in the Specification;
(c) if, contrary to the Defendant's primary case, there was no contractual time for completion of the Implementation Services, then the Implementation Services were to be completed within a reasonable time. A reasonable time, having regard to all the circumstances, was 13 November 2000 alternatively the end of December 2000 alternatively 6 March 2001.
Variation of the Agreement
9. In or about July 2000, the System was delivered to the Defendant in readiness for the Implementation Services to be carried out. Thereafter it was agreed that the date for delivery and installation of all 5 integration software programs under the Services Agreement would be delayed until the end of October 2000. The said agreement is evidenced by an e-mail dated 17 October 2000 from Derek Brotherston of the Defendant to Ian Mapp of the Claimant and the further documents referred to in paragraphs 17-21 of the Defendant's further information. Further or alternatively there was an agreement that implementation would be by 6 November 2000 as evidenced by the documents described in paragraphs 22-4 of the Defendant's further information.
9A. It was an implied term of the Master Software Agreement that the Implementation Services would be completed, by which is meant the delivery, installation and testing of the said integration software by the Claimant, within a reasonable time. A reasonable time, having regard to all the circumstances, was 13 November 2000 alternatively the end of December 2000 alternatively 6 March 2001.
9B. If, contrary to the Defendant's primary case, no variation was agreed to the effect that the said integration software would be delivered and installed by the end of October 2000 alternatively 6 November 2000, it was an implied term of the agreement that the Implementation Services would be completed within a reasonable time. A reasonable time, having regard to all the circumstances, was 13 November 2000 alternatively the end of December 2000 alternatively 6 March 2001.
Breach of the Master Software Agreement
10. Wrongfully and in breach of the Master Software Agreement, the Claimant failed to complete and install the said integration software by 30 October 2000 or 6 November 2000 and failed to complete the Implementation Services by 13 November 2000 or at all:
(a) By 17 November 2000, some 8 weeks after the due date for successful Phase 1 implementation of the System, the installation and testing of the necessary interfaces between the System and Tetra CS/3 and Pulse had not been completed.
(b) Further delays ensued, as a result of which the Defendant instructed the Claimant that although it should continue to carry out all possible Implementation Services including implementation of the System on the Defendant's test network, it would not be permitted to implement the System on the core hardware used for the Defendant's business over the busy pre- and post-Christmas period because of the considerable disruption that would then be caused to the Defendant's business.
(c) During early 2001, the Claimant continued to attempt to provide the Implemented System, but even by 6 March 2001 the Claimant had still failed to provide the same.
11. The delay in the completion of the Implementation Services beyond 13 November 2000 was caused or substantially contributed to by the Claimant's negligence and/or unreasonable conduct in that it was caused by the Claimant's failure prior to the end of October 2000 to allocate adequate resources to the completion of the said integration software and its failure after the end of October 2000 to ensure continuity in its staff responsible for implementing the System or to ensure that employees with sufficient experience or knowledge and understanding of the Defendant's requirements were used by it in attempting to do so.
12. By reason of the Claimant's aforesaid delays in implementing the System the Claimant was in repudiatory breach of the Master Software Agreement entitling the Defendant to terminate the same.
13. On or about 6 March 2001 at a meeting between Mr. Mohsan, the managing director of the Defendant, and Mr. Noble of the Claimant, Mr. Noble informed Mr. Mohsan that the Claimant would need several more months in order successfully to provide the Implemented System. Mr. Mohsan informed Mr. Noble that he had lost faith in the Claimant's ability to perform the Master Software Agreement, that market conditions had changed and that the Defendant did not wish the Claimant to carry out any further work. In the premises, the Master Software Agreement was terminated at the said meeting alternatively by the Defendant's conduct in preventing further work, denying the Claimant's claim and at the very latest by service of this Defence on 24 June 2002.
14. By reason of the foregoing, the System delivered to the Defendant in its unimplemented form is of no value to the Claimant and the sums paid by the Defendant to the Claimant were paid for a consideration which has wholly failed. Further, such additional sums as the Claimant now claims would, if paid, be paid for a consideration which has wholly failed."
Time's Part 20 claim
The Amended Reply and Defence to Part 20 Claim
"The above term satisfied the requirement of reasonableness because:
(1) The licensee under the Software Agreement was adequately protected by Clause 10.0 of the agreement.
(2) The nature of computer software is such that the conditions implied by the Sale of Goods Act 1979 are not appropriate.
(3) The balance of bargaining power between the parties was, if anything, tilted in favour of the Defendant."
So far as clause 11.2 was concerned, at paragraph 35 the matters relied upon in support of the contention that that satisfied the requirement of reasonableness were that the clause itself gave adequate protection to the licensee, that the balance of bargaining power was, if anything, tilted in favour of Time, and
"The liability of a provider of software, if unlimited, is potentially very high indeed, and insurance is therefore expensive or impossible to obtain."
Mr. Kinsky did not formally abandon reliance upon the provisions of clause 11.1 and clause 11.2, but Astea in fact made no attempt to justify by evidence the proposition that the provisions of either satisfied the requirement of reasonableness set out in Unfair Contract Terms Act 1977. As the onus of proving that they did was upon Astea, the failure to adduce evidence meant that a finding that they did not was inevitable. I need say no more in this judgment about these provisions.
"20. Further or alternatively, although it [is] admitted that the Software Agreement provided for the sale by the Claimant to the Defendant of the medium upon which the ServiceAlliance software was delivered,
(1) The Software Agreement was otherwise not an agreement for the sale of anything, but a licence to use the ServiceAlliance software, and
(2) The ServiceAlliance software was not "goods" within the meaning of the Sale of Goods Act 1979.
(3) The Sale of Goods Act 1979 therefore does not apply to the licensing of the software or the provision of the implementation services.
21. In the premises, paragraphs 8(a) and (b) are denied.
22. Clause 11 also applied to the terms of the Service Agreement and satisfied the requirement of reasonableness for the reasons set out in paragraph 19 above. Paragraph 8(c) is therefore denied.
23. As to the first sentence of paragraph 9 it is admitted that the ServiceAlliance software was delivered to the Defendant but the Defendant is put to proof as to the date.
24. The second sentence of paragraph 9 is denied.
(1) At the date when the Claimant delivered the ServiceAlliance software to the Defendant, both parties knew that it was not going to be possible to implement the system by 1 August 2000. In the premises, if there was a contractual obligation on the Claimant to implement the ServiceAlliance software by that date, it was waived by the Defendant and/or the contract was varied by consent so as to remove that obligation.
(2) The Claimant never agreed to implement the ServiceAlliance software by the end of October 2000. The e-mail relied upon in the third sentence of paragraph 9 does not evidence the agreement of the Claimant to do so.
(3) There was no agreed implementation date; at best, the Defendant was entitled to have the ServiceAlliance software implemented by the Claimant within a time that was reasonable in all the circumstances.
25. Paragraph 10 is denied:
(1) It is admitted that the ServiceAlliance software was not implemented by the end of October 2000. There was no breach of contract on the part of the Claimant and/or the cause of the delay beyond that date was not caused by any such breach.
(2) There was no "due date for successful Stage 1 implementation of the System".
(3) Delay was caused by
(a) The fact that relations between the Defendant and Lynx deteriorated to a point where Lynx were very unwilling to cooperate [sic] on the project.
(b) The fact that Tetra CS/3 software was not working properly and/or the interfaces had not been developed by Lynx and/or by its subcontractors, VI Software and/or by the Defendant's individual contractors.
(c) The team working on the Pulse software could not provide the data necessary for the Claimant to test the ServiceAlliance software and/or develop the necessary interfaces with Tetra CS/3 and Pulse.
(4) It is admitted that the ServiceAlliance software had not been implemented by early November, and that the Claimant had no access to the Defendant's computer system between that date and the beginning of February 2001.
(5) As to paragraph 10(c) the Claimant admits that it continued to attempt to work on the necessary interfaces with Tetra CS/3 and Pulse but continued to be hampered by the provision of inaccurate test data.
26. Paragraph 11 is denied. The Claimant exercised reasonable skill and care in delivering the services it was obliged to provide under the Services Agreement.
(1) It is denied that any part of the process of implementing the System should have been completed by the end of October 2000. Due to delays in implementation and deficiencies in the performance of the Tetra CS/3 and Pulse software and interfaces, it could not have been.
(2) The Defendant was not entitled to and did not benefit from a warranty to the effect that individual members of the Claimant's staff would remain the same throughout the project period.
(3) Further or alternatively the delays caused by the Defendant and/or Lynx and/or VI Software were outside the Claimant's control and, to the extent that rotation of the Claimant's staff resulted from those delays, the Claimant is not responsible for any subsequent delay.
(4) The allegation that the Claimant's employees did not have sufficient experience or knowledge and understanding of the Defendant's requirements is so vague as to make it impossible to respond to. For the present it is simply denied.
27. Paragraph 12 is denied. None of the breaches alleged (even if established) evidence an intention on the part of the Claimant no longer to be bound by the terms of any of its contracts with the Defendant.
28. Paragraph 13 is denied. It is admitted that on 6 March 2001 a meeting took place between Mr. Mohsan and Mr. Noble. At that meeting:
(1) Mr. Mohsan made no complaint at all of any alleged defective performance by the Claimant.
(2) Instead, he criticised the defective performance of Lynx, and identified that as the cause for the delay.
(3) He told Mr. Noble that the Defendant's staff had repeatedly complained about the performance of Lynx, but that he had heard no complaint about the Claimant's performance.
(4) He told Mr. Noble that trading conditions for the Defendant had deteriorated, and this had caused the Defendant anyway to lay off the staff that it had been planning to lay off when the new repairs management system went live.
(5) At Mr. Noble's offer to suspend implementation work for the time being, Mr. Mohsan agreed on the basis that he would have time to consider what he would do next.
(6) Mr. Noble and Mr. Mohsan then discussed, in an amicable fashion, whether it would be possible for the Defendant to sell its licenses to use ServiceAlliance to someone else, thus recouping some of the Defendant's cost of the abortive project.
(7) Mr. Mohsan made no mention of terminating any of the agreements between the Defendant and the Claimant and the agreements were not terminated at the meeting. In any event any purported oral termination would not have been effective to terminate them under clause 8.2 of the Software Agreement.
29. Paragraph 14 is denied. It was the Defendant, not the Claimant, that breached the agreements by changing its mind about wanting the software package it had agreed to take on license and requested the Claimant to implement. At all material times the Claimant remained willing to perform its obligations."
"It is irrelevant to consider whether or not the software delivered to the Defendant by the Claimant is of any value or use to the Defendant. The Claimant's contractual obligation was to licence and deliver the software, and it licensed and delivered it. Alternatively, the Defendant is required to prove that the software is of no value or use."
In relation to the alleged inability to make anticipated savings by reduction in numbers of staff it was pleaded that:-
"The Defendant has laid off the staff it was intending to lay off, and has therefore achieved the savings anyway."
The circumstances leading up to the making of the Contract
"I think we need a statement from Time as to what you will require live by 1st August. We cannot expect to get the whole lot up by then, so we need to know the minimum acceptable. For example, is the Tetra/CCC interface required to be in place by then? What modules do you expect to be running live on 1st Aug?
You will have to concede that if we do not get the project going this week/next, then the 1st August is not feasible, no matter whose system you had chosen. That is not a basis for negotiation, it is a basis for a practical, and possibly achievable, project – We will not agree to any contract we don't think we can deliver on – no matter what the customer may think as to our motives. If we say it is not possible, then you'd better believe it is not, because we will walk away rather than sign – no matter how much money is involved. The decision on such matters lies with Ian Mapp, our Operations Manager, not me."
"CCC" was how, at the time, Pulse was known. Thus the significance of the question whether the Tetra/CCC interface was required by 1 August 2000 was whether it was expected that the Integration Services would be completed by that date. In an e-mail of 16 May 2000 to Mr. Beel Mr. Brotherston made clear that Time was seeking complete integration by the end of July 2000. In a reply to Mr. Brotherston Mr. Beel indicated that the concern on Astea's side was with whether the Integration Services could be achieved by 1 August 2000.
"5. Payment terms shall be as follows:
1/3 on implementation date (see 6 below)
1/3 on delivery of software
1/3 on 1st September 2000 (assuming successful implementation by this date)
6. The date of implementation is 1 August 2000, which is a fundamental part of this agreement."
In his covering letter Mr. Brotherston requested that Astea sign and return a copy of the special conditions. Astea did not do so.
"I have delayed releasing this until Ian Dundas had completed his discussions with yourselves/Lynx on the feasibility of the interfacing tasks – seen as the critical path for this project. These are the key events/milestones for the remaining weeks. I have not produced a formal MS Project plan as the tasks are fairly straightforward – but I assume that you will be incorporating this into your overall planning for the management of Time resources.
There are two assumptions built in:
- there will be no electronic transfer of data from existing systems;
- we will assist in the definition of reports from ServiceAlliance, but Time will be responsible for their production.
(oh, and the contract gets signed!! I am sure Kevin would not want me to miss an opportunity….)
Week commencing 19 June
- Astea match documented process flows to ServiceAlliance to identify any potential gaps
(Resources: Astea – Nigel Vant)
- documenting of interface specification begins
(Resources: Astea – Ian Dundas)
Week commencing 26 June
- 3 day workshop to identify screen/business rule changes and follow draft ServiceAlliance processes
(Resources: Astea – Nigel Vant, Time)
- Milestone: confirmed processes
(Resources: Astea – Nigel Vant, Time)
- Milestone: agreed interface specifications
(Resources: Astea, Ian Dundas, Time Lynx)
Week commencing 3 July
- Coding work on interfaces begins
(Resources: Astea – Custom Development)
- 2 days of setup for production environment – database, clients
(Resources: Astea – Damon Bernd, Time)
- AllianceStudio work begins on changes, including knowledge transfer to Time personnel
(Resources: Astea – Nigel Vant, Time)
Week commencing 10 July
- Milestone: documented ServiceAlliance processes
(Resources: Astea – Nigel Vant, Astea – 2nd business consultant, Time)
- Milestone: training materials produced
- Milestone: Reporting Requirements Defined
(Resources: Astea – 2nd Business Consultant, Time)
- Project Review Meeting
(Resources: Astea – Ian Mapp, Nigel Vant, Time)
Week commencing 17 July
- delivery /testing of interfaces begins
(Resources: Astea – 2nd business consultant, Time, Lynx)
- user training begins
(Resources: Astea – Nigel Vant, Time)
- manual data loading begins
Week commencing 24 July
- Milestone: User Training completed
(Resources: Astea – Nigel Vant, Time)
- Milestone: Interfaces signed off
(Resources: Astea – 2nd business consultant, Time, Lynx)
Week commencing 31 July
- Milestone: System signed-off for production
(Resources: Astea – Ian Mapp, Time, Lynx)
- Milestone: Cutover to ServiceAlliance
(Resources: Astea – All, Time)
- live running initial support
(Resources: Astea – Nigel Vant)
Week commencing 7 August
- Project Sign-off meeting
(Resources: Astea – Ian Mapp, Time)
Please confirm your acceptance of this schedule, so that final arrangements can be made."
It does not appear that Time ever did confirm its acceptance of the schedule.
"I have just spoken to Astea and they appreciate the effort that has been made to complete the contract details in time for the end of month deadline.
Work is already progressing well and we have the technical design spec for the integration from Lynx, which both Astea and Lynx will be discussing at H/O on Monday.
However they need the contract to be dated for the 30th June 2000, as this is the last day of their current quarter.
If you have an opportunity to review the contract document, that Richard Hope has produced in conjunction with them, they need it faxed to their USA office on Monday.
The key requirement is for the date to be as given above.
I am assuming that there are no remaining issues with the contract, as Richard seems confident that all aspects have been covered.
I hope you will be able to sign the document over the weekend."
"We seem to have reached an impasse with the Astea contract.
My understanding is that whilst they are happy for their US parent to guarantee the UK contract should it become necessary, we have extended the contract obligations through our wording of the guarantee.
The US CEO cannot sign the document he has been presented with at present.
I am not sure if you have prompted this extension of the terms or if it has crept in through the interpretation of the legal wording Richard has produced.
Astea UK are still working at the speed we need but I think Pat Noble is getting worried that the US may instruct him to hold back until the contract is signed.
Will you please give this some thought with an aim to resolve today if at all possible."
"The work involved to provide the Astea integration is 45 days development plus 5 days consultancy/training; total 50 days. Hence the cost of this project will be (45 x £550 plus 5 x £650) £28,000.
As I have already asked our sub-contractor (VI Software) to commence work on the project in order to meet the required timescales I would appreciate a prompt purchase order."
"Has there been any development on this front? If so, how does it affect current priorities, all the focus for the last 3 days, Friday, Saturday, Sunday has been on Pulse and CS/3 – no work done on Service Alliance."
Mr. Anyon, who gave evidence at the trial, told me, and I accept, that he himself was diverted from doing any work in relation to the Software during the month of July 2000 and for half of August in order to concentrate upon the more important, from the point of view of Time, issues concerning the problems with Pulse and CS/3.
"Derek has advised me that they have now agreed to put the live date back to 1st September (partly because of the delays on Lynx's side and because of the contract signing delays). I think we should not press them to amend the contracts that should be signed today. In the event that the contract still says 1st August, we get them they [sic] send a separate letter stating the change in deadline. Otherwise we will get further delays in getting the contract through.
Do you agree?"
Mr. Noble did agree, as he made known in an e-mail to Mr. Beel dated 24 July 2000. In that e-mail he asked Mr. Beel to press Mr. Brotherston to send Astea a letter to the effect contemplated in Mr. Beel's e-mail dated 13 July 2000 so that it was clear that Astea was not in breach of contract. No such letter was ever in fact sent, and the matter was not pursued on behalf of Astea.
"Until we have a system that will work on Monday, I cannot spend any more time on Astea as it will prevent me from completing my other work."
Mr. Brotherston replied the same day, so far as is presently material:-
"Don't worry about your time and Astea, I have put them on hold for next week anyway so that we can re evaluate our time commitments."
"thinking about the discussions we have been having last week at Time in Burnley, I feel that it would be good (given that we have a deal by then) to plan Marc Tonen (or someone with similar qualities) for 1 or 2 days to work on some of the issues. Some of the AllianceStudio changes [i.e. configuration] are not difficult, but we also have hit difficult ones where expert level would be welcome. I believe that Marc can do all that work without being on site.
Are you doing the planning for Time? Can you then take this into account? Please consider that I will also be needing Marc for some WMData work very soon after his holiday ends (problems with invoice interface to their accounting system)."
"We are looking at some ServiceAlliance custom work to develop some interfaces to a customers Fiancancial [sic] and Call Centre applications. This work is specified and ready to go now. We have hit the vacation season here and do not have anyone available to start this work soon – do you have anyone by chance?
A speedy response would be appreciated (I guess that you don't have to think too hard!) so that we can look at other alternatives if necessary."
In fact there were no spare resources. Mr. Mapp was cross-examined about this e-mail. He explained that he was exploring options. While it was correct that all of the programmers working for Astea in Europe must have been occupied with other tasks, he could re-deploy some one or more of them. He could also bring in resources from outside, although Mr. Noble told me that that was not really an effective option for work of integrating the Software with other software because a good knowledge of the Software was necessary for that task, which an outside contractor would be unlikely to have.
Progress between the signing of the Contract and the installation of the integration software
"I am getting concerned that we do not seem to have re-established a proper project plan for the implementation of ServiceAlliance since the initial delay. Nigel is continuing to work on a week by week basis, but this will certainly result in missing the present 1 September target. I understand that other projects are dragging on resources, but I would like to create a more formal workplan.
Can you let me know whether the September date is still valid, and the availability of Time resources? Or should we be considering a postponement? I have run into a period of holidays for various of the consultancy team and I need to make some decisions regarding priorities between projects."
That e-mail, as it seems to me, put the point very fairly to Mr. Brotherston. He responded the same day:-
"I share your concerns and, as you may remember I am on holiday from the 12th for two weeks.
Being realistic I think we should plan to implement the full system on the 11th September and then go live on the 18th
Will that work for you?"
- "Determine the user platform, requirements, and traffic to identify real hardware requirements including fat, thin and concurrent users.
- Test the current available hardware that exists with the service alliance package…
- Set up a test network utilising the proposed hardware solution….
- Complete specification of integration/interfaces and produce a prioritised list of additional requirements to inc. Accounts
- Review the details of the integration/interfaces spec and agree a testing plan….
- Produce a project plan."
All of these activities required a contribution from Time. The first few action points all revolved around the selection and installation of appropriate computer hardware to permit the Software to run once integrated with CS/3 and Pulse.
"…aims to go live on 18/9/00 with parallel running for 2 weeks leading to cut over on 2/10/00. The critical aspects are integration and completing the business process detailed workshops as intake volumes are likely to increase considerably during October."
He told me in cross-examination, and I accept, that the business process detailed workshops referred to were a matter for Time internally to deal with.
"The requirements for all hardware required by Service Alliance, and its configuration were agreed by Zuber and Steve Devibe [sic – in fact Devine], before we started this project.
Zuber has seen and agreed the spec as listed in Ian Dundas' proposal which dates back to May/June.
The only point was that the client systems really need 128MB of ram and ours have 64MB, however Ian confirmed that this would only effect [sic] the speed of operation.
There has NEVER been any mention of a clash of architecture.
I am now surprised, confused and concerned!"
"1. The overall project is significantly over the budget that was agreed.
2. The data conversions which we are still coming to terms with went badly wrong. I have just been told that just last Thursday we got a new file for the Archives.
3. The locking issue was a problem that brought the company to its knees with up time averaging about 2 –3 hours a day for the first 2 – 3 weeks after launch.
4. The current performance issues, although appear to have disappeared, need to be identified and fixed. I assume based on what you have told me that service pack 2 from MS will fix this.
5. I am deeply concerned still that we do not have a system which is true client server. Despite repeated assurance from Sage Tetra, I remain to be convinced. Issues such as no waiting message or the "hour glass" add to my fear.
6. Because of the significant locking and data migration issue, we have significantly increased costs from our third party contractors such as the pulse system.
7. I am told that over the past two weeks, the Application servers have rebooted four times with the latest being Wednesday. I cannot see how you can call the system performance satisfactory if this is happening.
8. Phase 2 is significantly late due to the above issues."
"The problem is that due to the high degree of problems with CS/3, Pulse and EPOS nobody has been interested in Astea until now. Steve Taylor and I need this system to be in and working for the end of the month, it is not some form of nice add-on, it is an essential requirement for our service operations."
"Steve we are now at an advanced position with Astea and on track to implement by the end of September;
- essentially we (the users) have completed 98% of the functional spec and process design which is fully documented
- the integration spec has also been agreed with a few questions left to be clarified, this will be completed on Tuesday 5/9 ready for sign off (integration development has now been started by Astea)
- the hardware platform/configuration/spec has been agreed between Astea, Zuber and Derek
The critical point now is setting up a production network using the agreed configuration, this is essential to allow us to set up the Service Alliance data, products, customers and warranties and to carry out functional testing.
We need to start setting the system up on Monday 4/9 and therefore must have the production network in place ASAP. I understand Paul Mangham needs a day to do this. If this cannot be achieved delays will occur that will have a significant operational impact."
"I now have the signed copy of the hardware spec. document from Astea.
Given that this can be agreed at the meeting tomorrow (9.30) can we get the hardware together in time for Astea to attend on Thursday to configure the system?
We have a "go live" date of the end of September so we need to be installing the actual hardware that will be in use and not a small, dummy network.
The consultant from Astea will be coming from Holland so I need to let them know as soon as possible if we will be ready for him or not.
Please let me know by return."
The response was evidently that the hardware would not be ready and the attendance of the engineer should be cancelled, for in an e-mail of the next day to Mr. Zuber Mohsan Mr. Brotherston confirmed that he had cancelled the visit by the engineer and asked when the hardware would be ready. He pointed out that any delay beyond the end of that week would compromise the "go live" date then in contemplation.
"Given the developments today regarding delays to hardware and lack of Time resource for integration we will need to rethink the implementation dates. In order to do this I need some commitment to actual delivery dates from Steven [Devine] and Zuber."
"Derek I was in a meeting this morning regarding how returns would be handled in store and pointed out that Service Alliance would probably be the solution but may not be until next year. Steven Devine said he was very nervous about being able to go live with Service Alliance in 3 to 5 weeks.
I am also getting exasperated with the apparent lack of will to achieve our deadline.
For now we will continue to do all we can, however I am on holiday next week and wont be around to fight. Keith [Anyon] will also be away for another week. I know you will be pursuing our joint cause…"
Mr. Brotherston replied the next day:-
"I think we are all nervous but there is nothing to loose [sic] by going for it anyway. It is disappointing that it is just the two of us that want the system in!
If we we [sic] sensible we would postpone until Zia, Tahir and Steve Devine are ready to support us."
"As outlined in James Spencer's letter of the 30th August, I am extremely concerned that your account is significantly in arrears. Whilst I recognise that Time Group Limited are a major and very important customer you nevertheless currently owe us in excess of one million pounds, of which over five hundred thousand is overdue (please see attached schedule). As you will appreciate this is not a situation that we can allow to continue indefinitely. That said, we recognise that a project of this nature is complex and difficult and as a reflection of our continued commitment and a demonstration of our consistently reasonable approach we are willing to accept, as you have already discussed with James, a payment on account of £200,000. Provided we receive this by Tuesday of next week (12th Sept) we would be willing to discuss a schedule of payment for the balance, and upon (and only upon) agreement of a new payment schedule, we would consider this to be an accepted amendment to our contract with you.
I am also aware that there is a significant amount of Adaptus bespoke work that has for some time been expected to start in September or earlier and that we do not currently have a purchase order from you for this work. Any further delay in raising a purchase order will make it more likely that this critical phase in the project will not be delivered within your desired time-scales. I therefore request that you send to us by return your written confirmation to proceed with the Adaptus work, together with your payment on account of £200,000."
In fact the proposal set out in the letter was not acceptable to Time. Relations between Lynx and Time continued to deteriorate such that Lynx threatened to activate a time lock on CS/3 unless it was paid the sums which it claimed were due. On 1 December 2000 litigation was commenced on behalf of Time against Lynx seeking damages for alleged breach of the contract between them and, in particular, an order that Lynx be restrained from acting upon the threat to activate the time lock.
"The Lynx system was supposedly designed to support a minimum of 2,000 users. At the "go live" on 28 July 2000 we had about 400 users. Even so, at "go live" there was a serious problem with the system going slow and locking e.g. on 25 September the cancellation of a particular order took 22 minutes. This should have been accomplished in one minute. Despite the efforts of Lynx "locking" has remained a persistent problem and continues to occur to this day. In the weeks following "go live" the system would slow down to the extent that it was almost unusable with the result that telesales, administration and dispatch operations would frequently come to a halt. Lynx has put a lot of resources into trying to resolve the locking problem and it has gradually improved but remains a significant issue. For example the batch release operation and picking list print operation are creating deadlocks within telesales and administration. Typically batch release and picking list print take about an hour to run. Frequently, when those programs are run, there will be a locking problem. This may manifest itself in the locking of the batch release or picking list print operation or the locking of either individual users or groups of users. Whichever operation is "locked out" has to be re run from the beginning. Lynx acknowledge that this problem persists and are due to provide yet another fix later this week."
"I am being chased, twice a day, by Astea for payment of their invoices.
They have now invoiced twice for the software, one for two thirds and one for the final third. The second is not due as the system is not yet in and working.
However the first is well overdue and we must pay it before it affects the implementation process….
There are other invoices due for other items included within the implementation but they are of lesser amount and importance…"
"With regard to Astea/Service Alliance, I am, on the one hand pushing them to commit resource to setting up the new hardware and trying to meet our deadlins [sic] and on the other receiving no help at all from Tahir with regard to paying their outstanding and overdue invoice.
Can you help at all?"
"The projects in danger of stopping if we do not move quickly, please let me know what you would like to do."
"Will you please give the issue of Astea some serious thought and then let me know how you would like me to proceed.
We have currently come to a halt and need to get moving as soon as possible.
My recommendation is that we pay the first third of the licence cost and then review the rest as your confidence in the product builds.
I need to be able to plan our next stage and at present am unable to.
I will happily pass any message on to Pat if you let me know how you would like to proceed."
"We will lose this week as well unless I can make arrangements today, as we stand at present there will be no Service Alliance activity this week."
Mr. Tahir Mohsan in fact accepted the recommendation of Mr. Brotherston as to the way forward. Mr. Brotherston put the proposal to Mr. Noble. He reported the reaction of Mr. Noble in an e-mail to Mr. Tahir Mohsan sent on 27 September 2000:-
"I have spoken at length to Pat Noble this morning.
I have put to him your proposal that we pay the first third (£58k) this week with the understanding that we need to see the system working before the second payment is made.
He is concerned that he has no control over the interfaces being produced by Lynx or our Pulse team and that these are required to demonstrate a "working system".
He proposes that they install the software, load data from CS/3 and produce a working test system which will demonstrate the full facilities to the full user count.
I have told him that he needs to meet with his developers and Lynx to further discuss the interfaces as I am sure there will be issues here in the same way as there have been with Pulse and Epos.
Pat wants to continue to commit to the project and will work under the proposal we discussed."
Payment of the first one-third instalment of the licence fees was made on 2 October 2000.
"Development should now be completed however I still do not have the basic functionality I need to be able to manage customer contacts in Q4 [that is, the months of October, November and December 2000]
The outstanding issues include the following:-
Speed – Nobody can confirm whether speed is a network or software problem….
Run time errors – still occurring on an ad-hoc basis; staff being thrown out of the application apparantly [sic] randomly…
Missing records – the overnight update (of notes etc) does not seem to happen regularly.
Proactive sales – seem unable to see previous accounts, therefore create new records for new sales transactions. This then knocks on to the CCC and makes our attempts to support the customer very difficult.
We cannot search effectively by postcode….
Reports – I still do not have access to reports despite regular chasing…
At the moment the application is not suitable for supporting anticipated winter traffic.
I know people are working hard on this, but I need to see some progress quickly please."
- "Feedback on RMA acceptance by Service Alliance to Pulse still needs to be defined. There are several options including an error log and/or E-mail or separate error monitoring application/process etc.
- The Interface Table that was originally in the Pulse Database will now be in the Service Alliance Database….
- Existing Notes for customers will come through as Customer Attachments in Service Alliance i.e. the Notes will be viewed against the customer details
- New Notes will come through as a Repair Order Attachment.
- We agreed that we would DTS the following:
- Companies 2 & 7 data.
- The last 3 months of the rest.
- The link from Service Alliance to Time's Despatch process in CS/3 will be controlled by Service Alliance…."
It is apparent from the list of "Discussions and Decisions" that a number of important matters were only considered for the first time as between Time and Astea at the meeting of 5 October 2000. In particular the question of communication between the Software and Pulse that an RMA had been actioned was recorded as an issue requiring definition, while the interface table between the Software and Pulse, previously intended to be in Pulse, was now to be in the Software. The significance of the references to Notes is a matter to which I shall return later in this judgment. "Companies 2 & 7" were Time internal code for business and educational customers, that is to say, those for whom service at their own premises was provided and which were thus a main focus of the operations of the Service Centre. The "others", essentially ordinary consumer customers, were coded by Time 1 and 4. As matters unfolded the transfer into the Software of data in relation to the last three months of transactions with such customers proved of some difficulty.
"With reference to our telephone call of today, I am confirming our total dissatisfaction in the way the CS/3 system has been implemented.
The performance is almost non-existent with effective downtime of between 4 – 6 hours a day. As you are also aware, the despatch label must have the correct detail on them and also have the ability to despatch from the Blackburn warehouse. These are just some of the hundred or so issues which must be delivered.
We are now in a desperate situation and require urgent action.
I am expecting you personally to be on site until all these issues are fixed. Also, I need a plan of your staff cover for the month of October so that we can plan through this together."
"Astea Integration work
- It was required that more resource should be assigned to this task to allow for completion by the end of October. Nigel Vant has spoken to Ian Map [sic], Ian will respond by Monday, 16/10/2000 with a schedule….
- Installation of all 5 parts of the Integration work Monday, 30/10/2000…
Outstanding Programming issues
- Khalid spent time with both Stuart and Mike Bredbury to resolve any issues he or they had, he was happy that all his points had been addressed and that he now had a point of contact with VI."
The target date for installation of all five parts of the integration work of 30 October 2000 set out in the minutes confirmed the date for that operation in the revised project plan prepared in advance of the meeting of 5 October 2000.
"Thank you for the work schedule.
I am rather surprised at the time scale.
Our original "go live" date was August, which was moved (through our needs) to the start of November. The interfaces between Service Alliance and both Pulse and CS/3 have not changed in specification since they were agreed back in July. I can see no reason why the work has not been completed; as it would have been needed two months ago had our deadlines not moved.
Khalid seemed unaware of some of the specification documents, when we met last week and also seemed to have only recently started the work.
I do appreciate that there was a two-week "hiccup" in activities whilst we resolved the contractual issues but this does not add up to the delays you are now suggesting.
We will not be able to implement new software and interfaces at the end of November as we are already into the quarter of the year where no changes are allowed to any mainstream system (due to sales activities). We have negotiated a degree of latitude on this matter for the sake of implementing Service Alliance but this will not be extended into November.
The Customer interface, RMA generation and Product file synchronisation are essential modules that must be in place and ready for testing by the 30th October as put forward at the last meeting. If this cannot be achieved we will have to reassess the feasibility of installing SA this side of February 2001.
I do hope you are able to commit resource to prevent us having to take this damaging decision."
"Recent notes are added as an attachment to the repair order.
Long history notes need processing as an attachment to customer.
Notes are going to be read only.
Additional processing for "SUSPEND".
Additional field "order number" to be passed to interface for reference purposes.
Upon shipment need to trigger a Time Computers DLL to print out labels and return a consignment number to store in the shipment document.
Mr. Noble sent that list, which was accompanied by a list of information which Mr. Elbarjaj required from Time in consequence, to Mr. Brotherston as an attachment to an e-mail also sent on 17 October 2000. Mr. Brotherston replied the same day:-
"The inclusion of notes was always in the original spec.
RMA suspend status is an addition and not essential.
Passing the order number has become essential but is an addition and we may have to live without it on day one.
The customer interface is as specified in the original documents as discussed between Ian Dundas and Stuart Marshall some time ago. The use of APIs as apposed [sic] to stored procedures should not have suddenly appeared last week.
We have, as you know a serious deadline issue and I think you need to find the development resource to deliver the integration, as originally agreed, by the end of this month.
I am sure there will be many areas that need further attention but it is essential, for both companies, to get the process working to a reasonable level by this time."
"I have spoken with Pat Noble and generally agreed the 30th as a testing date as proposed at the last meeting.
There are some issues with eaxtra [sic] work that we have "slipped in" and a need for some information. In particular they need the DLL which handles the despatch label system and the Stored Procedure from Lynx/VI for the customer interface.
Please will you arrange for them to receive these."
"I confirm that we still expect to deliver before the end of October. I am copying this message to Khalid to ask him to leave out the functionality which you have agreed to be changes below. We can revisit these items after delivery as additional work. Please note that we are still waiting for the DLL for the label printing and the stored procedure for doing the update. The later the arrival of these items, the more risky is the delivery date.
It seems that the situation regarding the notes is a little grey. We originally specified that notes should be added to the transaction log, but with further information becoming available, we think this will not be practical and hence have discussed the use of attachments. We are hoping that we can deliver the new functionality on time but this is at risk since it is not fully specified yet."
"As of midday today, we have still not received the stored procedure for retrieving customer information, nor the DLL to enable label printing. Khalid has completed initial coding of our interface code and is planning to commence testing of his work on Monday. The unavailability of these components means that Khalid would have to test without them, and given our timescales, the delivery date is now already at risk. Furthermore, it increases our workload since we would now have to test twice. Can you let us know as soon as possible when we can expect these deliverables since we may be better off delaying the commencement of testing until we have received them."
The terms of the report certainly suggest that, in the event, the amount of work which Mr. Elbarjaj had to undertake on the interface between the Software and Pulse, estimated originally at 20 days, had been less than anticipated.
"This means we will install Service Alliance up to the point of Despatch and then add Despatch Process Integration when it is completed."
"Following your conversation with Derek, he has asked me to mail you confirmation that we will accept delivery and installation of tested integration programs on Monday, 6/11/2000. This has moved the delivery date back 1 week. It is essential that we have a test plan for this software and need to be led by yourselves as to how we structure this.
We will have our Pulse work completed to the original timescale, (Jon Cleaver) and the work that needs completing by VI should also be in place as originally scheduled. (Allan Darlington – VI).
The Despatch work, at this end, will proceed as soon as the Pulse work is completed and Time resources become available (Jon Cleaver & Chris Warner). Ideally we would need to be ready to install as soon after the Service Alliance package is up and running to minimise the amount of time using a manual despatch system."
"Just so that we are clear, in case the issue is raised in the future, we had planned to deliver by the end of October, which is next Tuesday. This is quite a complex interface and we therefore had planned to be testing by Monday 23rd October at the latest. In the event, and despite many reminders, we had still not received from you critical information regarding the method of retrieving customer data from Pulse until that date so could not even complete development. You then changed the method of retrieving data from stored procedure (as described in the specification) to view, and this has caused a further delay to do research since we have not used this mechanism in PowerBuilder before. The delay is thus 3 working days which is totally attributable to the late supply of information and change to specification."
Mr. Anyon's response in an e-mail of 28 October 2000 was rather defensive. The effect of his reply was that:-
"…if many reminders had been sent, they were not sent to me.
2. The change of specification for viewing in Pulse, I will need to discuss with Jon Cleaver, Monday morning, to determine how much this has changed from the original specification."
Mr. Noble replied in his turn also on 28 October 2000. He set out the e-mails in which reminders had been given and concluded in the light of his review of those e-mails that in fact the fault lay with VI.
"Having reviewed the status of the Time interface today, I do not think that it will be ready to install until Wednesday next week. The principle [sic] reason for the delay is that one of the developers, Carlo, was off sick for 5 days. Given the timescale for the studio work, would it be a good idea to inform Time that we will be on site on Wednesday to install everything and that Khalid and Keith [Louden] will then remain there for the remainder of the week? If so, could you inform Keith Anyon accordingly."
Mr. Mapp passed on the news to Mr. Anyon in an e-mail dated 2 November 2000. Mr. Anyon accepted the position that there would be a delay to the commencement of the installation of the integration software until 8 November 2000, as he indicated in an e-mail dated 3 November 2000 to Mr. Mapp and others.
Events after installation of integration software
"Things that ASTEA needs to do for the integration testing.
1) Configurations – this requirement has not yet been implemented with regards creating the installed base per the BRD.
2) Multiple line items/products per BDR [sic] (repair order) functionality needs to be enabled in the ASTEA interface. Khalid had assumed that there would only be one product per BRD.
3) Time have changed the requirement from maintaining history notes in the transaction log to maintaining them as customer attachments.
4) There is an additional requirement to make Customer/Swan notes view access only.
5) The already identified customisation for an additional field to identify the total boxes delivered is outstanding.
Apart from the above requirements that will require to be enabled, I understand from Khalid that the ASTEA set-up is complete and awaits testing.
It is guestimated that from informal discussions which await formal confirmation that:-
1) Pulse will be set-up and ready to test by Next [sic] Monday.
2) Tetra/CS3 – from talking to Keith Anyon Tetra are set-up and are ready to test after the initial data-load to Service Alliance has been completed…"
"Confirmation of status
Khalid has finished – total boxes value
- multiple repair order lines
these will be delivered/installed on Thursday/Friday and testing commenced. His flight arrives at 7:40 and Nigel is collecting him from the airport.
Work on configurations can continue once testing is underway.
We are waiting for a DLL from Jonathan for the despatch process.
The question of timely confirmation of Repair Order creation is still open. It is still not clear how we can implement this in a way that gives you a positive result quick enough. We have implemented the functionality as described in the specification, and Derek agreed explicitly with Pat Noble that initial delivery would match the specification. We have moved on this position for configurations since it is fundamental to the core business process, but I consider that this confirmation does not fall into the same category."
"I have spend [sic] a considerable amount of time this afternoon in conversation with Keith Louden trying to get Service Alliance set up on my machine for testing.
I find that I do not have sufficient rights to do a lot of the tasks that I am being asked to do. I also do not feel I have enough experience to deal with many of the issues that are coming up. This is a difficult task to do with a person on site, it is even more difficult to try to do it over the phone.
We should be doing this either with an Astea person on site or, through Jawaid who is the System administrator."
"Keith Louden will be there on Monday (although not till mid-morning), and the plan will be:
- to uncover any error records from the data synchronisation (you will probably start on this anyway)
- to install the latest software for the RMA Engine machine
- to structure a series of tests that will cover all foreseeable circumstances of the interfaces
- to execute those test [sic] in conjunction with yourselves
- to liaise with Khalid if changes/fixes are required."
Although he duly arrived, Mr. Louden only remained on site at this stage for a few days. He returned the following week.
"We seem to be making very slow and painful progress at the moment.
I have not heard from Ian since we last spoke although I know the [sic] Keith and he have been in communication.
I have great concern that with the current approach we will never have the system implemented.
We really need a consultant/Developer on site.
What are your views on how we can finish this project off?"
Mr. Noble replied the same day:-
"To be honest, I would have put Khalid on site by now but it is Ramadin (don't know if spelling is correct!) and he is VERY reluctant to travel. We have another developer in the Netherlands office and I am arranging for him to get up to speed this week so that he should be available to come on site. In the meantime, we have allocated Nigel to you for the remainder of this week to try and move things along. We will review the position during this week and determine actions accordingly."
"Unfortunately Khalid is leaving Astea so we have had another developer, Carlo Alberding, working with him on your interface for the last week. Please communicate all issues with Carlo from now on until further notice. We do have another developer starting in the UK on 2nd January and plan to transfer the responsibility again during the first half of January. This will make it much easier to provide on-site assistance from that point."
The developer referred to as starting on 2 January 2001 was in fact Mr. Peter Shergold. Although his employment with Astea commenced on 2 January 2001 Mr. Shergold told me in evidence that it took him two or three weeks to become familiar with the Software and it was perhaps another couple of weeks before he was fully on top of the work which Mr. Elbarjaj had been doing to integrate the Software with CS/3 and Pulse. At all events he did not visit the premises of Time in Burnley until 23 January 2001. However, he was corresponding with Mr. Anyon by e-mail as from about 11 January 2001.
"We had a meeting with Stuart Marshall of VI. It was agreed that they would now be available for you to contact with issues regarding the integration. It would be worthwhile you and Peter establishing contact with them today to make introductions for Peter.
I am still testing issues the VI side of things and I hope to finish today. If I have outstanding issues I will be contacting VI with these at the end of the day. I will give you an update at this time."
21 February 2001
Initial Data Load for Testing
- Products load complete
- Customers load complete.
- Installed Base (Customers and Invoiced Items).
- Site creation for customers with different Invoice and Delivery Addresses (VI Proposal)
- Modification work on Serial Numbers almost complete (VI).
- Warranties to be attached to Customer Items.
RMA creation, according to Astea (as of Friday, 16/02/2001)
- Address Data mismatch in Pulse causing the RMA to fail.
- Serial Numbers being worked on by VI needed to complete the creation.
- Process testing to be done.
- Not currently working in Astea – to be worked on after the RMA process is completed.
Customisation and Toolkit changes.
- Some are done more need to be done.
- Work done by Jon Cleaver, needs to be linked to Service Alliance.
Feedback to Pulse
- Work done by Jon Cleaver – needs testing once the RMA process is working.
Hardware Set up for Testing
- Dependent on the above work being completed
- Dependent on all above.
- Priority that Time gets from Astea due to length of time the project has overrun.
- No delivery – no payment to Astea.
- Number of Astea staff available.
- Initial Development work done in Holland.
- Much of the work done remotely, very slow process.
- Staff turnover at Astea – 3 developers have worked on this project at different times.
- Loss of staff here – Jon Cleaver."
On its face that report seems to indicate that the principal matters outstanding at that time before the Software could become operational were the problems with the validity of the RMA data offered to the Software, and integration of the Software with work done in relation to Pulse. Mr. Anyon told me in cross-examination that the list of "Concerns" which he set out was not a list of matters which necessarily were currently of concern at the date of the document, but a list of any matters which had ever been of concern to him during the project.
"Staff savings 1 in QC
3 4 Allocation
£200k +VAT £250 inc VAT"
The words written seem to indicate that possible savings in staff of the order of four or five were considered at the meeting. In very broad terms the monetary figures set out may have represented the sums outstanding due to Astea as at 21 February 2001 in respect of unpaid invoices. However, Mr. Mohsan's evidence was that he was not, in the notes he made, carrying out a comparison of staff savings against the cost of the Software. In the end no clear explanation was given by Mr. Mohsan of what the notes which he made in manuscript were supposed to relate to.
"I do recall the meeting in the afternoon of 21 February, called by Tahir, the review the status of the Astea project. I think this was because the system was not live and he was also being pressed for payment of the outstanding invoices. This meeting was held at the head office in Burnley and lasted about an hour. While I cannot remember the meeting very well, I recall that Steven Taylor, Michael Flannagan, Steven Devine, Carol Newby (a TAG team member and a systems person who is now married to Tahir) and, I think Zia Mohsan, attended. At the meeting the ServiceAlliance project was discussed. Tahir ran the meeting and it soon became clear that the main issue was to decide whether to finish the ServiceAlliance project, which would entail having to settle the outstanding costs of around £200,000. Tahir said alternatively if we did not proceed with ServiceAlliance this would leave the sum of around £200,000 which was the cost of employing a number of staff. He explained to us that in Time's current financial state we either spent the money on staff or on the software. There was no discussion at this meeting about the quality of the product that had been installed, or the go live date, and no one believed that full implementation could not be achieved. I cannot recall every detail of the meeting but the feeling was that the project was nearly there, and it was a shame that it had not gone live. However when faced with that choice of paying Astea or keeping staff the decision taken by Michael Flannegan and Stephen Taylor was to keep the staff. It was accepted that the money was owed to Astea but simply the choice was an economical one. Tahir then said that he would have to talk to Pat about the money and what could be done and asked me to arrange a meeting."
It seems fairly plain that Mr. Brotherston's recollection of the meeting which he described is not accurate in relation to the persons who attended a meeting at which both he and Mr. Tahir Mohsan were present. Mr. Mohsan's "Action Sheet" for the meeting listed the persons attending as I have recorded them. Mr. Taylor, Mr. Flanagan and Carol Newby were not listed as attending that meeting. Later the same day a meeting took place between Mr. Flanagan, Mr. Taylor, Mr. Keith Bond and Mr. Anyon notes of which made by Mr. Anyon and to which I shall refer later in this judgment. Mr. Brotherston seems to have conflated more than one meeting in his recollection, although he did not actually attend the meeting of which Mr. Anyon made notes.
"On or around that time I hade [sic] been informed by the TAG team members that the ServiceAlliance system could take another 3-4 months to implement and "go-live". I was told that people at Astea kept changing and that the view was that Astea were not sufficiently resourcing the project. The members were also concerned at the level of change in the Astea personnel. I appreciated that the cost of ServiceAlliance would be significantly in excess of the budgeted figure of £60,000. I became very concerned about the situation. From what I was being told the project was likely to be almost 10 months behind target, budgeted costs were likely to be materially exceeded and there was no guarantee that ServiceAlliance would work. Time no longer had a need for the number of licences originally envisaged. Furthermore, given changes in the PC market the level of cost savings that had been envisaged in July 2000 could no longer be achieved and the return on investment was far less. Derek states that there was no discussion at this meeting about the quality of the product that had been installed or the go-live date. This is completely untrue as these were particular matters that were discussed. I also take issue with the assertion that rather than paying Astea, Time decided to keep staff instead. Irrespective of whether there was a downturn in the market if the ServiceAlliance implementation was working Time would have been prepared to pay as it would have made savings through cost reductions. However, as far as I was concerned Astea were in breach of their obligations to deliver a working system and I had lost faith in their ability to deliver a working system within a reasonable time frame."
"The meeting was called for the following reasons:
1. Identify requirements, from Pulse / CS/3 and other systems to allow the Service Centre to function effectively, without the benefit of Service Alliance.
2. To review any significant problems caused by developing Pulse as a replacement.
The main requirements from Pulse/CS/3 and Other for Steve Taylor are as follows:"
There followed a table setting out for each relevant area of the Service Centre Mr. Taylor's requirements, the reasons for those requirements, and the benefits expected to accrue from satisfying them. In total benefits identified included saving 6½ full time staff positions. Below the table the notes went on:-
"The following are the major functions that would be lost by not having Service Alliance.
- Repair Demand Balancing
- Changes to the Configuration of Customer equipment after the Repair
- Capture of Labour and Material cost of Repair.
- Specific Service Centre Stock Management
- Component usage analysis by Engineer
- Component reliability analysis.
Concerns with switching to Pulse
- Reliability of the system
- Level of support if there are more users."
It is, in my judgment, pretty obvious that the outcome of the meeting attended by Mr. Tahir Mohsan was an instruction from him to Mr. Anyon to consider with appropriate colleagues what would be the implications of not continuing with the Software and to report back. The notes were described in a Lotus Notes document produced by Mr. Anyon as "Minutes of Meeting to discuss the Service Centre requirements if we do not use Service Alliance". There was no suggestion in the notes that the Software was inappropriate or unsuitable, or would not be ready soon enough to meet the then requirements of Time. Rather doubts were expressed as to the reliability of Pulse if it was sought to develop it as a substitute for the Software. What at this stage Mr. Mohsan wanted to know was what disadvantages would follow from not continuing with the Software. What advantages would follow was another question.
"Pat Noble has called me a couple of times in order to establish the agenda/reason for his meeting with you on the 6th.
I have told him that you would like a progress review discussion with him.
In response he has committed extra resource to the project so that he has more to demonstrate in the way of finishing the project before you meet!
I do not want to pre-warn him of our intentions but do not think it is correct that he digs an even bigger hole for himself over the next two weeks.
I know that he has gone out on a limb for me and for Time and convinced his bosses in the states that everything will be ok.
I don't feel this is going to end up too well and may significantly damage his own standing in Astea. Let alone his relationship with us.
What can I tell him?
Please give this some thought and respond as soon as possible."
Mr. Mohsan did not in fact respond, but it is plain from the terms of Mr. Brotherston's e-mail that by the date he sent it he was aware that Mr. Mohsan had decided that he wanted to try to get Time out of the Contract and he, Mr. Brotherston, was concerned that Mr. Noble should have some idea that that was the real purpose of the meeting of 6 March 2001 before that meeting took place.
The meeting of 6 March 2001 and the aftermath
"Almost there with the Interface. But have been there before.
Issues with invalid data …. validation.
Transferred RMA 4 a week ago.
Almost there in terms of delivery.
Booked …. of the £200k last year."
Where gaps are indicated Mr. Mohsan was unable in the witness box to read his own handwriting.
"45. The meeting was held in a boardroom next to Tahir's office, and only last[ed] an hour or so. Tahir started the meeting, and explained firstly how difficult the market was for personal computers. After some further pleasantries, Tahir then asked me "where do you think we are with implementation?" I responded by saying that I thought that we were nearly finished, all of the systems had been implemented and we were just going through final testing. Tahir asked me at that time how much longer I thought it would take to implement in total, and I said that with VI and Pulse co-operation it may take 2-3 months for testing and go live. The reason I gave this kind of time scale was from experience I know that it takes that long for staff to be trained on a new system, though the pace of the training programme would be dictated by Time with input from Astea as and when necessary. Until such time as Time was happy with working on the system, it was not ready to go live.
46. Tahir informed me that he had recently made a number of staff redundant because the market for PCs had collapsed as it was saturated and there was no incentive for customers to upgrade as there was nothing new on the market. This was true, as evidenced by the reported difficulties experienced by other companies in this market. Tahir said that he had been gearing up the business, but realised in time that he had got it wrong, and as a result had rapidly reduced his cost base. He commented to me then that Tiny Computers had made a mistake by continuing to gear up, and failing to respond to the market slowdown. As a consequence of this situation, Tahir did not think that the projected savings of ServiceAlliance forecast in March 2000 were going to be realisable following implementation of the system. Tahir said that when he had started the project this was against a business plan of substantial growth of the Time business and implementation of the new system would have the effect of further streamlining his business to enhance even greater profits. This was no longer likely to be the case.
47. Tahir was scathing about Lynx, and said that he would never use them again, and that he could well understand if I had said to him that the reason for Astea being delayed was because of the lack of co-operation from Lynx which had caused a delay to the whole project. I was aware that there had been a large fall out between Lynx and VI and Time and also that Lynx/VI staff had been thrown off site followed by a complete breakdown in communication. Tahir confirm[ed] at the meeting that his staff had, however, not made any complaints, or said anything critical of Astea's staff in contrast to what had been said about those working for Lynx.
48. We discussed the unpaid invoices. Tahir remarked that as Time had paid about £70,000 to cover labour costs, Astea would not be out of pocket and really what was outstanding was the licence fee. I said, however, that the licence fee had been booked in to Astea's accounts and consequently the revenue had been recognised. Tahir seemed surprised by this. More importantly, I said to Tahir that my concern was that we had agreed a contract whereby a price would be paid for the use of the software, and I asked when he planned to make the payments due. Tahir seemed non-committal in response, and the idea was floated by me of selling the licences on to a third party. I suggested to him that if he was able to find another customer interested in licensing ServiceAlliance, as a means of helping him out I may be able to do some sort of deal on the basis of an introduction. I had in mind crediting an introduction fee/commission if Tahir brought a new customer to us. Tahir indicated that he would give this some thought.
49. I asked Tahir what he intended to do about the project. Tahir suggested that we should suspend work temporarily until he decided what to do next, which I agreed to. Basically, I took the view that I had to agree to this, as he had not paid us for the work done so far, and I wanted to reach an amicable conclusion to the project if possible. I did not get the impression that Time could not pay, but as business was tough, I simply thought that payment would be made some months down the line. Tahir did not indicate at any point in the meeting that he was not going to be able to pay the rest of the sums outstanding, and in fact the meeting was quite amicable. When I came away from the meeting, I was not sure exactly what would happen, although I suspected that it may be that Tahir offered to pay a percentage of the sums outstanding up front, and the rest over a year. I did assume, however, that all of the sums outstanding would be paid eventually.
50. When I left the meeting it was agreed that Tahir would have some time to consider the matter further and then contact me. Indeed, Tahir wrote to me along those lines later that day referring to a "sensible commercial arrangement". I obviously thought that this meant settlement, and I did not for one minute think that he might not pay anything further, but that he might at worst try to agree with me that a lesser amount should be paid than that outstanding."
"18. On 6th March 2001 Mr. Noble of Astea attended Time's offices for a meeting with myself. The reason for the meeting being called was to discuss the issues arising out of Astea's implementation services. I do not accept Mr. Noble's version of what was discussed at this meeting [as set out in the Re-Amended Reply and Defence to Part 20 Claim] or that I made no complaint at all of any alleged defective performance by Astea. The whole reason for the meeting was Astea's defective performance of their implementation services.
18..1 I accepted that some of the difficulties and delays in Astea's integration work were contributed to by difficulties with Lynx but did not accept that they were the sole cause of the delay. Other than a general reference to problems caused by Lynx, I do not recall discussing these aspects in much detail. I certainly would not have advised Mr. Noble that no complaint about Astea's performance had been made by Time's staff. This would not have been true. I received complaints about Astea's performance of their implementation services by Derek Brotherston, Keith Anyon and Steve Taylor and particularly about difficulties caused by repeated staff changes at Astea. I do not recall mentioning Time's need to lay off staff at this meeting although some staff were being laid off at or around that time.
18.2 I asked Mr. Noble how long it would take to complete Astea's implementation services and he informed me that it would take three or four more months. I informed him that this was not acceptable, whereupon Mr. Noble advised me that he had already booked the sums payable under the Agreement into Astea's revenue for that financial year (2000 – 2001). I was surprised at hearing this as Astea had still not completed their implementation services. Had these services been completed by 30th October 2000, Time would have paid the sums due under the Agreement.
18.3 I informed Mr. Noble that Time no longer wanted the ServiceAlliance package and were not prepared to waste any more time with Astea's implementation services. Mr. Noble informed me that he was prepared to put the implementation services on hold and look for a way forward with a view to moving the licences to another company as they had been booked out as revenue for that financial year. I informed him that we would try to assist him in transferring the licences but this was really a matter for Astea, not Time. I believe that Mr. Noble's primary concern was not to have to repay the first instalment that Time had paid from his clear anxiety to find another user for the licences so that there would be no reversal of Astea's revenue."
"29. Pat Noble's version of a meeting on 6 March 2001 contained at paragraphs 45-49 of his Statement is not a true reflection of the course of that meeting. Prior to the meeting Derek told me that from his discussions with Pat he anticipated that Pat was going to try and blame the delay and problems on Lynx. At the meeting I pre-empted Pat Noble by stating that I knew that he was going to try and blame Lynx for Astea's failure to implement ServiceAlliance and that Time would blame Astea. I did not want to become embroiled in such discussions. I expressed my serious concerns regarding the delay that had been encountered and asked Pat how much longer it would [take] to implement ServiceAlliance and provide us with a working system. I wanted to establish when ServiceAlliance would be delivered. In his statement Pat says that he said 2-3 months. My clear recollection is that he stated it would take 3-4 months.
30. At paragraph 46 Pat Noble refers to the projected savings against a business plan of substantial growth and increased profits. This is not strictly correct. Time looked at cost reduction rather than increased profits as this is still important even in times of a downturn in the market.
31. At paragraph 47 I dispute that I would have said I could understand Astea being delayed as a result of the lack of co-operation from Lynx or that I did not say anything critical of Astea's staff. Whilst our discussion did not descend to particulars I made it clear to Pat the level of staffing and the availability of Astea staff was not acceptable and that in my view Astea had completely under resourced the project.
32. In paragraph 48 I refute that Pat Noble did not express his concerns to me about the contract or when Time planned to make payments. I expect his main concern was to avoid Time demanding repayment of the £58,000. I also deny that I floated the idea of selling the licences on to a third party. This was a request that came from Pat Noble and he asked me if I would be prepared to sell the licences and whether I knew of any potential purchasers. I informed him that Time would be prepared to transfer the licences but he was best placed to identify potential purchasers.
33. In paragraph 49 Pat Noble says that I suggested that we should suspend work. This is incorrect. The suggestion came from Pat Noble himself. I would also put this in context. Our meeting on 6 March 2001 was at my request and was against a background that Astea had still failed to deliver a working system. From my prior discussions with Derek Brotherston I was aware that Astea would seek to blame problems with Lynx as the reason for their failure to deliver. Derek and members of the TAG team had previously advised me that this was not the case. Pat was fully aware of Time's concerns prior to the meeting. I opened the meeting by saying to Pat that I knew that he would try and blame Lynx for the delays but that Time was blaming Astea. I recall asking Pat how long it would take for Astea to complete the implementation of ServiceAlliance. When he said 3-4 months, I informed him that this was simply not acceptable. The period of 3-4 months was longer than had originally been envisaged for implementation back in July 2000. I had completely lost confidence in Astea's ability to deliver ServiceAlliance and I informed Pat that this simply would not work for Time and the project was at an end, that is to [say] the contract was terminated. Whilst Pat accepted this to be the position he explained that Astea had booked the licence fee as revenue for that year and did not want to reverse this, as it would create real difficulties for him as far as his American parent company was concerned. I appreciated the difficult position he found himself in and wanted to assist as far as I was able. Pat suggested that we put everything on hold whilst he tried to find an alternative customer to take the licences. In this way he would avoid having to reverse the licence revenue. I agreed to proceed on this basis to try and help Pat although I should be clear that the contract was at an end and that Astea would not be receiving any further payments from Time regardless of whether an alternative customer could be found."
"It was a pleasure seeing you this afternoon and I hope you had a safe journey back to base.
With reference to the Astea implementation, as I indicated, we are running significantly behind timescales and the conditions of Time Group are such that the cost benefit analysis that was once put in place has now changed substantially. As we agreed at the meeting, we are to put all further developments on hold until we reach a sensible commercial arrangement moving forward.
I do intend to think about how we resolve this issue. As I indicated at the meeting, I was not aware that you had already booked the revenue in last years figures as that has confused the issue somewhat from our point of view. However, we do intend to find an amicable way forward. I will also consider your proposal of finding another customer who may wish to buy this product and resolve this issue of unbooking the revenue from last year.
I look forward to speaking with you Pat, later this week."
The letter contained no criticism of any sort of Astea or of its performance of the Contract. It contained no suggestion that the Contract had been terminated. The letter was friendly in tone and identified the reason for putting the project "on hold" as the fact that the cost benefit analysis from Time's point of view had changed. The reference to reaching "a sensible commercial arrangement moving forward" seems to me to be totally irreconcilable with the assertion that things were not going to move forward, they had come to an end. I was urged by Mr. Hossain to treat the reference to the project being "on hold" as being non-technical business language equivalent to "terminated". However, it is plain from the context of the letter that the expression "on hold" should be understood in its ordinary sense as a common English expression. Having seen and heard Mr. Mohsan give evidence it is clear to me that he understood and used the expression in its usual sense. In other words, in the letter, as in the meeting, he was very careful not to indicate that he was terminating the Contract. I am satisfied that the suggestion of Mr. Kinsky to Mr. Mohsan in cross-examination that the confusion allegedly created from Time's point of view by the booking by Astea of the revenue from the licence fees payable under the Contract was that it blocked the tactic of seeking to suggest that the payment already made covered Astea's costs and should be accepted as sufficient to let Time off the hook was correct. I am also satisfied that, as was made plain by the promise at the conclusion of the letter that Mr. Mohsan would get back to Mr. Noble, it was Time which it had been proposed at the meeting should seek a new customer for Astea which would be prepared to take an assignment of the licences granted by the Contract, not Astea itself. There was no benefit to Astea in letting Time off the hook of the Contract if Astea found a new customer for the Software. On the other hand, if Time introduced to Astea a customer otherwise unknown to Astea, there was such a benefit.
"Many thanks for your letter of 6th March and your indication that you intend to find an amicable way forward.
I do understand the difficulties that Time Group are experiencing and I can indeed understand your predicament. We do, however, need some sort of proposal from you very soon and I have not heard from you since your letter. Having satisfied the contractual conditions for the license revenue, and provided all of the services under the contract, we did indeed book the revenue in last years figures. Without a proposal from you our auditors will naturally start to query the ageing of the debt and I would like to avoid this if possible. Could you consider settling 50% of the outstanding amount immediately whilst we continue to search for an acceptable resolution?
I look forward to hearing from you."
"Further to my letter of 22nd March (copy enclosed) I am somewhat disappointed to have received no reply. As I am sure you will realise, without an acceptable proposal from you, Astea will be forced to take legal action to recover amounts due. I do not think that this is in the interests of either party and would like to avoid it if at all possible. I am getting certain pressures from my US management and I need to demonstrate some progress rather rapidly. To that extent, I would appreciate your proposal to settle the outstanding amounts within one week of this letter."
"I am in receipt of your letter dated 5 April.
As you are aware, due to the timescales involved in implementing the Astea software, we have got to a stage whereby the cost justification of the software is no longer viable. We are currently reviewing this implementation. However, we are reviewing our service operation as an overall requirement and looking to deploy in store service into our shops whereby we might consider your software again.
As you are aware, we have paid up front £50,000 for the initial consultancy and bespoking. I was surprised to learn at our meeting that you had booked the entire sale as revenue for your year-end last year, which is slightly unusual considering that we have checked all of the inventory. As soon as we have finished reviewing our entire service operation, which we should expect to have completed by the end of May, then we will be in a position to come to a final conclusion on what we do with Astea software.
I have also looked at your suggestion as to whether we could help you resell this license on to other organisations. I am in discussion with a number of them and will keep you informed as to the progress. However, these discussions are at an early stage."
Again there was no suggestion that the Contract had been terminated or that Astea had been in breach of the Contract. The repeated explanation for Time not wishing to proceed with the Software was that the cost justification for introducing it no longer existed. Essentially what it seems to me Mr. Mohsan was seeking by his letter to do was to fend Mr. Noble off for the time being with a vague hint of business to come out of the reconsideration by Time of the question of providing a service facility to customers in store and a vague indication that Time may yet come up with a customer to whom the existing licences of Time could be assigned.
"It was a condition of the Agreement that "the scheduled date of implementation by Astea shall be 1 August 2000". This deadline was extended with Time's consent until 30 October 2000 in an email from Derek Brotherston of Time to Ian Mapp of Astea dated 17 October 2000.
Notwithstanding this extension the implementation was not completed by 30 October 2000 and furthermore, it remained far from complete by 6 March 2001 when Mr. Mohsan of Time met with Pat Noble of Astea and put the implementation programme on hold. Between 30 October 2000 and 6 March 2001 Time have been put to considerable costs and expense attributable to the failure of Astea to implement the ServiceAlliance package by the agreed date.
Our clients are presently quantifying the loss caused by this breach of contract and intend to counterclaim by way of set off against the amount your clients are seeking. We are advised that the amount of the counterclaim is likely to extinguish the amount your clients are seeking and accordingly it would be quite wrong for your clients to present a winding up petition in respect of the debt referred to in your client's statutory demand, there being a genuine dispute on substantial grounds."
It is, it seems to me, not without significance that no assertion was made in the letter that the Contract had been terminated by Time. Rather the contention advanced was that it had been agreed at the meeting on 6 March 2001 that the integration of the Software with other relevant systems would be put "on hold". There was also no suggestion that the sums claimed by Astea were not, as such, due, merely that Time had claims of its own which it could set off against its debts to Astea. Looking at the matter in the round, therefore, it seems to me that the terms of Messrs. Halliwell Landau's letter dated 7 June 2001 in fact support the evidence of Mr. Noble as to what happened at the meeting on 6 March 2001 and not that of Mr. Mohsan.
" Astea failed to implement the ServiceAlliance package or successfully integrate it with the other packages by 30 October 2000 and also failed to complete the implementation such that on 6 March 2001 I met with Pat Noble of Astea and requested that the implementation programme be put on hold."
The law relevant to issues of liability and the submissions of the parties
"The bills of lading in the present case contained no such stipulation [as to time for performance], and, therefore, in accordance with ordinary and well-known principles the obligation of the respondents was that they should take discharge of the cargo within a reasonable time. The question is, has the appellant proved that this reasonable time has been exceeded? This depends upon what circumstances may be taken into consideration in determining whether more than a reasonable time was occupied.
The appellant's contention is, that inasmuch as the obligation to take discharge of the cargo, and to provide the necessary labour for that purpose, rested upon the respondents, the test is what time would have been required for the discharge of the vessel under ordinary circumstances, and that, inasmuch as they have to provide the labour, they must be responsible if the discharge is delayed beyond that period.
The respondents on the other hand contend that the question is not what time would have been necessary or what time would have been reasonable under ordinary circumstances, but what time was reasonable under existing circumstances, assuming that, in so far as the existing circumstances were extraordinary, they were not due to any act or default on the part of the respondents.
My Lords, there appears to me to be no direct authority upon the point, although there are judgments bearing on the subject to which I will presently call attention. I would observe, in the first place, that there is of course no such thing as a reasonable time in the abstract. It must always depend upon circumstances. Upon "the ordinary circumstances" say the learned counsel for the appellant. But what may without impropriety be termed the ordinary circumstances differ in particular ports at different times of the year. As regards the practicability of discharging a vessel they may differ in summer and winter. Again, weather increasing the difficulty of, though not preventing, the discharge of a vessel may continue for so long a period that it may justly be termed extraordinary. Could it be contended that in so far as it lasted beyond the ordinary period the delay caused by it was to be excluded in determining whether the cargo had been discharged within a reasonable time? It appears to me that the appellant's contention would involve constant difficulty and dispute, and that the only sound principle is that the "reasonable time" should depend on the circumstances which actually exist. If the cargo has been taken with all reasonable despatch under those circumstances I think the obligation of the consignee has been fulfilled. When I say the circumstances which actually exist, I, of course, imply that those circumstances, in so far as they involve delay, have not been caused or contributed to by the consignee. I think the balance of authority, both as regards the cases which relate to contracts by a consignee to take discharge, and those in which the question what is a reasonable time has had to be answered when analogous obligations were under consideration, is distinctly in favour of the view taken by the Court below."
"When the language of a contract does not expressly, or by necessary implication, fix any time for the performance of the contractual obligation, the law implies that it shall be performed within a reasonable time. The rule is of general application, and is not confined to contracts for 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 nor unreasonably."
"If this had been originally a contract without any stipulation as to time and, therefore, with only the implication of a reasonable time, it may be that the plaintiffs could have said that they had fulfilled their contract; but in my opinion the case is very different when there was an initial contract, making time of the essence of the contract: "within six or at the most, seven months". I agree that that initial time was waived by reason of the requests that the defendant made after March, 1948, for delivery; and that, if delivery had been tendered in compliance with those requests, the defendant could not have refused to accept the coach-body. Suppose, for instance, that delivery had been tendered in April, May, or June, 1948: the defendant would have had no answer. It would be true that the plaintiffs could not aver and prove they were ready and willing to deliver in accordance with the original contract. They would have had, in effect, to rely on the waiver almost as a cause of action….. If the defendant, as he did, led the plaintiffs to believe that he would not insist on the stipulation as to time, and that, if they carried out the work, he would accept it, and they did it, he could not afterwards set up the stipulation as to the time against them. Whether it be called waiver or forbearance on his part, or an agreed variation of substituted performance, does not matter. It is a kind of estoppel. By his conduct he evinced an intention to affect their legal relations. He made, in effect, a promise not to insist on his strict legal rights. That promise was intended to be acted on, and was in fact acted on. He cannot afterwards go back on it….
So, if the matter had stopped there, the plaintiffs could have said, notwithstanding that more than seven months had elapsed, that the defendant was bound to accept; but the matter did not stop there, because delivery was not given in compliance with the requests of the defendant. Time and time again the defendant pressed for delivery, time and time again he was assured he would have early delivery; but he never got satisfaction; and eventually at the end of June he gave notice saying that, unless the car were delivered by July 25, 1948, he would not accept it.
The question is whether he was entitled to give such a notice, making time of the essence, and that is the question that Mr. Sachs has argued before us. He agrees that, if this were a contract for the sale of goods, the defendant could give such a notice. He accepted the statement of McCardie J., in Hartley v. Hymans, as accurately stating the law in regard to the sale of goods, but he said that that did not apply to contracts for work and labour. He said that no notice making time of the essence could be given in regard to contracts for work and labour. The judge thought that it was a contract for the sale of goods. But in my view it is unnecessary to determine whether it was a contract for the sale of goods or a contract for work and labour, because, whatever it was, the defendant was entitled to give a notice bringing the matter to a head. It would be most unreasonable if the defendant, having been lenient and waived the initial expressed time, should, by so doing, have prevented himself from ever thereafter insisting on reasonably quick delivery. In my judgment he was entitled to give a reasonable notice making time of the essence of the matter. Adequate protection to the suppliers is given by the requirement that the notice should be reasonable."
"The case therefore comes down to this: there was a contract by these motor traders, the plaintiffs, to supply and fix a body on the chassis within six or seven months. They did not do it. The defendant waived that stipulation. For three months after the time had expired he pressed them for delivery, asking for it first for Ascot and then for his holiday abroad. But still they did not deliver it. Eventually, at the end of June, being tired of waiting any longer, he gave four weeks' notice and said: "at all events, if you do not supply it at the end of four weeks I must cancel the contract"; and he did cancel it. I see no injustice to the suppliers in saying that that was a reasonable notice. Having originally stipulated for six or seven months, having waited ten months, and still not getting delivery, the defendant was entitled to cancel the contract."
"(4) Time is often spoken of as being "made of the essence of the contract by notice" – a concept which is reflected in the words "or to have become" in section 41 of the Law of Property Act 1925. Nevertheless, the phrase is misleading. In equity, and now in the fused system, performance had or has, in the absence of time being made of the essence, to be within a reasonable time. What is reasonable time is a question of fact to be determined in the light of all the circumstances. After the lapse of a reasonable time for performance the promisee could and can give notice fixing a time for performance. This must itself be reasonable, notwithstanding that ex hypothesi a reasonable time for performance has already elapsed in the view of the promisee. The notice operates as evidence that the promisee considers that a reasonable time for performance has elapsed by the date of the notice and as evidence of the date by which the promisee now considers it reasonable for the contractual obligation to be performed. The promisor is put on notice of these matters. It is only in this sense that time is made of the essence of a contract in which it was previously non-essential. The promisee is really saying, "Unless you perform by such-and-such a date, I shall treat your failure as a repudiation of the contract." The court may still find that the notice stipulating a date for performance was given prematurely, and/or that the date fixed for performance was unreasonably soon in all the circumstances. The fact that the parties have been in negotiation will be a weighty factor in the court's determination. For the foregoing, see Smith v. Hamilton  Ch. 174. To say that "time can be made of the essence of a contract by notice" except in the limited sense indicated above, would be to permit one party to the contract unilaterally by notice to introduce a new term into it."
"This case gives rise to a difficult question. How long is a ship obliged to remain on demurrage, and what are the rights of the owner if the charterer detains her too long? Translated into the terms of general contract law, the question is: Where time is not of the essence of the contract – in other words, when delay is only a breach of warranty – how long must the delay last before the aggrieved party is entitled to throw up the contract? The theoretical answer is not in doubt. The aggrieved party is relieved from his obligations when the delay becomes so long as to go to the root of the contract and amount to a repudiation of it. The difficulty lies in the application, for it is hard to say where fact ends and law begins. The best solution will be found, I think, by a judge who does not try to draw too many nice distinctions between fact and law, but who, having some familiarity both with the legal principle and with commercial matters and the extent to which delay affects maritime business, exercises them both in a common-sense way. This is the sort of solution which, upon the supposition that it was acceptable to business men, the commercial court was created to provide."
"The test whether an event has this effect or not has been stated in a number of metaphors all of which I think amount to the same thing: does the occurrence of the event deprive the party who has further undertakings still to perform of substantially the whole benefit which it was the intention of the parties as expressed in the contract that he should obtain as the consideration for performing those undertakings?"
"In my judgment, there is of course a middle ground between acceptance of repudiation and affirmation of the contract, and that is the period when the innocent party is making up his mind what to do. If he does nothing for too long, there may come a time when the law will treat him as having affirmed. If he maintains the contract in being for the moment, while reserving his right to treat it as repudiated if his contract partner persists in his repudiation, then he has not yet elected. As long as the contract remains alive, the innocent party runs the risk that a merely anticipatory repudiatory breach, a thing "writ in water" until acceptance, can be overtaken by another event which prejudices the innocent party's rights under the contract – such as frustration or even his own breach. He also runs the risk, if that is the right word, that the party in repudiation will resume performance of the contract and thus end any continuing right in the innocent party to elect to accept the former repudiation as terminating the contract."
I accept that submission as correct in principle.
"It is, of course, open to parties to a contract …. to exclude by express agreement a remedy for its breach which would otherwise arise by operation of law … But in construing such a contract one starts with the presumption that neither party intends to abandon any remedies for its breach arising by operation of law, and clear express words must be used in order to rebut this presumption."
Clause 8.2 of Astea's Conditions on its face is intended to provide a mechanism for termination of a contract in which it is incorporated in circumstances in which it would not be terminable at common law. There seems to me to be no warrant for construing clause 8.2 as excluding the rights which Time would otherwise have at common law in the event that the Contract or an agreement incorporated in it was repudiated.
"In McDonald v. Dennys Lascelles Ltd. (1933) 48 CLR 457, 476, Dixon J said, in a judgment unanimously approved of by this House in Johnson v. Agnew  AC 367, 396:
"When a party to a simple contract, upon breach by the other contracting party of a condition of the contract, elects to treat the contract as no longer binding upon him, the contract is not rescinded as from the beginning. Both parties are discharged from the further performance of the contract, but rights are not divested or discharged which have already been unconditionally acquired. Rights and obligations which arise from the partial execution of the contract and causes of action which have accrued from its breach alike continue unaffected."
Despite an attempt by Mr. Curry to show that hire-purchase agreements are to be distinguished from the ship contract with which this House is presently concerned, they clearly fall within the general proposition propounded by Dixon J."
Two earlier decisions at first instance in which it had been held that in particular circumstances the defaulting purchaser of goods (in one case) or land (in the other) were able to recover sums paid in part payment of the purchase price were distinguished. Different members of the House of Lords distinguished the earlier cases on different grounds, but the common theme of the majority was that the general principle was as I have set out. That general principle was restated, again by reference to the statement of Dixon J in McDonald v. Dennys Lascelles Ltd., by Lord Brandon of Oakbrook in Bank of Boston Connecticut v. European Grain and Shipping Ltd.  AC 1056 at pages 1098-1099. I accept the submission of Mr. Kinsky.
"In my view the hardware did not have any significant value to SWW in itself (except for a minimal second hand value). Equally I am satisfied that the customer contact and workflow SRS did not have any intrinsic value to SWW which would prevent SWW claiming in restitution. In my view SWW did not get any part of that for which they paid the purchase money. They paid the purchase money for ICL to devise and install a computer system to conform to SWW's URS. They did not receive any part of the Computer System. SWW did not contract in a vacuum to receive management know-how. They contracted to receive management services to enable the computer system to be delivered not as an end in itself."
With great respect to Mr. Hossain, it does not seem to me that those comments of H.H. Judge Toulmin are of any assistance to him in the circumstances of the present case. Those comments were, no doubt, entirely apposite in the circumstances of the case before H.H. Judge Toulmin, but the concept of a total failure of consideration is only relevant, in my judgment, in circumstances in which a payment has been made and the question is whether there has been consideration for that payment. They are not relevant in the context in which Mr. Hossain sought to rely upon them, namely on the issue whether a payment due under a contract, but not made, remained payable after a repudiation. On that issue, in the light of the authorities relied upon by Mr. Kinsky, the answer is as I have indicated. However, that notwithstanding, if there were a breach of contract which had the effect of depriving Time of any benefit from payments made or due, it is not an adventurous proposition that the amount of the payments made, and the liability to make further payments, should be brought into account in calculating the damages recoverable in respect of the breach. In the end, therefore, my rejection of this submission of Mr. Hossain is without practical effect, in the event that I find that there was a breach of contract on the part of Astea which deprived Time of any benefit under the relevant contract.
Consideration and conclusions in relation to liability
Time's alleged losses
"It seems to me, as a matter of principle, that the full claim of damages in the form in which it is pleaded was not sustainable, in so far as the plaintiff sought to recover both the whole of his original capital loss and also the whole of the profit which he could have made. I think that that is really a self-evident proposition, because a claim for loss of profits could only be founded upon the footing that the capital expenditure had been incurred."
At page 308 Jenkins LJ expressed the same view.
"However, a conservative estimate of the cost of the ASTEA project to Time would be at least twice the original estimated cost of £38,050 i.e. £76,100 plus VAT making a total of £89,417.50."
£89,417.50 is indeed £76,100 plus 17.5% of £76,100. As the Value Added Tax element, if valid at all, would have been recovered by Time as input tax in any event, it plainly cannot form any part of any loss in relation to the Lynx Element. In fact, the cost of work needing to be performed by Lynx in relation to the Software was estimated by Lynx originally, in Mr. Spencer's e-mail dated 3 July 2000, not at £38,050, but at £28,000. At paragraph 12 of his witness statement dated 10 February 2003 made for the purposes of this action Mr. Tahir Mohsan again dealt with the figure of £89,417.50. This time he said:-
"There is no specific invoice for the Astea/CS3 integration work carried out by Lynx/VI but I estimate that the additional cost to Time for the work carried out by Lynx/VI would be at least twice the estimated costs of £38,050 plus VAT making a total of £89,417.50. Because the ServiceAlliance package was never implemented and was of no benefit to Time these costs were wasted."
In cross-examination Mr. Mohsan said, for the first time, that the estimate of the amount of the sums paid to Lynx which was referable to work on integration of CS/3 and the Software was not his, but that of Mr. Spencer of Lynx and had been made by Mr. Spencer before the date of Mr. Mohsan's witness statement. I am satisfied that that assertion was completely untrue and was made up by Mr. Mohsan in the witness box. I reject his evidence as to the sum referable to work on the integration of CS/3 and the Software which was paid to Lynx. There was no other reliable evidence of what sum had been paid to Lynx in respect of this work. All I know is that at one point in September 2000 Lynx contemplated a cost of the order of £7,040, while by 9 November 2000 it seems to have been claiming a sum of £22,000. The dispute between Lynx and Time was settled by payment by Time of a global sum of the order of half the total claimed by Lynx, and there was no evidence of what part, if any, of the sum eventually paid related to work on the integration of CS/3 and the Software. For these reasons I should not have found the Lynx Element proved in any event.
"These staff savings would I believe have continued until about the end of 2002 by which stage Time had further developed Pulse to add some additional functionality to it albeit that this is still someway short of what ServiceAlliance would have achieved."
In other words, what Mr. Taylor seemed to be saying was that by the end of 2002 the contemplated savings had been achieved anyway through the development of Pulse. If that is right, then it is puzzling that in the meeting held on 21 February 2001 between Mr. Flanagan, Mr. Taylor, Mr. Bond and Mr. Anyon the staff savings which it was contemplated could be achieved through the development of Pulse were a total of six and a half full time employees, not the total of eleven of which Mr. Taylor spoke in his first witness statement. Either the estimate of eleven in total was excessive even if the Software had become operational, or the estimate of six and a half full time posts to be saved through the development of Pulse was overly pessimistic. The whole picture was complicated by two further considerations. The first was that, as Mr. Tahir Mohsan accepted in cross-examination, the thinking behind introducing the Software in the first place did not include the saving of existing staff posts, but rather handling a greater volume of business in the Service Centre without an exponential increase in the number of staff. However, no detailed thought seems to have been given to exactly how an exponential increase would have been avoided. The other complicating consideration was that, in the event, the downturn in the market for personal computers prompted Time to make considerable numbers of staff redundant anyway. Mr. Kinsky submitted that by that means the contemplated staff savings were made in any event. He put that suggestion to Mr. Taylor, who rejected it, asserting that, as it were, even more people could have been made redundant had the Software become operational. Logically that is a sound answer to Mr. Kinsky's point, as it seems to me, subject to demonstration of where the further redundancies could have been made. In that context Mr. Taylor produced, and attached to his second witness statement, an analysis of manning levels in the Service Centre in each month of each of the calendar years 2001 and 2002. Those showed total staff of 28 in January 2001, 31 in each of February, March and April 2001, falling to 22 in May, 21 in June and 19 for the rest of 2001, save for October, when the number was 17. The year 2002 began with 15 in January, rising to 19 in February, to 21 in March, to 22 in April, to 26 in May, with the number continuing at 25 or 26 until November, when it fell back to 22, rising to 23 in December. The numbers of staff in each month do not obviously indicate scope for shedding 11 posts. Eleven is 35.48% of the largest number of staff recorded in any month, 31. If it were correct that by the end of 2002 Time was in the same position, so far as numbers of staff employed in the Service Centre was concerned, as it would have been had the Software become operational, then the contrast seems to be between 28, or at most 31, and 23, a saving of 5 or, at most, 8 posts. However, in fact what the figures seem to indicate is a demand which was both dependent upon the health of the market, and seasonal. If one looked below the surface of total numbers of staff, according to Mr. Taylor six of the eleven posts which could have been saved had the Software become operational were in the Logistics department. His analysis showed the numbers employed in that department as 8 in January 2001, 9 in February, March and April 2001, 4 from May to October 2001, but rising to 16 by May 2002 and being 14 in December 2002. In other words, far from saving staff in the Logistics department, if it was in the position at the end of 2002 in which it would have been had the Software become operational, it actually increased in numbers by 6 as compared with January 2001. The "Admin" department, on the other hand, where Mr. Taylor said that three posts could have gone, declined in any event from 6 employees in January 2001 to one in July 2001, at which level it remained until December 2002. That reduction was obviously achieved entirely without reference to the Software. The remaining two posts which Mr. Taylor contemplated could have been saved were in the returns, or inventory, department. On Mr. Taylor's analysis the numbers employed in that department declined from 9 in January 2001 to 6 by July 2001, and remained at 5 or 6 thereafter until December 2002. Again the reduction was apparently achieved entirely without reference to the Software. Thus of the three departments in which Mr. Taylor asserted that savings in numbers of staff could have been made had the Software become operational, and were made by December 2002, the Logistics department in fact showed a substantial increase in numbers by December 2002 as compared with January 2001, while the savings made in the other two departments were made long before December 2002, namely by July 2001. If one then reminds oneself that the pleaded case of Time in the Re-Amended Part 20 Claim was that a total of 63 employees in the Service Centre could have been reduced to 52, it becomes clear, in my judgment, that the alleged loss of the opportunity to save posts in the Service Centre was illusory. This was just an invented element of claim for which there was never any sound factual foundation.