Steria Ltd v Sigma Wireless Communications Ltd [2007] EWHC 3454 (TCC)

Case No 6BM50037[2007] EWHC 3454 (TCC)
IN THE HIGH COURT OF JUSTICE
QUEEN’S BENCH DIVISION
BIRMINGHAM DISTRICT REGISTRY
TECHNOLOGY AND CONSTRUCTION COURT
HIS HONOUR JUDGE STEPHEN DAVIES SITTING AS A JUDGE OF THE HIGH COURT
Venue BIRMINGHAM CIVIL JUSTICE CENTRE
33 BULL STREET
Venue BIRMINGHAM B4 6DS
Date of draft judgment: 28 September 2007
Date judgment handed down: 15 November 2007
Before
His Honour Judge Stephen Davies.
Between
STERIA LIMITEDClaimantSIGMA WIRELESS COMMUNICATIONS LIMITEDDefendant
Mr Simon Hargreaves of Counsel (instructed by Wragge & Co LLP) for ClaimantMr David Blunt, Q.C. of Counsel (instructed by Pinsent Masons) for Defendant
JUDGMENTA.INTRODUCTIONDate 2007-11-15
[1]This case arises out of a project for the provision of a new computerised system for the fire and ambulance services in the eastern counties of the Republic of Ireland. The project was known as a Computer Assisted Mobilising Project (‘CAMP’ for short), and thus the employers were collectively known as ‘CAMP East’. What was to be provided was a computer aided mobilisation and communications system, operated from a regional command centre. This was to replace the mix of existing systems used by the various services within CAMP East, some of which were manual and others being computerised systems of varying vintage and quality. Under the new system the fire and ambulance services were to enjoy the benefit of a region wide computerised system for taking emergency calls, mobilising emergency services, and other associated and ancillary functions.[2]CAMP East contracted the provision of the computer aided mobilisation and communications system to the main contractor, Sigma, a company incorporated in the Republic of Ireland and the Defendant in this action, for a contract price of €6,467,827. Sigma sub-contracted a substantial element of the works, namely the provision of the computer aided despatch system with a sub contract value of €3,075,736.73, to Steria the Claimant in this action.[3]Sigma has paid the vast majority of the sum due under the sub-contract, but has refused to pay the final tranche of 5% (€153,786.84) due at the expiry of the defects liability period. In defending the claim it is not asserting that there were any defects in the sub contract works; instead it is contending that Steria delayed in completing the sub-contract works, and as a result it is entitled to set off against the final payment due under the sub contract (which it does not otherwise dispute) and to counterclaim either:(i) liquidated damages of €307,573.73 under the sub contract, or;(ii) general damages, in a sum in excess of €380,000, for losses which it contends it has incurred as a result of the delay.[4]It will immediately be seen that the amounts involved in this case are not significant in comparison to the value of the main contract or the sub-contract. Nonetheless the case has been keenly contested by both sides, with substantial documentation having been produced, with evidence heard over 5 sitting days, and with detailed written opening and closing submissions. I have been told, and have no reason to doubt, that the costs incurred by both parties are substantial.[5]In order to avoid over-loading the introductory section of this judgment with explanations of the various parties, people and places involved and descriptions of the more important technical terms involved, I have provided as appendices to this judgment glossaries to provide that information. In this judgment I indicate by asterisking the first substantive reference in this judgment to someone or something which is within the appendices. I also include references to the trial bundle by using their file number and page number, thus A1/001 is page 1 of bundle A1, and references to the evidence by using the day on which the evidence was given and the page number of the transcript of evidence, thus 1/001 is page 1 of the transcript of evidence of day 1 of the hearing.

Structure of the judgment

[6]The judgment is separated into the following sections:a. A. Introduction (pp.2-3)b. B. The history leading up to the conclusion of the sub-contract and the main contract (pp.3-5)c. C. The terms of the sub-contract (pp.6-20)d. D. The scope of Steria’s obligations in relation to legacy data loading and integration (pp.21-24).e. E. The terms of the main contract (pp.25-28)f. F. The extension of time provisions of clause 6.1 of the sub-contract (pp.29-36)g. G. Is clause 7.1 of the sub-contract a valid liquidated damages clause or a penalty? (pp.37-42)h. H. Causes of delay and delay notices (pp.43-82). This is sub-divided into: H.1. Causes of delay to FAT2 (pp.50-74) H.2. Causes of delay in delivery to Dublin and in installation at Dublin and OBI (pp.75-77) H.3. Causes of delay in achieving SAT (pp.78-82)i. I. Sigma’s counterclaims (pp.83-86)j. J. Conclusions (p.87)k. K. Glossaries (pp.88-92) B. THE HISTORY LEADING UP TO THE CONCLUSION OF THE SUB CONTRACT AND THE MAIN CONTRACT[7]In June 2000 Mason* produced the tender documentation for the main contract. The Invitation to Tender (‘ITT’) comprised a series of separate tender documents; as relevant to this case it included the following documents:(1) Tender Document 1 – Project Overview, the aim of which was to provide tenderers with an understanding of the project procurement.(2) Tender Document 2 – ITT Contract Document, the aim of which was to provide tenderers with details of the contract terms which would apply to the project.(3) Tender Document 4 – CAD* System User Requirement, the aim of which was to provide tenderers with the user requirements for the CAD system element of the project. There was also a Tender Document 3, which outlined the user requirements for the communications element of the project, but this element was not sub-contracted to Steria and is therefore of no direct relevance to this case. Finally, there was a Tender Document 5, which outlined the user requirements for the MIS* element of the project which, although sub-contracted to Steria, is not at issue in this case.[8]It appears that both Sigma and Steria (or more accurately Bull Information Systems Limited – ‘Bull’, the company whose business was acquired by Steria during the course of this project) were on the tender invitation list, and both tendered for the whole project. All tenderers were required to provide detailed responses to Tender Documents 2 – 5 inclusive, stating in one integrated document on a paragraph by paragraph basis whether their offer was:(i) compliant with the individual requirements of those documents;(ii) non-compliant; or(iii) part-compliant.[9]In the event, whilst CAMP East was inclined to select Sigma as the main contractor, it was sufficiently impressed with the Bull tender for the command and control system to want to use Bull as sub-contractor for that works package. Mason therefore wrote to Sigma on 13 December 2000 [C1/022], inviting it to undertake negotiations with Bull to that end. On 19 December 2000 [C1/024] Bull wrote to Sigma confirming an offer to undertake the relevant works package work as Sigma’s sub-contractor, on the terms of its completed Tender Documents 2, 4 and 5, which had all been re-dated 13 December 2000 and addressed to Sigma. They were re-dated and re-sent with a letter dated 15 February 2001 [C1/137].[10]There followed a series of meetings and communications involving CAMP East, Mason, Sigma and Bull over the period from December 2000 through to June 2001. That process included negotiations as to the terms of the main contract, which culminated on 29 June 2001, when:(1) CAMP East wrote to Sigma [C2/725], informing it that the relevant authority had sanctioned Sigma’s proposals, and that Mason had been instructed to conclude a contract with Sigma.(2) In turn, Sigma wrote to Bull [C3/726], informing it that CAMP East had awarded the project to Sigma, that Bull was the ‘nominated CAD supplier’, and that Sigma was intending to place an order with Bull in accordance with its quotation of 15 February 2001.[11]However it was not until 30 August 2001 [C3/802] that Dublin Corporation wrote to Sigma enclosing a counterpart of the main contract which appears to have been executed under seal on its behalf. The version I have also bears what appears to be the signature of Mr Maguire, Sigma’s managing director.[12]Although there is no correspondence to this effect, it is apparent that sometime around 11 September 2001 the draft sub contract agreement was signed by Mr Maguire on 11 September 2001, and then forwarded to Bull. It was then signed by a Mr Lambert on behalf of Bull on 2 December 2001. The reason for the delay - either by Sigma in submitting the draft sub contract to Bull, or by Bull in signing the sub contract on receipt - was not explored in evidence, but it is not alleged that there was any agreement to vary the terms of the sub contract as a result of the delay in its execution. It appears from the Particulars of Claim and from David Cartwright’s witness statement that the sub-contract was novated by Bull to Steria (then known as Integris Limited) in January 2002; it is unnecessary for me to consider the precise legal mechanism by which this process was achieved in this judgment because it is common ground in this case that the contracting parties for all relevant purposes are Sigma and Steria.

C. THE TERMS OF THE SUB CONTRACT

[13]The sub contract was in writing. It was a heavily revised version of the standard MF1 Form of Sub-Contract. In addition to what were described as the Special Terms and Conditions contained in the main body of the agreement itself (the ‘Special Terms’), the sub-contract also had 13 Schedules attached to it. Furthermore, it incorporated as contract documents by express reference those documents referred to in Schedule 2, namely:• Bull’s response dated 15 February 2001 to CAMP tender document 2 (i.e. the ITT Contract details). (I will refer to this as the ITT Contract specification.)• Bull’s response dated 15 February 2001 to CAMP tender document 4 (i.e. the CAD System User Requirement). (I will refer to this as the CAD specification.)• Bull’s response dated 15 February 2001 to CAMP tender document 5 (i.e. the MIS System User Requirement). (I will refer to this as the MIS specification.)[14]The definition of the sub contract works directed the reader to Schedule 3, which in turn re-directed the reader to the Schedule 2 contract documents, ‘as expanded by a FDS* which will be furnished to Sigma within the time-scale outlined in Schedule 5 of this document’.[15]Schedule 5 contained a table, which identifies the ‘time for completion of the sub-contract works’ as being as follows: Task Completed by FDS 1 Nov 2001 FAT* Phase 1 7 Dec 2001 FAT Phase 2 15 April 2002 Delivery to Dublin 14 June 2002 Installation at Dublin and OBI* 25 July 2002 SAT* 20 Sept 2002[16]In addition to the Special Terms, the Schedules, and the contract documents referred to in Schedule 2, clause 2.1 of the contract also provided for the incorporation of what are described as the ‘reflected terms and conditions of the Main Contract’, although clause 1.2 also provided that these should rank below the Special Terms and the Schedules in order of precedence. These reflected terms were identified in Schedule 1 of the sub-contract, and in addition to identifying – superfluously - the 3 documents also identified in Schedule 2 (i.e. the 3 sub-contract documents referred to in paragraph 13 above) they also included ‘Sigma response dated 22 December 2001 to CAMP tender document 2’. This was a reference to Sigma’s ITT Contract tender submission, but due to the order of precedence in Schedule 1 Steria’s ITT Contract tender submission takes precedence over Sigma’s submission in any event. Furthermore:(i) Clause3.1 provided that ‘the Conditions [as defined under the Main Contract] should except as varied by the Special Terms and Conditions and subject to clause 1.2 [the order of precedence clause] be deemed to be incorporated in this sub-contract and as between the Contractor and the Sub-contractor shall apply to the Sub-contract Works as they apply to the Works’.(ii) Clause3.2 provided that ‘unless the context otherwise provides, the provisions of the Main Contract shall apply to the Sub-contract as if the Contractor were the Purchaser therein stated and the Sub-contractor were the Contractor thereunder’.[17]It will be appreciated from this description of the documents which make up the sub-contract that a large quantity of material was incorporated into the sub-contract by reference, including the terms of the main contract - save where inconsistent with the terms of the sub-contract.[18]I must set out clause 6.1 of the Special Terms, which contained an extension of time provision, and clause 7.1, which made provision for the contractor to be entitled to levy liquidated damages in the circumstances specified therein.[19]Clause 6.1 “The Sub-Contractor shall complete the Sub-Contract Works within the time for completion thereof specified in the Fifth Schedule hereto. If by reason of any circumstance which entitles the Contractor to an extension of time for the Completion of the Works under the Main Contract, or by reason of a variation to the Sub-Contract Works, or by reason of any breach by the Contractor the Sub-Contractor shall be delayed in the execution of the Sub-Contract Works, then in any such case provided the Sub-Contractor shall have given within a reasonable period written notice to the Contractor of the circumstances giving rise to the delay, the time for completion hereunder shall be extended by such period as may in all the circumstances be justified and all extra costs incurred by the Sub-Contractor in relation thereto shall be added to the Sub-Contract Price together with a reasonable allowance for profit. The Sub-Contractor shall in all cases take such action as may be reasonable for minimising or mitigating the consequences of any such delay.”[20]There is a substantial dispute between the parties as to the proper construction of this extension of time provision and, in particular, whether or not the requirement for giving written notice of delay is a condition precedent to Steria’s entitlement to an extension of time.[21]Clause 7.1 “If the Sub-Contractor fails to complete the Sub-Contract Works or any part thereof within the time for completion or any extension thereof granted under Clause 6 (Completion), there shall be deducted from the Sub-Contract Price, or the Sub-Contractor shall pay to the Contractor as and for liquidated damages, the percentage (stated in the Sixth Schedule) of the Sub-Contract Value of that part of the Sub-Contract Works as cannot in consequence of the delay be put to the use intended for each week between such time for completion and the actual date of completion, but in no case shall the total amount to be deducted or so paid exceed the maximum percentage of the Sub-Contract Price stated in the Sixth Schedule hereto. Such deduction or payment shall be in full satisfaction of and to the exclusion of any other remedy of the Contractor against the Sub-Contractor in respect of the Sub-Contractor’s failure to complete within the time for completion of the Sub-Contract Works.”[22]Schedule 6 “LIQUIDATED DAMAGES (Refers to Clause 7.1 of these Special Terms and Conditions) Per para. 4.5.1 of CAMP Tender Document 2. 4.5.1.2 The percentage of the Sub-Contract Price for the Works to be paid or deducted for each week or part week of delay shall be 1% per week. 4.5.1.3 The maximum amount of Liquidated Damages shall not exceed 10% of the Sub-Contract Price. Damages will apply only to the tasks and delivery dates, and in the amounts shown in the table below: Task Completed by LD Per Week LD Maximum FAT Phase 2 15 April 2002 IR£ 6,055.08 IR£ 60,558.50 Delivery to Dublin 14 June 2002 IR£ 6,055.08 IR£ 60,558.50 Installation at Dublin and OBI 25 July 2002 IR£ 6,055.08 IR£ 60,558.50 SAT 20 Sept 2002 IR£ 6,055.08 IR£ 60,558.50 Max Total LD IR£ 242,234.00[23]There is a substantial dispute between the parties as to whether or not this provision is a valid liquidated damages clause or an invalid penalty clause. Again, I will return to this dispute once I have reviewed the relevant sub-contract and main contract terms.[24]The only other Schedule to which I should refer at this stage is Schedule 11. This set out the contractor’s responsibilities, and required the contractor to ‘ensure that these responsibilities are performed with all due skill, care and diligence and at no cost to the sub-contractor.’ The Schedule was then broken down into 11 general and 2 specific responsibilities, including:
“General Responsibilities: … 4. Provide information and consents promptly, and give written confirmation of the same promptly. … 7. Ensure that the sub-contractor has at all times such access to the purchaser’s business premises, computer software and other office facilities as is necessary to enable the sub-contractor to perform his obligations. 8. Ensure that all data and other information supplied and/or made available to the sub-contractor by or on the purchaser’s behalf is, unless drawn to the sub-contractor’s project manager’s attention in writing, complete and accurate in all respects. … Special Responsibilities: 1. Adhere to Schedule 5 (Time for Completion of Sub-Contract Works). …”
Special Responsibilities:

The ITT Contract specification

[25]This was part of Steria’s original tender submission to CAMP, which Steria subsequently submitted to Sigma on 13 December 2000 as part of its sub-contract proposal. It contained 159 pages. The following sections are of some relevance to the issues in this case.[26]§1.21 dealt with the FDS, and made it clear that:(i) the first stage of the contract was for the FDS to be agreed between the contractor and the purchaser;(ii) unless the FDS was completed to a standard which was acceptable to the purchaser the contractor would not be permitted to proceed further with the contract. There is an issue between the parties as to whether the FDS had to be agreed between the parties, and thereby became a contract document, or whether it was simply a document proffered for approval by Steria which did not affect the underlying contractual obligations of the parties.[27]§4.1 stated that the General Conditions of Contract (i.e. the general conditions applicable to the main contract) should be the MF/1 General Conditions of Contract (Revision 3, 1988 edition, 1989, 1992 and 1995 amendments) for the supply of electrical, electronic or mechanical plant with erection subject to such additions, amendments and substitutions as were set out in the document. Sigma relies on certain conditions of the MF/1 Conditions as incorporated into the sub-contract.[28]§4.3.1 stated that the Engineer for the purpose of clause 1.1(d) of the MF/1 Conditions was to be Mason. Sigma contends that Mason was also the Engineer for the purposes of the sub-contract, and that the Engineer had a role under the sub-contract as well as a role under the main contract. Steria disputes that the Engineer had any role under the sub-contract.[29]§4.3.11 required the contractor to provide a programme for the execution of the works, to be updated at least monthly with changes to be approved by the Engineer. It is to be noted that Steria’s response stated that Steria preferred any changes to be made ‘by mutual agreement through a formal change control procedure’. Also, under §4.5.1, dealing with the time for completion, Steria suggested that any changes in the time for completion ‘should be mutually agreed by the parties through a formal change control procedure’.[30]On the basis of this Sigma has contended that this formal change control procedure applies to the notification procedure for extension of time under clause 6.1 of the Special Conditions. It is convenient to deal with this point at this stage.[31]In my judgment the reference to a formal change control procedure is a reference to the procedure provided for by clause 9.1 and Schedule 10 of the sub-contract. Under this procedure, where either party wished to vary the sub-contract the sub-contractor was invited to produce a variation control notice (VCN) evaluating the impact of the proposed variation. If the contractor decided to accept the VCN, he would sign and return the VCN to the sub-contractor. In my judgment, the effect of this section was to provide that any proposed changes to the programme and to the time for completion should be dealt with in this way, rather than being subject to the approval of the Engineer. It follows that the impact of any delay due to relevant circumstances (i.e. delay within clause 6.1) on the programme or on the time for completion would be dealt with by agreement under the VCN procedure of clause 9.1 and Schedule 10. However, I do not consider that this affects the procedure under which relevant circumstances causing delay are to be notified to the contractor under clause 6.1. Furthermore, I do not consider any failure by Steria to submit a VCN could by itself deprive it of would otherwise be its contractual right to an extension of time. In other words, this cannot be a condition precedent of its right to an extension of time.

CAD specification

[32]This is a document 247 pages long. It contains Steria’s detailed response to CAMP’s detailed requirements in relation to the CAD System. Both parties place considerable reliance on various parts of this document in support of their respective cases, in particular in relation to the crucial issue of Steria’s obligations in relation to the loading and integration of legacy data, and it is thus of considerable importance in this case.[33]Before delving into the detail of the CAD specification it may be helpful for me to make some general observations about the structure of the fire and ambulance services which comprised CAMP East, and about the way in which the new system was intended to work.[34]The structure was described in the Project Overview section of the ITT as follows:(i) The DFB* was the fire authority for Dublin City and County, providing the fire service for those areas. It also provided an A&E ambulance service in that area by arrangement with ERAS*. It appears to have been the driving force behind CAMP East.(ii) The individual fire authorities for the other counties of the eastern region were all separate entities, providing a fire service within their particular counties. Including Dublin County, there were 14 counties and thus 14 fire authorities in all. Of the others, particular reference is made later in this judgment to Longford.(iii) ERAS was responsible for providing an ambulance service to the counties of Dublin, Kildare and Wicklow. ERAS had already procured a computerised dispatch and patient transport system from a business known as SSL; the intention was in due course to integrate the two systems, but in the mean-time it was required that the 2 systems should be capable of linking with each other. ERAS therefore had a contingent interest in the CAMP East project, even though it was not intending to use the system immediately upon completion.[35]Furthermore, because each authority was a separate entity, their existing systems were different. As described in §1.5 of the Project Overview, DFB had a computerised mobilisation system, as did ERAS and 2 other fire authorities, whereas the remaining fire authorities had manual systems. In I.T. jargon, the data held in the databases forming part of these systems was known as legacy* data.[36]So far as relevant to this case, there were 2 particularly important features of the proposed new system (see §2.3 of the Project Overview), namely:(i) That it should contain a searchable database of addresses (a ‘gazetteer’), so that an emergency telephone operator, on being told for example there was a fire in ‘Longfield Road, Ballymore’, would be able to enter those details into the computer and then be able to identify the relevant location from the database. This would then allow the operator to ascertain from the details in the database important information such as the location of the nearest fire station and the recommended route from the nearest fire station to the incident location (this is what is known as the PDA* feature).(ii) That it should contain a GIS* / mapping* function, so that the operator could also see on screen a computerised map of the relevant area. This would be of obvious benefit in, for example, identifying the precise location in the case of any confusion. It would also be extremely useful in communicating with fire engines or with ambulances – as was to be provided by means of the communications element of the project - to identify which appliance was closest to an incident and to direct appliances to the location.[37]It will be appreciated that there is a difference between the process of creating the gazetteer database and the process of filling it with information (in I.T. jargon, ‘populating’ the database) by loading the relevant data into the database. So far as the latter was concerned there were, in broad terms, 3 options:(i) Populating the gazetteer by buying in a commercially available gazetteer database and loading the data from that source into the gazetteer. In the UK a commercial gazetteer database, known as Address Point was produced by the Ordnance Survey. In the Republic of Ireland a similar gazetteer database known as GeoDirectory* was available which, it appears, was produced by the Irish Post Office (An Post) in conjunction with the Irish Ordnance Survey (OSI*). There was an obvious advantage in using commercially available data produced by the postal and mapping authorities to form the basis for the gazetteer, but equally this data would not include the hard-gleaned local knowledge which had been garnered by the fire and ambulance authorities and included in the legacy databases.(ii) Populating the gazetteer by transferring (in IT jargon, ‘migrating’) the existing legacy data held by the various authorities. This would involve writing and then running a special programme to load the data automatically from the existing computerised databases. It would also involve loading the data manually from those existing databases, where for whatever reason the data could not be loaded automatically. This had the advantage of providing the information which was unique to the fire and ambulance authorities, but equally suffered from the disadvantage that the data might not be complete or consistent, either as between individual databases or with the commercially available data.(iii) A hybrid option, using the commercially available database for the initial load, and then completing the process by integrating the legacy data from the existing databases, either automatically, or manually, or by a combination of the two. This had the advantage of combining the benefits of the commercially available and the individual systems, but also involved the challenge of welding the various data into one complete and useable database.[38]So far as that challenge was concerned, it is important to note that the extent to which the legacy data could be loaded automatically into the new gazetteer would depend on the completeness and consistency of the existing computerised databases. That was because the special programme created to load the legacy data would be designed to search for ‘matches’ of fields within the new gazetteer with fields within the existing databases, and to migrate the information held in the latter into the former. The risk was that if the existing databases were not complete or consistent, in that they did not all contain the same information stored in the same fields, the degree of successful migration (the ‘hit rate’) would be reduced.[39]In the event, as will appear, it was decided that the hybrid option should be pursued. However it is common ground that major problems were experienced in loading the legacy data onto the new database. It is common ground that this was the cause of significant delay to the project, but there is considerable disagreement between the parties as to whether this is a cause of delay which was the contractual responsibility of Sigma or of Steria.[40]It is also important to observe at this stage that one major difference between the UK and the Republic of Ireland is that there are no postcodes in the Republic of Ireland (with the exception of a postal area system in Dublin). This was obviously a hindrance to the accurate location of addresses, and the problem was compounded by the fact that:(i) the Republic of Ireland outside of Dublin is predominantly rural rather than urban;(ii) many towns or villages in different counties have identical or confusingly similar names. In addition to being a hindrance to the accurate physical location of addresses, it is also a hindrance to the accurate automatic loading of legacy data into a gazetteer created by using a commercial database, i.e. one cannot simply write a programme which searches the legacy data for a match with the specific property location and the postcode as contained in the commercial database. In order to ameliorate the problem caused by the absence of postcodes, OSI used a system known as the ‘townland’, under which a specific area is identified by reference to the largest town or village within that area. As will be seen later in this judgment, this was identified as a significant piece of data to use in the matching process. However, because there might very well be more than one townland with the same or a confusingly similar name, it was necessary to provide a further level of geographical information about each townland. In the case of GeoDirectory, that further level of information was known as the ‘posttown’, whereas in the case of the legacy data it was known as the ‘qualifier’.[41]In summary, what Steria proposed was to provide its own mobilising system, known as STORM*, which it had previously successfully supplied to a number of authorities in the UK and elsewhere. This was to be tailored to meet CAMP East’s particular requirements. The gazetteer database within STORM was itself to be loaded from a gazetteer database to be created by its proposed sub-contractor (a company initially known as SER and subsequently as Blue8*), which was known as Compass*. Thus the data, whether from the commercially available database or the legacy data or both, was first to be loaded into Compass and then to be loaded from Compass into STORM.[42]The question, therefore, is what contractual obligations were undertaken by Steria in relation to the loading of the gazetteer, and the starting point for that investigation is the CAD Specification. Answering the question is made more complicated by the fact that the CAD Specification contains a number of different sections where reference is made to this aspect of the task, and the contents of each separate section are not necessarily completely consistent with the others.[43]In §1.3.4 it was stated that the existing systems were a mix of manual and computerised systems, and that in developing a solution the tenderer would need to ‘interface with or transfer data from a number of databases or systems that exist’. Steria’s response was that it had ‘made allowance to … load important data sets such as the gazetteer into the active system’.[44]Sigma relies on this as demonstrating that Steria was made aware that there was more than one ‘legacy’ database to be loaded. I do not consider that this section can be read so explicitly; it appears to me to be more a general reference to the fact that there were a number of databases and systems of which the tenderer needed to be aware when assessing the scope of the works, rather than an explicit warning that there were a number of different legacy databases all of which would need to be loaded and integrated with each other. In any event, this section must be read subject to the further information provided by CAMP East §9.1 as to the structure and content of such databases, to which I will refer below.[45]In §1.3.7 it was stated that the tenderer would need to ‘integrate’ with the ‘local gazetteer database’. Steria responded: ‘STORM holds its own gazetteer and we propose to load this from data available inside and possibly outside the service. It will accommodate Townlands as well as more obvious addressing formats’.[46]It appears that the reference to data available ‘inside the service’ is a reference to the DFB legacy database. Again, however, it is clear in my judgment that in this section Steria was not being asked, nor did it undertake, to load all legacy data of whatever structure and content into the new system as part of the sub-contract.[47]In §1.4.2(c) Steria confirmed that it was proposing to create a gazetteer, using ‘electronic data sets from DFB and possibly Ordnance Survey (Address Point) to create a comprehensive gazetteer for the CAMP East area’. It continued: ‘Provision of Ordnance Survey Address Point data is excluded from our proposal. If, during FDS, this data set is found to be necessary to complement internal data, Bull assumes it will be ‘free-issued’ for our purposes by the CAMP East project’.[48]It is clear from this section that at this stage Steria was not committing itself to loading data from any particular dataset, and that it would not be until FDS stage that it would become apparent whether it would be necessary to use GeoDirectory (it being common ground at trial that the reference to Address Point was intended and understood as a reference to GeoDirectory – see the cross-examination of Anthony Smalldridge at 1/42-43) in addition to or instead of the DFB database. Steria was not giving any warranty that the legacy database would be suitable for loading into the gazetteer. This is not surprising since, in my judgment, there is no evidence that pre-tender Steria had been supplied with sample legacy data, or that it had been given any clear information as to the nature and quality of that legacy data.[49]In §1.5.4 it was stated that the new system would need to interface with or receive data downloads from (amongst others) the DFB mobilising system and the gazetteer system incorporating geographical data for CAMP East. In its response Steria stated:
‘The existing DFA* mobilising system holds valuable data for loading gazetteer and PDA details. A data load utility [programme] will be provided to take data … provided by the Authority and construct part of the Gazetteer. The remaining gazetteer for CAMP East will be taken from Ordnance Survey Address Point data …’
[50]It is apparent from this section that Steria was proposing to use a programme to load information currently held within the legacy data supplied by CAMP East into the gazetteer which it was to provide as part of the sub-contract. In fact, it appears that Blue8’s data load utility programme was to be used, not least because it was their database which was to be loaded and it was important to use a tool which was compatible with the database – see Anthony Smalldridge’s evidence at 1/19-20. At first reading this section appears to suggest that Steria had already decided to load data from GeoDirectory and to load legacy data, which appears to be inconsistent with §1.4.2(c) above and also with §9 below. It is an example of the inconsistency within the CAD Specification, but in my judgment it is §9 of the CAD Specification which was intended to provide the definitive statement in relation to data loading, and therefore that which prevails.[51]I should also refer in passing to §3.8.9 and §3.8.12, which make it clear – and this is not disputed – that CAMP East were required to obtain the necessary mapping* data from Ordnance Survey Ireland at their own expense.[52]Under §6, which is headed ‘service requirements’, §6.1 identified certain tasks which needed to be performed as part of the installation, ‘to ensure that the systems are installed satisfactorily’. The first such item was ‘data conversion / data loading’, and §6.1.1 stated that the tenderer would be required to ‘convert and load data sources to populate the mobilising system, for example the gazetteer’. Steria’s response was ‘Compliant. The proposal includes load utility programs to populate the mobilising gazetteer’.[53]This is consistent with §1.5.4 above. What Steria was undertaking to do was to provide and run a programme to convert and load legacy data into its gazetteer.[54]§9, entitled ‘CAMP East gazetteer’ is of considerable significance so far as this case is concerned, and I will need to make extensive reference to it. In §9.1 it was stated that the DFB has been ‘collecting geographical information and saving the data electronically to aid the production of a gazetteer of the fire authority areas’. It stated that ‘the process is complex and labour intensive but will have large benefits when the Fire Authorities and the Eastern Region Ambulance Service move to a computerised computer aided dispatch system’. It continued to say that ‘the methodology has been extended to take in the other Fire Authorities’. In its response Steria stated that it expected ‘this data to be made available in electronic form according to the structure given in this section (9.6 and 9.7)’.[55]I must therefore consider these sections. They identify and describe the structure and content of the data produced by DFB by reference to the information ‘fields’ contained in each data table. In particular, the following points should be noted:(i) The table in §9.6, which set out the geographical structure of the database and the fields used in it, showed that in relation to each individual location address in the database it was possible for there to be as many as 36 separate fields, each containing its own data. §9.6 also stated that ‘some of the fields may contain no data’. Steria’s response was that ‘the table layout is understood. A subset of these elements will be used to construct the mobilising gazetteer’.(ii) The stated purpose of §9.7, headed ‘field description’, was to describe the fields used (my emphasis). 11 fields were identified, including: (a) the ‘townland’ field, i.e. the field which contained the name of the townland within which the location is situated; (b) the ‘qualifier’ field, i.e. the field which contained the name of the area within which the townland is situated and which thus enabled one townland to be distinguished from another.) There were also ‘map ref x’ and ‘map ref y’ fields, which were intended, as their names suggest, to contain the ‘x’ and ‘y’ references of the maps of the area in which they were situated, and ‘map square’ fields, which identified locations by reference to the grid of a map (e.g. grid A1 or B2 etc). Steria’s response was that ‘these fields can be loaded into our gazetteer’.(iii) In addition to the warning in §9.6 that ‘some of the fields may contain no data’, there was also a warning in §9.5 that ‘CAMP East have used only … certain fields within the tables’, but there was no equivalent or similar warning in §9.7.[56]§9.2 contained a description of the format of the CAMP East gazetteer database. In Steria’s lengthy response there was the same reference as in section 1.4.2(c) above to the 3 alternative methods of loading the gazetteers, i.e. using the DFB generated (legacy) data alone, using free-issue GeoDirectory data alone, or using a combination of both, to be discussed post-contract award. The response continued by stating that Blue8 had extensive experience in integrating legacy data with datasets such as GeoDirectory, and explaining that they achieve a success rate ‘higher than the industry standard’ in this matching process by using a specific comparison technique and by creating bespoke matching tools for individual projects.[57]In §9.4, Steria repeated that it proposed to ‘use extracted data to populate our own gazetteer. The proposal includes the provision of a load process to take extracted data and load our gazetteer structures’.[58]In §9.8 a description was given of the ‘townland’ concept, and in §9.9 and §9.10 details were given, via a townland diagram and a flow diagram, as to the procedure used by DFB to populate its gazetteer database. It stated that DFB began by obtaining basic townland data from Ordnance Survey Ireland, and then continued by adding or confirming data using sources such as the An Post directory and the electoral ward directory, and completed the process by using the local fire station officer to confirm the information already present, and to add information based on local knowledge, such as directions to the location. The townland diagram made it clear that included in the information about the townland was its ‘qualifier’.[59]There was no suggestion in §9 either that there were marked divergences in the structure and content of the databases produced by the various fire authorities, or that there were marked divergences between the structure and content of those databases and the structure and content of commercial databases produced by OSI and/or An Post.

The FDS

[60]At this stage, it is necessary only to refer to the final version of that section of the FDS which deals with the creation of the gazetteer. This is dated 22 March 2002, and comprises 15 pages [C3/905]. It describes how data would initially be loaded onto Compass, and then how STORM would be loaded from Compass. It is clear from §1.4.2, which describes the Compass load process, that the first step was to load GeoDirectory data into Compass, and the second step was to integrate the legacy data into Compass once it had been loaded with GeoDirectory. What was envisaged by Steria was a process whereby once GeoDirectory was loaded into Compass:(i) a search would be conducted for a match between the equivalent of the townland and the qualifier fields held in the version of Compass populated with GeoDirectory and the townland and qualifier fields or levels held in the legacy data;(ii) if a match was found, then supplementary data from the legacy database would be loaded into the levels already populated from GeoDirectory;(iii) if a match was not found, a separate location record from the legacy data would be created, but there would then have to be a manual data cleansing process to remove duplicate location records. Although in cross-examination Anthony Smalldridge accepted [1/92-93] that the FDS did not state in terms that the matching process would involve a search against townlands and qualifiers, he stated – and I accept – that as a result of his discussions with Richard Sheehan CAMP East were fully aware that this was the intended match process, and also that CAMP East would have been aware of this in any event from the references in the FDS to townlands and qualifiers [4/118-119].

D. THE SCOPE OF STERIA’S OBLIGATIONS IN RELATION TO LEGACY DATA LOADING

[61]The issue between the parties is as to the effect of these detailed provisions.[62]Steria contends in §26 of its Closing as follows:(i) The legacy data was held out as being contained in a single database, of good quality and complete, and populated in accordance with §9 of the CAD Specification.(ii) Steria made no assumptions as to, nor assumed any responsibility in relation to, the quality of the legacy data.(iii) It was agreed in the FDS [§1.4.2 ‘Compass load’] that the legacy data would be loaded into Compass, after GeoDirectory had been loaded into Compass as the ‘base’ data, using the specific loading rules set out in the FDS, involving searching for data against townland and qualifier.[63]Sigma on the other hand contends as follows:(i) Steria had a ‘design and build’ obligation, which required the FDS to be prepared to the approval of the Engineer, and which required the address data (GeoDirectory and legacy) and the mapping data to be loaded and integrated with each other [§8 Closing].(ii) Steria’s obligation was to undertake the work in the manner set out in the specification or, where not so set out, to the reasonable satisfaction of the Engineer [§10 Closing], so that it was required to load all of the address and mapping data, save for manual loading, and to do so to the reasonable satisfaction of the Engineer [§§21, 22 Closing].(iii) Sigma did not warrant the quality of the legacy or other data [§23 Closing], and did, in §§9.5, 9.6 of the CAD Specification, warn Steria that the legacy data was incomplete [§25.1 Closing].(iv) By the time the FDS was prepared and approved there was a recognition by Steria that the legacy data was inaccurate and/or incomplete [§25.2 Closing].[64]Firstly, I agree with Steria that on a proper construction of the Sub-contract the Engineer has no specific role under the Sub-contract. Whilst ‘the Engineer’ is defined in the Sub-contract as having the meaning assigned to him under the main contract, such specific references as there are to the Engineer in the Special Conditions recognise his role under the main contract but do not indicate that he has a particular role under the sub-contract: see in particular clauses 8.2 and 10.1. In the absence of such reference, and given the indications in the sub-contract to the contrary, I do not consider that the general incorporation of the main contract conditions is sufficient to bring in the Engineer as having all the powers and functions in relation to the sub-contract as he would have under the main contract. In my judgment more specific words would be required for this to be so. Therefore, the sub-contract does not require issues as to the manner of performance, where not expressly specified in the contract specification, to be decided by the Engineer. Nor does the sub-contract provide for a specified mechanism for challenging any such decisions during the course of the contract, whether by adjudication or arbitration or otherwise; the arbitration clause in the sub-contract (clause 19.1) only applies where there is an arbitration under the main contract raising the same or substantially the same dispute.[65]Secondly, I agree with Steria that on a proper construction of the Sub-contract the FDS was to be agreed by Sigma (see §1.21 of the ITT Conditions) and, once agreed, would comprise one of the documents in which the detailed specification of the sub-contract work was to be defined: see Schedule 3 of the Sub-contract.[66]Thirdly, Steria was not in my judgment undertaking an unqualified obligation to load all of the legacy data into the Compass and thence the STORM gazetteer. What Steria was undertaking to do in my judgment was as follows:(1) At FDS stage, to notify CAMP East whether it was proposing to load the gazetteer using data from GeoDirectory, using data from the legacy databases, or using a combination of both, and if so how and by what means, and to obtain Sigma’s agreement as to its proposals.(2) To the extent that (as occurred) data was to be loaded from one or more of the legacy databases, to use the skill and expertise of Blue8 to provide data loading programmes to use to load the data from the legacy databases into the gazetteer in accordance with the agreed loading rules in the FDS.[67]Fourthly, CAMP East did provide information in §9 of the CAD Specification, on which Steria was entitled to rely, as to the structure and content of the legacy data which was to be made available to Steria, whether in the form of one single database or in more than one database, and Steria was entitled to expect all of the legacy data supplied by CAMP East in relation to all of the areas covered by CAMP East substantially to conform with this structure and content. In particular, that they would contain fields for the townland and the qualifier for each location address, which would contain data identifying the townland and the qualifier.[68]Dealing with Sigma’s objection that it did not warrant the accuracy of the information contained in this document, and Steria’s retort that this was irrelevant, since the document was a contract document and thus these sections were contract terms, in my judgment the position is as follows:(i) Simply because a statement is contained in a contract document does not necessarily mean that it is being warranted.(ii) Here however there is a specific contractual obligation cast upon Sigma by paragraph 8 of Schedule 11 to ensure the completeness and accuracy of all information supplied or made available to Steria unless otherwise drawn to its attention in writing. Furthermore, it was a specific term of the contract, pursuant to §9.1 of the CAD Specification, that ‘this [legacy] data would be made available in electronic form according to the structure given in … section 9.6 and 9.7’, which in my judgment means that it would as a minimum contain the data in the fields specified in §9.7.(iii) Although Sigma contends that the proviso to paragraph 8 Schedule 11 was satisfied by the warnings in §§9.5 and 9.6 that some fields and some data might not be present, in my judgment on a fair reading of §9 as a whole there was no indication either that the 11 specific fields identified in §9.7 might not be used, or that if they were there might be no data within them. Indeed, it seems to me that CAMP East was plainly stating in §9 that whatever else might not be included, the legacy data would include townland and qualifier data. I do not accept that the qualifications relied upon by Sigma were either intended to have, or actually had the effect of making it clear to Steria that if it chose to place any reliance on this information that was at its own risk and did not obviate the necessity for Steria to conduct its own investigations (or ‘due diligence’, as it was referred to at the trial) into the structure and content of the legacy databases.(iv) Furthermore, I do not consider that the references made in the FDS which are relied upon by Sigma alter the position in any material respect. There is no evidence that by this stage Sigma had advised Steria, or otherwise that Steria was aware, that the structure and content of the legacy databases was significantly different to that described in §9, so far as the essential structure and content of the legacy database or databases was concerned It appears that by FDS stage Steria was aware that the legacy data appeared to be less complete than the GeoDirectory data so far as the presence of X and Y co-ordinates was concerned, but not in relation to townlands and qualifier data, which is what they decided to use for the initial matching process as set out in the FDS: cross-examination Anthony Smalldridge 1/87-89. .(v) Therefore Steria was entitled to assume that the legacy data to be supplied by CAMP East would substantially accord in structure and in content with §9 of the CAD Specification.[69]It follows, in my judgment, that the work which Steria undertook to do was to load data from the legacy databases provided by CAMP East into the Compass gazetteer already populated by data from GeoDirectory, by a matching process using load utility programmes provided by Steria – or here its sub-contractor Blue8 - in accordance with the loading rules agreed in the FDS. By usual implication, Steria was also obliged to exercise such reasonable care and skill in so doing as might be expected from a contractor with professed skill and expertise in integrating legacy data with commercial datasets. Steria was not however in my judgment undertaking to achieve a specific result, namely to load all data from all legacy databases provided by CAMP East, regardless of whether or not that was reasonably achievable using those programmes and those rules (which had been produced on the assumption that the structure and content of the legacy databases was as described in §9.1 of the CAD Specification), if in fact the legacy databases which were provided were not substantially as described in §9.1.

E. THE TERMS OF THE MAIN CONTRACT

[70]I must now refer to the main contract, so far as relevant. The most substantial issue between the parties is as to the terms of the liquidated damages provisions of the main contract, which is said to be relevant to the question as to whether or not clause 7.1 of the sub-contract is void as a penalty.[71]The main contract is contained in a formal contract under seal dated 30 August 2001 and is made between Sigma as Contractor and the Right Honourable The Lord Mayor, Aldermen and Burgesses of Dublin as Purchaser for the execution of the main contract works for a contract price of €6,467,827. The contract itself was disclosed and appeared in the trial bundles at trial [C3/803]. However, in the same manner as the sub-contract, the detailed terms of the contract were contained in a number of specific documents which were identified in clause 2 of the contract, but it was not possible from the documents in the trial bundle to discern with complete confidence the terms of the main contract in its final agreed version. Enquiries were made during the course of the trial, and it was discovered that whilst Dublin Corporation had retained a full copy of the main contract, it had gone to storage and needed to be retrieved. In the event, however it was disclosed in time for the parties to make detailed submissions about its terms in their closing submissions.[72]As I have already indicated, the sub-contract made provision in clause 7.1 and Schedule 6 for liquidated damages to be deducted by reference to delay in 4 separate tasks, as opposed to by reference only to delay to the final task, i.e. the date for completion of SAT. It had always been Sigma’s case that the main contract contained a similar ‘sectional’ liquidated damages provision, but when he came to give evidence Mr Robinson stated that so far as he was aware that was not the position, and that under the main contract liquidated damages were only payable in the event of delay to the final task under the main contract. Nonetheless, following disclosure of the main contract, Sigma continued to maintain that the main contract did indeed contain a sectional liquidated damages provision. Although Steria continues to rely on Mr Robinson’s evidence in this regard, I agree with Sigma that since the main contract is now available, it is appropriate to look first at the terms of the main contract to seek to construe the relevant liquidated damages provision, and to proceed to consider extrinsic evidence only where necessary and appropriate to do so under the usual rules applicable to the construction of contracts in writing.[73]First, the MF/1 Conditions (which it is agreed formed part of the main contract) make provision for the parties to agree that there should be sectional completion dates, if that is what they want: see the definitions of ‘time for completion’ and ‘section of the works’ in clause 1.1. Second, the MF/1 Conditions envisage that the Special Conditions [p40 of the standard form] will be completed by inserting the time for completion, including ‘where appropriate [the] time for completion of each section of the works’. Third, clause 34.1, which is the clause in the MF/1 Conditions which deals with liquidated damages, provides as relevant that in the event of failure to complete the works within the time for completion, then the contractor shall pay or allow:
‘… the percentage stated in the Appendix of the contract value It is worth noting at this point the definition of ‘contract value’, which is ‘such part of the contract price … as is properly attributable to the plant or work in question’: clause 1.1.i. of such parts of the works as cannot in consequence of the said failure be put to the use intended for each week between the time for completion and the actual date of completion [and that] the amount so deducted shall not exceed the maximum percentage stated in the Appendix of the contract value of such parts of the works …’
[74]Here, in the final version of the main contract the liquidated damages were stated to be 1% of the contract value for each week or part week of delay, subject to a maximum of 10% of the contract price. So far as the time for completion was concerned, it was identified by CAMP East in document 2 of the ITT, under that section which refers to clause 34.1 of MF/1, as being ‘the date for completion of tests on completion as set forth in section 5.0 (programme of works and planning requirements) forming part of this contract …’. There is no indication in the use of those words that more than one completion date, corresponding to individual sections of the works, was being proposed by CAMP East. Although Sigma’s response [H2/393] stated that ‘the date for completion is detailed in our response to section 5.0, which is different to the tendered time period’, that in my judgment is a reference to a different overall completion date, rather than a counter-proposal that there should be sectional completion dates. Indeed, it does not appear that Sigma’s response to section 5.0 of that document specified sectional completion dates. Thus:(i) In its response to section 5.1, in which it is required to complete a bar chart (Gantt) showing ‘the programme to meet the completion of the works’, Sigma referred to its project plan submitted as Addendum A to its letter dated 26 June 2001 ‘for an outline’.(ii) This outline project plan showed a 15 month contract period, beginning with contract award on 29 June 2001 and ending at the end of September 2002. It includes what appears to be 6 main items, including Steria’s works as one such item, which are sub-divided into 50 separate items in total. The dates for Steria’s works are as follows:• Completing the FDS in 60 days, i.e. by a date in early October 2001.• Undertaking FAT1 in December 2001.• Undertaking FAT2 in April 2002.• A further 100 days for delivery, installation and configuration, followed by 10 days for SAT in September 2002.(iii) In its response to section 5.1.4 Sigma proposed a project plan ‘with contractual commitment to complete all works within 18 months, with aspiration to complete the works within 15 months’.[75]Although Sigma contends [§53 Closing] that these dates are ‘entirely consistent with the LAD milestone dates in the sub-contract’, and although (save with the exception of FDS) that would appear to be correct, this in my judgment does not go so far as establishing that the dates for completion of the individual tasks in the outline project plan were each intended to be separate sections of the works. In my judgment clear and unambiguous words would need to be used to make it plain that what was being proposed was a series of up to 50 sectional completion dates. Here, the only sensible conclusion is that the only relevant completion date under the main contract was the date specified for overall completion in the outline project plan. In my judgment therefore, Mr Robinson was correct in his understanding that the liquidated damages provisions of the main contract only provided for liquidated damages to be paid in the event of delay to the date for completion of the final task under the main contract, i.e. completion of the tests on completion. This is also consistent with the admitted fact that at no time did CAMP East actually levy liquidated damages against Sigma; if there had been sectional completion dates in the main contract which were the same as the sectional completion dates in the sub-contract, then prima facie CAMP East would have been entitled to levy liquidated damages against Sigma in relation to the delay in achieving those dates which, if Sigma be right, was not the contractual responsibility of CAMP East.[76]The only other relevant provision of the main contract to which I need refer is clause 33.1 of MF/1 which made provision for extensions of time in certain specified circumstances, and which required the contractor to give notice ‘as soon as practicable’ and to ‘provide full supporting details’.

F. THE EXTENSION OF TIME PROVISIONS OF CLAUSE 6.1 OF THE SUB-CONTRACT

[77]As I have already observed, a number of disputed issues have arisen between the parties as to the proper construction of this clause.[78]The first issue is whether or not the requirement in clause 6.1 for Steria to give written notice of the circumstances giving rise to the delay within a reasonable period is a condition precedent to its right to an extension of time. Whilst Steria contends principally that clause 6.1 is not a condition precedent, or if it is that:(a) it complied with that requirement; alternatively(b) Sigma has waived the requirement for compliance / is estopped from complaining of non-compliance; the further issue of law which arises if those arguments are unsuccessful is Steria’s contention that if delay has been caused due to acts of prevention by Sigma (including for this purpose CAMP East and/or Mason) and if Steria has failed to give notice in compliance with clause 6.1, then the result is that the time for completion is set at large. This argument relies on what has become known as the ‘prevention principle’.[79]The second issue is what is required by this clause in terms of notification. Is Steria simply required to give written notice of the circumstances giving rise to the delay, or is the notice also required to do one or more of the following things:(a) to state that Steria is delayed by the circumstances in question;(b) to state what delay has been caused, and/or how the circumstances have caused that delay;(c) to state that Steria is seeking an extension of time;(d) to state that it is a notice under clause 6.1? Furthermore, can written notice extend beyond communications by letter, fax and/or e-mail to minutes of meetings and/or to delivery of pleadings?

What is required of a notice under clause 6.1?

[80]It is convenient to deal with the second issue first. Steria’s case is that the wording of this part of the clause is clear and unambiguous, and there is no warrant for reading in to the clause matters which were not expressly included, particularly in circumstances where both parties may be assumed to be familiar with the wording of standard forms of contract such as MF/1 which do contain more detailed provisions as to the form and content of any notice seeking an extension of time. Sigma’s case [§70(4) Closing] is that, whilst the clause is admittedly relatively undemanding in its requirements, nonetheless:(a) the notice must make it clear that it is a request for an extension of time under clause 6.1 so as to enable Sigma to take appropriate action, such as taking steps to avoid or mitigate the delay and/or making an onwards claim under the main contract;(b) the notice must explain how and why the relevant circumstances have caused delay;(c) the notice must give an assessment of the delay In its response to Steria’s closing submissions Sigma accepted that this was a ‘should’ rather than a ‘must’ [paragraph 1.2]. .[81]In my judgment, the requirement for Steria to give notice of the circumstances giving rise to the delay cannot be extended to include a requirement that the notice must make it clear that it is a request for an extension of time under clause 6.1, or to include a requirement that it gives an assessment of the delay. Both would involve reading into the clause words which are not there, and which do not meet the stringent requirements for implication of such terms. I do not however accept Steria’s argument that all that is required is a notification that particular relevant circumstances have occurred. In my judgment it is necessary for Steria to notify Sigma first that identified relevant circumstances have occurred and second that those circumstances have caused a delay to the execution of the sub-contract works. In my judgment the latter is required, either by a process of purposive construction or by a process of necessary implication, because otherwise it seems to me that the notice would not achieve its objective; a communication by Steria that, for example, CAMP East was delaying in approving the FDS, without also stating that in consequence the sub-contract works were being delayed, would not achieve the essential purpose of the notification requirement. I am unable however to accept Sigma’s submission that the notice must go on to explain how and why the relevant circumstances have caused the delay. That would be to import a requirement for Steria to provide a level of detail in the notice which goes beyond the simple notification which is of the essence of the clause.[82]I also consider that the written notice must emanate from Steria. Thus for example an entry in a minute of a meeting prepared by Mason which recorded that there had been a delay by CAMP East in approving the FDS, and that as a result the sub-contract works had been delayed, would not in my judgment by itself amount to a valid notice under clause 6.1. The essence of the notification requirement in my judgment is that Sigma must know that Steria is contending that relevant circumstances have occurred and that they have led to delay in the sub-contract works. Therefore, whilst in principle service of a statement of case by Steria in which such a notice was given could be effective, the question in such circumstances would always be whether or not it was given within a reasonable period, as required by clause 6.1.

Is the notice requirement a condition precedent?

[83]I now turn to the question as to whether or not the notification requirement is a condition precedent. Of course this question will only arise for decision if I conclude that Steria failed to give proper notification under clause 6.1, but it is convenient to consider the argument at this stage in any event.[84]Sigma’s case is that the use of the word ‘provided’ imposes a clear and unqualified condition precedent, the purpose of which enables it to conduct a contemporaneous investigation, so as to enable it to take appropriate action (for example, as before, by taking steps to avoid or mitigate the delay and/or by making an onwards claim under the main contract), and to award at the appropriate time such extension as may be justified.[85]Steria’s case is that:(i) clear words are required to make a notification provision a condition precedent;(ii) the contra proferentum rule applies, so that any ambiguity will be construed strictly against the party seeking to contend that it is a condition precedent;(iii) here, clause 6.1 does not make it plain by express language that unless the notification provision is complied with Steria will lose its right to an extension of time (and thus be subject to liquidated damages);(iv) here, the notification provision is neither clear or precise as to the period within which the notice has to served (what is a reasonable period, what triggers the start of the reasonable period, etc.). Steria’s case is that this does not deprive the notification provision of effect; thus Sigma would still have a claim for damages in the event of breach, which could be substantial where e.g. it could prove that had Steria given notice in time it could have taken steps to minimise its liability which by reason of the lack of notice it was unable to do. Indeed Steria goes further and submits that the notification provision may properly be construed as an innominate term, such that a sufficiently serious failure to give notice might enable Sigma to reject the claim for an extension of time: §§130-131 Closing.[86]In response, Sigma submits that:(i) since the notification provision only deprives Steria of a contractual right to an extension of time, as opposed to a common law right (such as a right to recover damages for breach of contract), the ‘clear words’ requirement does not apply;(ii) the contra proferentum principle does not apply, because the clause was originally proposed by Steria Steria objected to this point being taken, because the evidence – which only emerged in closing submissions – did not conclusively determine that it was necessarily Steria which first put forward the clause. ;(iii) in any event, the clause is not ambiguous and the wording is clear. Sigma also submitted that the authority relied upon by Steria in support of its ‘innominate term’ argument, Alfred McAlpine v. BAI (Run Off) [2001] Lloyd’s Rep 353 [CA], is a case which relates to an insurance contract so that the rationale in that case cannot sensibly be applied to extension of time clauses such as this.[87]In Multiplex Construction v. Honeywell Control Systems [2007] EWHC 447 (TCC) Jackson J. reviewed the more important authorities on extension of time clauses, and derived 3 propositions from them, the relevant one of which is contained in sub-paragraph 56(iii):
‘Insofar as the extension of time clause is ambiguous, it should be construed against the contractor.’
[88]He went on, however, to observe as follows:
‘57. The third proposition however must be treated with care. It seems to me that, in so far as any extension of time clause is ambiguous, the court should lean in favour of a construction which permits the contractor to recover appropriate extensions of time in respect of events causing delay. This approach also accords with the principle of construction set out by Lewison in ‘The Interpretation of Contracts’ (3rd edition, 2004). That principle reads as follows: ‘Where two constructions of an instrument are equally plausible, upon one of which the instrument is valid and upon the other of which it is invalid, the court should lean towards that construction which validates the instrument.’ 58. That principle is supported by a line of authority as set out in paragraph 7.14 and is encapsulated in the Latin maxim verba ita sunt intelligenda, ut res magis valeat quam pereat.’
[89]I respectfully agree. In my judgment an extension of time provision confers benefits on both parties; in particular it enables a contractor to recover reasonable extensions of time whilst still maintaining the contractually agreed structure of a specified time for completion (together, in the majority of cases, with the contractual certainty of agreed liquidated damages, as opposed to uncertain unliquidated damages). So far as the application of the contra proferentum rule is concerned, it seems to me that the correct question to ask is not whether the clause was put forward originally by Steria or by Sigma; the principle which applies here is that if there is genuine ambiguity as to whether or not notification is a condition precedent, then the notification should not be construed as being a condition precedent, since such a provision operates for the benefit of only one party, i.e. the employer, and operates to deprive the other party (the contractor) of rights which he would otherwise enjoy under the contract.[90]Turning to the wording of the clause, in my judgment the phrase ‘provided that the sub-contractor shall have given within a reasonable period written notice to the contractor of the circumstances giving rise to the delay’ is clear in its meaning. What the sub-contractor is required to do is give written notice within a reasonable period from when he is delayed, and the fact that there may be scope for argument in an individual case as to whether or not a notice was given within a reasonable period is not in itself any reason for arguing that it is unclear in its meaning and intent. In my opinion the real issue which is raised on the wording of this clause is whether those clear words by themselves suffice, or whether the clause also needs to include some express statement to the effect that unless written notice is given within a reasonable time the sub-contractor will not be entitled to an extension of time.[91]In my judgment a further express statement of that kind is not necessary. I consider that a notification requirement may, and in this case does, operate as a condition precedent even though it does not contain an express warning as to the consequence of non-compliance. It is true that in many cases (see for example the contract in the Multiplex case itself) careful drafters will include such an express statement, in order to put the matter beyond doubt. It does not however follow, in my opinion, that a clause – such as the one used here - which makes it clear in ordinary language that the right to an extension of time is conditional on notification being given should not be treated as a condition precedent. This is an individually negotiated sub-contract between two substantial and experienced companies, and I would be loathe to hold that a clearly worded requirement fails due to the absence of legal ‘boilerplate’.[92]In those circumstances I do not need to consider Steria’s further submission as to the true construction and effect of the notification provision if it is not a condition precedent. I can see the force of the submission that in some cases the right to recover damages for breach would provide an adequate remedy for Sigma; equally I can see that there would be many cases where it would be difficult if not impossible for Sigma to identify or prove the necessary elements of such a claim to the requisite standard. I can also see that construing such a requirement as an innominate term may have some attractions, but since the point was only identified in Steria’s Closing, and since I have not heard full argument on the point, it would be unwise as well as unnecessary for me to express any opinion on the point.

The application of the ‘prevention’ principle

[93]It is convenient at this stage also to address the prevention principle argument, even though again the point will only arise for decision if I find first that Steria had failed to give the requisite notices and second that Sigma had not waived, or was not estopped from relying on the absence of, the requisite notices.[94]I am extremely fortunate in that I have the benefit of the analysis of Jackson J. in the Multiplex case of the conflicting Australian authorities (Turner, Gaymark and Peninsula), the decision of the Court of Session in City Inn v Shepard Construction 2003 SLT 885, and the views expressed both by the editors of Keating on Building Contracts and by the late Professor Wallace QC. In summary, Jackson J. concluded in paragraph 103 that:
“I am bound to say that I see considerable force in Professor Wallace’ criticisms of Gaymark. I also see considerable force in the reasoning of the Australian courts in Turner and in Peninsula and in the reasoning of the Inner House in City Inn. Whatever may be the law of the Northern Territory of Australia, I have considerable doubt that Gaymark represents the law of England. Contractual terms requiring a contractor to give prompt notice of delay serve a valuable purpose; such notice enables matters to be investigated while they are still current. Furthermore, such notice sometimes give the employer the opportunity to withdraw instructions when the financial consequences become apparent. If Gaymark is good law, then a contractor could disregard with impunity any provision making proper notice a condition precedent. At his option the contractor could set time at large.”
[95]Although on the facts of that case Jackson J. did not, due to the particular wording of the extension of time and liquidated damages clauses employed, need to express a final decision on the point, nonetheless I gratefully adopt his analysis and agree with his preliminary conclusion. Generally, one can see the commercial absurdity of an argument which would result in the contractor being better off by deliberately failing to comply with the notice condition than by complying with it. Furthermore, when applied to the facts of this case, particularly acute difficulties arise when considering how the application of the prevention principle should work in practice. Thus clause 6.1 permits an extension of time in 3 relevant circumstances, one of which is ‘any circumstance which entitles the contractor to an extension of time under the main contract’. Clause 33.1 of MF/1 (the main contract term relating to extension of time), allows an extension of time in 4 specified circumstances, one of which is ‘any industrial dispute’ and the other of which is ‘circumstances beyond the reasonable control of the contractor arising after acceptance of the works’. Does the prevention principle apply to such circumstances? It is difficult to see why they should, since these circumstances cannot readily be characterised as acts of prevention by the employer. If not, however, is the effect that the notice procedure is a condition precedent in relation to delays caused by those events, but not to delays caused by other events? That would produce an inconsistent and undesirable result. Furthermore, in addition to conferring a right to an extension of time, clause 6,1 also confers a right on Steria to recover ‘all extra costs incurred in relation to [the delay] together with a reasonable allowance for profit’. Does the prevention principle mean that Steria could obtain these benefits even if it had not complied with the notice condition precedent? Again, that would appear to involve the contractor obtaining a benefit from his own breach, which is the converse of the prevention principle and hence might be said to be equally objectionable, but to construe the clause such that Steria was entitled to an extension of time even if it did not comply with the notice condition, but not to an extra payment, would again in my judgment be inconsistent and undesirable.[96]In its closing submissions [§134] Steria invites me to distinguish Multiplex on the grounds that it contained a clear and unambiguous notice condition precedent clause, unlike that found here. It does not seem to me that strictly speaking any question of distinguishing Multiplex arises since, as I have already noted, in that case Jackson J. did not need to reach an actual decision on the point. However I must confess that I cannot see that the particular form of the clause used in that case is relevant to the analysis of the authorities and the provisional conclusion reached. In any event I am, as I have already said, respectfully in agreement with Jackson J. Gratefully adopting therefore the reasons which he gives in that case, together with the further reasons set out above in relation to the particular clause in this case, I conclude that the prevention principle does not mean that failure to comply with the notice requirement of clause 6.1 puts the time for completion at large.[97]A separate but connected argument advanced by Steria was that one cause of delay, namely delay due to negotiations between the DFB and its employees’ trades union in relation to the introduction of the new system The submission being that negotiations which do not flare into an ‘industrial dispute’ are not covered by this part of clause 33.1 MF/1. , fell outside the scope of the relevant circumstances provided for by clause 6.1 and thus, in the event that delay was caused by this circumstance, would amount to prevention for which Sigma was responsible for which an extension of time was not available, with the result that time for completion was set at large. Although ingenious, in my judgment the argument fails because that cause of delay would either fall within the definition of ‘circumstances beyond the reasonable control of the contractor arising after acceptance of the works’ (and thus within clause 33.1 MF/1), or a ‘breach by the contractor’ (because the effect of delay caused by such ongoing negotiations would amount to breaches by Sigma of its positive obligations in Schedule 11 of the sub-contract).

G. IS CLAUSE 7.1 OF THE SUB-CONTRACT A VALID LIQUIDATED DAMAGES CLAUSE OR A PENALTY?

[98]I must now deal with Steria’s contention that clause 7.1 is a penalty clause.[99]Steria has referred me to Murray v Leisureplay [2005] EWCA Civ 963, a case in which the Court of Appeal subjected the law on penalty clauses to a detailed scrutiny in the context of a clause requiring the defendant employer to pay the claimant employee a year’s gross salary in the event of wrongful termination without notice. Steria has also referred me to Alfred McAlpine Capital Projects v Tilebox [2005] EWHC 281 (TCC), in which Jackson J. considered the law on penalty clauses in the context of a dispute arising under a construction contract. Sigma has referred me to the Tilebox case and also to the case of Philips Hong Kong v AG for Hong Kong (1993) 61 BLR 49, a decision of the Privy Council which was discussed in both cases.[100]So far as I can discern there is no significant dispute between the parties as to the legal principles which I should apply. Thus Sigma contended that the question for me, in the light of Murray, was whether Steria could show that the liquidated damages provision in clause 7.1 was ‘extravagant, unconscionable and not a genuine pre-estimate of loss’ (see the judgment of Clarke L.J. at §106(vii)). Steria referred me to the same judgment at §106(iv) where Clarke L.J., referring to the decision of Colman J. in Lordsdale Finance v Bank of Zambia [1996] QB 752, concluded that the real question for the court was whether the contractual function of the clause was deterrent or compensatory, and that one guide to answering this question was to compare the amount which would be payable on breach with the loss that might be sustained if the breach occurred. In Tilebox Jackson J. considered that there must be a substantial discrepancy between the level of damages stipulated in the contract and the level of damage which is likely to be suffered before it can be said that the agreed pre-estimate is unreasonable. I must however also bear in mind that this is only a guide, and does not necessarily always provide the answer by itself, because – as was emphasised by Buxton L.J. in Murray at §111 and by Jackson J. in Tilebox at §48.3 – the question is a broad and general question, and that in commercial contracts the courts should exercise great caution before striking down a clause as penal.[101]I have already found, contrary to Sigma’s primary case, that the liquidated damages provisions of the main contract did not contain any provision for sectional liquidated damages. In such circumstances, Steria submits that because clause 7.1 provides for liquidated damages to be levied in the event of delay in completion of the first 3 tasks, regardless of whether or not they also delay the last of the 4 tasks, and because it is impossible to see how Sigma would suffer any loss unless the last of the 4 tasks was delayed (i.e. unless there was a delay to overall completion), then clause 7.1 must be penal because there is a substantial discrepancy between the amount payable on breach and the level of damages likely to be suffered. So, for example, a delay of 4 weeks to overall completion would equate to a liability to liquidated damages under the main contract of 4% of the contract value, whereas a delay of 4 weeks to each of the first 3 tasks which did not translate to a delay in overall completion would result in no liability at all under the main contract, but would still result in a substantial liability under the sub-contract.[102]It is, as I understand it, further submitted by Steria that this is so regardless of the liquidated damages provisions of the main contract, although in my judgment this cannot be right; if the liquidated damages provisions of the sub-contract were truly back-to-back with the liquidated damages provisions of the main contract, then it would be perfectly possible for Sigma to suffer loss on delay in each of the 3 tasks regardless of whether that resulted in delay to overall completion.[103]It is also submitted by Steria that there is a significant imbalance even if one considers the case of a delay in tasks 1, 2 or 3 also leading to delay in overall completion. However in my judgment this is not necessarily correct. The point which must be remembered is that the liquidated damages provision in the sub-contract amounts to 0.25% of the contract value per week of delay for each task The figure for liquidated damages per week in Schedule 6 of IR£6,055.08 is 25% of IR£24,234, which is 1% of the total contract value of IR£2,422,339.52 – see Schedule 4. , compared to 1% of the contract value in the main contract per week of delay to overall completion. Thus, even leaving to one side the fact that in money terms 1% of the sub-contract value amounts to only 0.5% of the main contract value, one can see that there is not necessarily any or any significant imbalance in every case. To take 2 examples:(i) 3 weeks’ delay in task 1 which is not caught up in successive tasks. This therefore feeds through to 3 weeks’ delay to tasks 2, 3 and 4 under the sub-contract and also to overall completion under the main contract: Here under the main contract liquidated damages would be 1% x 3 weeks = 3%, whereas under the sub-contract liquidated damages would be 0.25% x 3 weeks x 4 = 3%.(ii) 3 weeks’ delay in each of tasks 1, 2, 3 and 4 under the sub-contract which is not caught up in each successive task. This therefore feeds through to 6 weeks’ delay in task 2, 9 weeks’ delay in task 3, and 12 weeks’ delay in task 4 and also 12 weeks’ delay to overall completion under the main contract. Here under the main contract liquidated damages would be 1% x 12 weeks = 12% (but capped at 10%), whereas under the sub-contract liquidated damages would be 0.25% x 3 + 0.25% x 6 + 0.25% x 9 + 0.25% x 12 (but capped at 2.5%) = 7%.[104]It is also pertinent to note that both under the main contract and under the sub-contract the total liability for liquidated damages is capped at 10% of the respective contract value; this is not a case where Sigma had negotiated a cap on its liability but was seeking not to pass on the benefit of a similar cap to its sub-contractor.[105]Furthermore, as submitted by Sigma, delay by Steria in tasks 1 -3 may cause loss and damage to Sigma even though in the event Steria catches up and thus there is no overall delay to task 4. Thus delay by Steria in tasks 1-3 might well disrupt or delay Sigma and/or its other sub-contractors in their respective works, thereby leading to Sigma incurring loss and expense which it is unable to recover from CAMP East under the main contract, and also resulting in its being exposed to delay and disruption claims from other sub-contractors which it can not pass up the line to CAMP East.[106]In such circumstances, in my judgment:(i) there is no substantial discrepancy between the liquidated damages provisions of the sub-contract and the level of damages likely to be suffered by Sigma;(ii) on the facts of this case I am unable to conclude that the clause was – objectively considered as at the date the contract was entered into – intended to be deterrent rather than compensatory. Overall, this being a commercial contract entered into between two substantial and experienced companies with knowledge of the difficulties which can occur where after the event one party seeks to recover general damages from the other for delay, I am not prepared to strike down the clause as penal.[107]A separate argument relied upon by Steria was that assuming, as I have already found, the notice requirement is a condition precedent, the clause is penal because it requires Sigma to pay liquidated damages in the amounts provided, not for delay, but for breach of the notice requirement itself. Although again ingenious, again I reject Steria’s submission as an attempt by the back-door to invoke the prevention principle. The liability will only arise if Steria fails to complete the task within the stipulated time; that is the breach for which the liquidated damages are recoverable. The additional factor, which is that liquidated damages will only be recoverable either if Steria has no reasonable excuse for that failure (i.e. because the delay is not caused by a relevant circumstance within clause 6.1) or because, despite having reasonable excuse it fails to comply with the notice requirement, is irrelevant to this point.

Is the liquidated damages provision of the sub-contract contractually uncertain?

[108]A further argument advanced by Steria is that there is a fundamental inconsistency between clause 7.1 and Schedule 6. The point which is taken is that what Steria is liable to pay under clause 7.1 is ‘the percentage (stated in the Sixth Schedule) of the sub-contract value of that part of the sub-contract works as cannot in consequence of the delay be put to the purpose intended for each week between [the] time for completion and the actual date of completion’. The sub-contract value is defined in clause 1.1 as being ‘such part of the sub-contract price … as is properly apportionable to the sub-contract plant or work in question’. (This is consistent with the main contract – see clause 34.1 of MF/1 noted at paragraph 73 above, and it is also consistent with what appears in §4.5.1.2 of the ITT Contract Specification.) However, what Schedule 6 states is that ‘Per paragraph 4.5.1 of CAMP tender document 2. 4.5.1.2. The percentage of the sub-contract price for the works to be paid or deducted for each week of delay shall be 1%’.[109]The effect of this is as follows, according to Steria:(i) The clear intention behind clause 7.1, consistent with the terms of MF/1, is that the liquidated damages for delay in completion of any particular task are to be ascertained by reference to the contract value of that particular task. So, to take an example by reference to a typical building contract, if there is a project for the development of 4 houses, and completion of one house is delayed, then liquidated damages are to be assessed by reference to the value of that house as opposed to the whole sub-contract price.(ii) Here, there is no provision in the sub-contract under which the sub-contract value of a particular task in Schedule 6 can be ascertained, and instead Schedule 6 purports to identify it by reference to an incorrect extract from the ITT Contract Specification. (I note that in Schedule 4, which sets out the sub-contract price, whilst a specific sum is allocated to the FDS, there is no specific sum allocated to FAT2, to delivery, to installation, or to SAT.)(iii) Therefore, either the liquidated damages provision is so inconsistent as between clause 7.1 and Schedule 6 that it fails for uncertainty or, in order to satisfy clause 7.1, Sigma was obliged but failed to plead and to prove the sub-contract value of each task which it contends was in delay.[110]Sigma however contends that the specific sums stated in the table to Schedule 6 represent the parties’ agreement as to the sub-contract value attributable to each task, and therefore that there is neither ambiguity nor uncertainty, nor is there any need to lead evidence on the point. (Sigma also contends that by clause 1.2 of the sub-contract the Special Conditions, including Schedule 6, takes precedence over – presumably – the ITT Contract Specification, but in my judgment that cannot be right, because clause 1.2 appears to accord equal precedence to all of the Schedules other than Schedule 1, and Schedule 2 identifies the ITT Contract Specification, the CAD Specification and the MIS Specification as contract documents.)[111]It is clear in my judgment that clause 7.1 envisages that there will be a percentage figure appearing against each task in Schedule 6, and also that there would need to be either a stated value against each particular task, or an investigation as to the contract value of each particular task, before the figure for liquidated damages could be ascertained. It is equally clear that instead of doing this Schedule 6 identifies a specific amount as being the figure for liquidated damages to be applied to each week of delay for each task, and that the way in which this is done is simply – and doubtless artificially – to apportion 25% of the contract price as being the contract value of each task.[112]The question is whether the court should give effect to this, or whether it should hold either that this is fundamentally inconsistent with clause 7.1 or that more is required to meet the requirements of clause 7.1. In answering that question I consider that my task is to construe the sub-contract, if I can properly do so, in a way which makes commercial sense and which does not frustrate the overall object of the sub-contract.[113]In my judgment, Schedule 6 identifies the sub-contract value applicable to each task, and in so doing avoids what might otherwise be the difficult and expensive task of ascertaining the sub-contract value after the event when the parties are in dispute. Whilst it may be said that the approach is artificial, nonetheless in a rough and ready way it is not unjust, and if the parties have selected this method it is not in my judgment appropriate for the court to subject that choice to an unduly legalistic scrutiny. I therefore reject Steria’s arguments on this point, and hold that liquidated damages should be applied to delay in completion of the tasks in the amount per week specified in Schedule 6, without the need for more.[114]Having upheld the liquidated damages provisions of clause 7.1 and Schedule 6, it is unnecessary for me to consider the further argument as to whether the cap in those provisions would also apply to cap the alternative claim for general damages. It is clear in my judgment from the concluding words of clause 7.1 that the entitlement to liquidated damages is Sigma’s sole remedy for delay by Steria, so that it is not possible for Sigma to advance its claims for general damages as an alternative. If I had needed to decide the point, I would have inclined to the view that if the liquidated damages provision is held to be penal, then it prevents either party from relying on it, so that the cap also disappears.

H. CAUSES OF DELAY AND DELAY NOTICES

[115]Having considered at what I fear may be inordinate length the contractual and legal disputes which have arisen in this case, I must now turn to the disputed issues of fact. Fortunately, although there has been a considerable amount of evidence and argument about the causes of delay, the parties were largely in agreement that the most substantial cause of the delay to the project overall was the delay due to the need to integrate the legacy data with the GeoDirectory, and I have of course already made findings as to the correct interpretation of the contract so far as this is concerned. I have also made findings as to what was required in terms of the notices required under clause 6.1.

The individual witnesses

[116]As I indicated at the beginning of this judgment, I heard evidence over 5 days from 5 witnesses in total. They were cross-examined in detail on the content of their witness statements and the relevant documents. There were many areas where their oral evidence illuminated the documentary evidence, and thus the controversy between the parties. There were other areas where their oral evidence filled in gaps in the documentary evidence. There were also some, but relatively few, areas where their oral evidence was inconsistent either with the documentary evidence or with other oral evidence given in the case. It is obviously difficult for witnesses to put themselves in the same position as they were at the time of the events in question, now some 4-6 years ago, given the effects of the passage of time on their recollections. Furthermore, given that their employers or ex-employers have been involved in hostile litigation for some years now, it was apparent to me that all of the witnesses had, in varying degrees, become involved in the entrenched positions taken by the parties. Notwithstanding these reservations, my overall impression was that the witnesses were both honest and generally reliable, and that the principal differences between them related more to their differing opinions as to the reasons behind the delay to the project than to genuine disputes of factual recollection.[117]So far as the individual witnesses are concerned, in order in which they gave evidence my overall assessment of them was as follows:

Anthony Smalldridge

[118]Anthony Smalldridge, Steria’s STORM product consultant, played a significant part in the technical aspects of the project. He is still an employee of Steria. He was in my judgment a palpably honest witness with a good technical knowledge and a good recall of events. He was understandably a little defensive under cross-examination, but I did not regard his evidence as being unduly partisan.[119]In its closing submissions [§39 et seq] Sigma contended that the inaccuracies in his witness statement, which he was prepared to verify and adopt, and in his evidence were such that I could not confidently accept his evidence as reliable. In particular, reliance was placed on what was said to be Anthony Smalldridge’s ‘change of case, obstruction and evasion’ in relation to the allegation that initially Steria’s complaint was that instead of being one database there were many databases with different structures, whereas subsequently it transpired that Steria’s true complaint was as to the differing data content within the different databases. My attention was directed to specific parts of Anthony Smalldridge’s cross-examination which it was said supported Sigma’s case on this point.[120]Having considered the various parts of the evidence on which reliance is placed by Sigma, I do not consider that they bear the weight sought to be placed on them.(i) I do accept that whilst initially one of Steria’s complaints was that they had been presented with a number of different databases with different structures, under cross-examination Anthony Smalldridge accepted that this was not so significant a problem as that caused by the differences in data content Although he said that he had expected the data sources to have been in one common data format: 1/32-33, he also accepted that Steria would have been able to deal with the problem that data was in different data tables [1/71]. .(ii) However, I also agree with Steria that this was not, and never had been, Steria’s sole complaint as to the legacy databases. It is quite clear from, for example, paragraph 6 of Anthony Smalldridge’s witness statement that his essential complaint was that the legacy data was neither complete nor consistent. In paragraph 8 he stated quite clearly that the problem was not that the data was contained in separate databases or folders, but that the classification of the data was inconsistent and the data was ambiguous. In paragraph 9 he stated quite clearly how that led to the problem in matching and thus merging the data in the legacy databases with the data already loaded from GeoDirectory. Although under cross-examination he accepted that his further complaint in that same paragraph, that the ‘structure’ of the databases was inconsistent, was not one which he pursued, that does not in my judgment in itself invalidate his other complaints.(iii) Moreover, in my judgment the difference between the structure and the content of the databases is not quite so clear cut as was suggested by Sigma, and indeed accepted by Anthony Smalldridge under cross-examination. It appears to me that the difference is more one of semantics than of substance. I do not consider that Anthony Smalldridge perceived the difference at the time in the same stark terms as was suggested by Sigma at trial.(iv) Steria’s essential complaint was that the legacy data was not complete or consistent, and the essence of that complaint was that the legacy data did not contain data within the fields identified in §9.7 of the CAD Specification, with the consequence that it could not be loaded into Compass using the loading rules (which had been devised on the assumption that it did), so as to achieve a matching rate acceptable to CAMP East. In my judgment the issue as to whether or not that is properly described as a failing in the structure of the database, or a failing in the content of the data within it, is not a point of real significance, and as I have already said was not perceived as such by Anthony Smalldridge either at the time of the events in question or later when he prepared his witness statement.(v) Finally, and in some ways most importantly, what one sees from the cross-examination is that Anthony Smalldridge was neither obstructive nor evasive during cross-examination when it was suggested to him that there were inaccuracies in particular parts of his witness statement, or that his complaints about the legacy data being in different databases or having inconsistent structures were irrelevant to the problems actually experienced. Whilst I agree that this demonstrates that Anthony Smalldridge was at fault in verifying a witness statement which contained passages which he agreed to remove or modify under cross-examination, nonetheless his frank willingness to do so reinforces my overall impression of him as an honest and basically reliable witness.

Paul Kearney

[121]Paul Kearney was Sigma’s project manager responsible for this project until October 2002. He is no longer employed by Sigma, but appeared to have left on good terms, so much so that he was willing to assist by giving evidence by video-link from New Zealand, where he now lives and works. He was also in my judgment a palpably honest witness with a reasonably good knowledge and recall of events. He clearly regarded himself as having been very much a mediator and a facilitator in his dealings with Steria and CAMP East, and that showed through in the contemporaneous correspondence generated by him. He also accepted that he was no expert in the technical details of data integration, being very much a communications engineer by training and experience, and thus he relied heavily on what he was told by others. His evidence was coloured to some extent by his overall perception that Steria had failed to conduct a reasonably thorough ‘due diligence’ exercise on the legacy data before committing himself to the sub-contract, but again I did not recall his evidence as unduly partisan.

Shaun McGinley

[122]Shaun McGinley was Sigma’s project manager responsible for this project after October 2002. He is still employed by Sigma and, to my mind, was significantly more partisan in his evidence than either Anthony Smalldridge or Paul Kearney. That may well be because when he took over as project manager he was fairly junior and, so it appeared to me, had little knowledge or experience of the project or the technical details behind it, and therefore appears to have accepted fairly uncritically the Sigma / CAMP East ‘party line’, which by October 2002 appears to have been that Steria was fully responsible for all aspects of data integration, other than manual loading.

David Cartwright

[123]David Cartwright was Steria’s project manager employed throughout on this project. He is still employed by Steria. He had recently undergone major surgery, but that did not appear to diminish his tenacity in dealing with detailed cross-examination by Mr Blunt QC. He appeared to have a good recall of most significant events, and a reasonable knowledge of the technical details, although not as detailed as that of Anthony Smalldridge. I assess his evidence as being rather more partisan to Steria’s case than that of his colleague Anthony Smalldridge.[124]In the same way as with Anthony Smalldridge, in closing submissions Sigma has submitted that David Cartwright was not a reliable witness. Again, I have considered the passages from the transcripts of his cross-examination to which I was referred. They demonstrate that under cross-examination David Cartwright accepted that certain parts of his witness statement contained factual errors, often it appeared because neither the lawyer who drafted the statement nor David Cartwright had checked that documents referred to actually stated what the witness statement said that they did. They also demonstrate that his acceptance of these errors was sometimes less immediate than was the case with Anthony Smalldridge.[125]Sigma has also submitted that David Cartwright’s repeated ‘mantra’ that CAMP East was causing delay reflected his inability or unwillingness to accept that many of the delays of which he complained were non-critical. An example given was David Cartwright’s complaint about the delay by CAMP East in providing accommodation at OBI in a state which was fit for Steria to install and commission its servers. It was submitted that under cross-examination David Cartwright agreed that this was irrelevant, because in fact SAT could not have proceeded at that time anyway because the legacy data had still not been loaded to the extent required by CAMP East. Whilst this is correct, David Cartwright’s maintained position under cross-examination was that neither of these causes of delay were Steria’s responsibility, so that in my judgment it was not unreasonable for him to point out that there were 2 reasons for delay over this period, both of which in his opinion were not Steria’s responsibility. The criticism also ignores the fact that David Cartwright stated in evidence that it would have been possible to achieve SAT at that time without completing the loading of the legacy data to the level required by CAMP East, had CAMP East been willing to relax their requirement as to data loading and had the accommodation at OBI been ready to accept the servers. In short, in my judgment it is not the case that this demonstrates that David Cartwright was willing to put forward causes of delay which he either knew or should reasonably have known were completely irrelevant to the actual delay to the project.[126]Overall therefore, and taking these points into account, I do not consider that David Cartwright was an unreliable witness whose evidence I could not safely accept. I consider that I may safely rely on the majority of his evidence.

Niall Robinson

[127]Niall Robinson was Sigma’s finance director, who is still employed by Sigma in that role. It became clear during his evidence that he had no direct involvement in the project, and his evidence as to the terms of the main contract was in effect his second hand evidence gathered from what he had been told by Mr Maguire, who was too busy with other commitments to give evidence personally. In the event, therefore, I was unable to, nor did I need to, place any weight on his evidence.

Absent witnesses

[128]It is also worth observing that Sigma did not seek to produce any witness evidence either from CAMP East or Mason to support its case, even though it was clear that Sigma had (and continues to have) a very close and good relationship certainly with CAMP East and presumably with Mason. For example, no evidence was provided from Richard Sheehan, who was the manager responsible for the DMS system (i.e. the database management system developed and maintained by CAMP East for the legacy data – see §9.2 of the CAD Specification). It is clear that from Sigma / CAMP East’s side he was the man with the most detailed knowledge of the legacy data and the data integration issues. No explanation was tendered by Sigma for the failure to call him as a witness. That said, since there was no questioning of Sigma’s witnesses as to why he had not been called, I do not consider that I am in a position to draw any adverse inferences from the failure to call him as a witness. It does however mean that Sigma’s evidence on the detailed technical issues was inevitably not as persuasive as that of Anthony Smalldridge, who did have that detailed technical knowledge.

Clause 6.1 and concurrent causes of delay

[129]One further legal point must be considered before I can delve into the facts, which is this. On a number of occasions it became apparent that the parties were contending that even though one cause of delay was something for which they were – or might be – contractually responsible, nonetheless the dominant or overriding or critical cause of delay at that time was something for which the other party was contractually responsible. So, to take an example which I shall need to address in this judgment, it may be the case that it would not have been possible for FAT2 to have been conducted significantly earlier than it was because of:(a) CAMP East’s failure to provide a copy of GeoDirectory to load onto Compass; and(b) Blue8’s failure to load the mapping data supplied by CAMP East. Since it was accepted that Sigma would be liable for CAMP East’s failure to provide GeoDirectory in time, and since it was also accepted that Steria would be liable for Blue8’s failure to load the mapping data, and since it appears to have been common ground that it would not have been possible to have conducted FAT2 without both GeoDirectory being supplied and the mapping date being loaded, is Steria entitled (subject always to notice having been given) to an extension of time under clause 6.1 for this period in such circumstances?[130]The parties have not directed submissions to me specifically on this point. However this point is discussed in Keating on Construction Contracts (8th edition) par 8-021, where the learned editors suggest:
‘It now appears to be accepted that a contractor is entitled to an extension of time notwithstanding the matter relied upon by the contractor is not the dominant cause of delay, provided only that it has equal ‘causative potency’ with all other matters causing delay [the footnote refers to Henry Boot Construction v Malmaison Hotel Manchester [1999] 70 Con LR 32]. The rationale for such an approach is that where the parties have expressly provided in their contract for an extension of time caused by certain events, the parties must be taken to have contemplated that there could be more than one effective cause of delay (one of which would not qualify for an extension of time) but nevertheless by their express words agreed that in such circumstances the contractor is entitled to an extension of time for an effective cause of delay falling within the relevant contractual provision.’
[131]It appears from the relevant part [§13] of the judgment in Henry Boot Construction v Malmaison Hotel Manchester that Dyson J. (as he then was) was recording an agreement by counsel to the effect stated above, rather than deciding a point which was at issue between the parties. Nonetheless the fact that he, as a judge with such wide experience in the field, noted the agreement without adverse comment is a strong indication that he considered that it correctly stated the position. Furthermore, the rationale suggested by the editors of Keating appears to me, with respect, to be compelling, and to apply as much to this case as it does to the particular clause in the Henry Boot case and indeed to extension of time clauses generally. Accordingly, I propose to adopt that approach as correctly representing the proper approach to extensions of time under clause 6.1 of the sub-contract.[132]It follows in my judgment that my task is to:(a) identify whether, and if so to what extent, the delays in completing each of the tasks in Schedule 6 of the sub-contract were due, whether dominantly or equally with other causes, to one or more of the circumstances referred to in clause 6.1;(b) consider whether Steria gave written notice of the circumstances giving rise to the delay within a reasonable time – or if not whether Sigma waived compliance or is estopped from relying on non-compliance;(c) consider what extension of time is justified in all of the circumstances by reason of the occurrence of those circumstances;(d) as part of process (c), to consider whether Steria took reasonable steps to minimise or mitigate the consequences of the delay.

H.1. CAUSES OF DELAY TO FAT2

[133]FAT2 was due to be completed by 15 April 2002. There is a dispute as to when it was completed; Steria says by 28 June 2002, whereas Sigma now In the original version of the Defence and Counterclaim it was pleaded that FAT2 was completed on 4 July 2002. contends that this was conditional upon the rectification of 7 specific issues, which did not occur until 26 July 2002, and also upon completion of data loading and integration, which did not occur until 23 January 2003.[134]Steria contends that FAT2 was delayed due to:(i) Sigma’s delay in agreeing the FDS;(ii) Sigma’s delay in providing GeoDirectory and the mapping data;(iii) Sigma’s failure to provide, on time or at all, legacy data in the form required by the sub-contract, in particular the CAD Specification.[135]Sigma does not dispute that if delay was caused due to the factors identified by Steria then they were relevant circumstances within clause 6.1 of the sub-contract. Its case is that FAT2 was delayed not by these factors but:(i) over the period from January – June 2002, due to Blue8’s failure to load the mapping data;(ii) from 28 June 2002 to 26 July 2002, due to Steria’s delays in rectifying the 7 specific issues;(iii) from 28 June 2002 to 23 January 2003, due to Steria’s continuing failure to load the legacy data to an acceptable standard.[136]Steria also complained that there was a delay in commencement of the project. This is factually correct, in that initially the project was due to commence on 30 June 2001, but that due to difficulties within CAMP East the project did not in fact commence until the main contract was signed on 30 August 2001. However Steria was willing to enter into the sub-contract dated 11 September 2001 on the basis that the only revision to the contractual dates for completion was to the date for completion of FDS, which was deferred to 1 November 2001, so that in my judgment it is unable to complain about that delay.

Delay in agreeing the FDS

[137]Steria contends that:(i) it was agreed from the outset that the FDS would be produced for agreement in a series of separate sections, to enable development work on each section to commence once that section was agreed;(ii) it produced drafts in September and October 2001, but with no response from CAMP East;(iii) one particular problem was that the FDS needed to be approved by the Chief Fire Officers, who met infrequently and required a high degree of consensus;(iv) thus it was not until 25 March 2002 that Steria was verbally informed that the FDS had been approved, and not until 23 April 2002 that the FDS was formally signed off;(v) Steria provided written notification of this cause of delay;(vi) Paul Kearney accepted that this was a cause of delay which was not Steria’s fault, conceding 8 weeks’ delay in his witness statement;(vii) Steria was unable and unwilling to make any progress on customer development until verbal confirmation of approval was given.[138]Sigma however contends that:(i) Steria was late in providing the draft FDS, in stages or otherwise, and did not provide a full version until 15 January 2002, which was accepted in principle on 19 February 2002;(ii) the sub-contract works were not delayed as a result of any delay in agreeing the FDS, because Steria was able to and did undertake planned development work throughout the relevant period.[139]It is clear from the minutes of meeting of 13 June 2001 [D1/034] that Steria and Sigma agreed that the FDS should be provided and approved in stages. On 7 November 2001 Steria sent an e-mail to Sigma [D1/081] complaining about CAMP East’s lack of response to the draft FDS which had been submitted, and stating that development could not start until the FDS had been approved. Under cross-examination [3/97] David Cartwright stated that by this time all sections of the FDS had been submitted, save for those relating to ERAS and MIS; this is supported by the fact that in re-examination Paul Kearney stated that he believed that the FDS had already been provided in sections by 21 November 2001, when he referred to Steria having agreed to send out a complete version of the FDS. Sigma’s e-mail response [D1/82] did not contradict the assertion that CAMP East was causing delay, but suggested that development could start on those sections which were approved. CAMP East then stated that in fact it required the FDS submitted in one complete formal issue before it would consider a formal approval, and this was not accomplished until 15 January 2002 [D1/100]. On 18 January 2002 [D1/101] Steria sent an e-mail to Sigma recording the delay to its works due to the delay in approving the FDS, and on 29 January 2002 Steria sent a further e-mail to Sigma [D1/111], stating that it expected there to be a 7 week delay to the programme as a result of this problem. It was in this e-mail that Steria said that it was seeking a ‘change note’ to ‘formally slip the delivery timescales’. In its response [D1/114] Sigma accepted that there was ‘no culpability applying to Steria’ for this delay, and under cross-examination Paul Kearney agreed that this was his view at the time. It should also be noted that at the progress meeting on 22 January 2002 [D1/103] it was recorded under section 0505 that any development undertaken by Steria prior to formal approval of the FDS was at Steria’s risk. However, as is clear from the documents, it was not until 25 March 2002 that Steria was verbally informed that the FDS had been approved, and it was not until 23 April 2002 that the FDS was formally signed off[140]In my judgment, it is clear from these contemporaneous exchanges that:(i) there was a significant delay in completing the process of approval of the FDS;(ii) this delay was due to delays on the part of CAMP East, as opposed to any delay by Steria;(iii) Sigma accepted at the time that the delay was due to CAMP East rather than Steria. It is also clear in my judgment that this delay on the part of CAMP East was a circumstance entitling Steria to an extension of time under clause 6.1, and the contrary has not been suggested by Sigma. Finally, written notice of these delays in compliance with clause 6.1 was given in my judgment by the e-mails of 7 November 2001 and 18 and 29 January 2002.[141]I must therefore now turn to Sigma’s further case which is that the delay in agreeing FDS did not actually delay the works, because delay in formal approval did not prevent Steria from proceeding with development based on informal approval. David Cartwright’s assessment in his witness statement of the delay to the project due to the delay in starting the contract and the delay in approving the FDS was pf the order of 12-16 weeks. In cross-examination David Cartwright accepted that Steria was able to commence development work as from 25 March 2002; however Sigma contends that it was both able to, and did so, before that date. Under cross-examination David Cartwright maintained that no useful development work had been undertaken before that date because he had taken seriously the warning at the progress meeting that to do so would be at Steria’s risk. This was because, according to him, he had been caught out in that way on a previous project. However the documentary evidence, together with his evidence under cross-examination, does tend to indicate that at least some development work was being carried out prior to that date. In particular, David Cartwright accepted that development work proceeded on one discrete element of the project known as GD92, because that was work which was also connected with another project, and he also accepted that ‘standard’ development work, i.e. work which was not dependent on the approval of the FDS, also proceeded.[142]At the trial there was some considerable investigation of the time-sheets which had been disclosed by Steria following my pre-trial ruling, in order to see whether or not they supported Steria’s account or Sigma’s account. I found it difficult on the evidence to reach any clear conclusion as to how much useful development work was undertaken prior to 25 March 2002, other than that falling into the categories referred to by David Cartwright. In my judgment the likelihood, on the evidence, is that Steria did undertake development work in the early stages, when it assumed that there would be no particular problem with approval, but that from late January 2002 to late March 2002, when it had been placed on notice first that approval was subject to approval by the Chief Fire Officers, and second that any development work undertaken in the mean-time was at its risk, it either ceased or significantly scaled down the project specific development work. I also accept the contemporaneous assessment of delay in the letter of 29 January 2002 as the most reliable evidence, and conclude that the delay from November 2001 to March 2002 in approving the FDS was a cause of some 7 weeks’ delay overall in achieving FAT2.

Delay in providing GeoDirectory, mapping and legacy data

[143]It is common ground that the complete GeoDirectory data, the complete range of mapping data and a complete set of legacy data were not delivered to Steria until 23 or 24 May 2002. However, there is considerable dispute between the parties as to the consequences of this, and in particular whether it was the cause of any delay to FAT2.[144]I have already referred earlier in this judgment to the FDS in relation to the GeoDirectory and legacy data. I should also refer to section 1.5 of the FDS, in which Steria identified the relevant mapping data which was required. Reference was made first to the required mapping data, which was principally the 1:450,000 scale, the 1:50,000 scale and the 1:2,500 or 1:1,000 scales. (The larger scales are referred to as colour ‘raster’ maps – which have the appearance of computerised photocopies of the paper ordnance survey maps, and the smaller scales are referred to as ‘vector’ maps - which are created from point and line data and which look more like diagrams than paper maps.) Second, Steria suggested various other scales of map, but it was made clear that these were not mandatory.[145]It is clear from the CAD Specification that Steria was entitled to be supplied with the GeoDirectory and mapping data on a free-issue basis by CAMP East on behalf of Sigma, and also that all parties were fully aware that FAT2 could not take place until that data and the legacy data had been supplied to Steria. As already explained, the first step in the population of the Compass gazetteer was to load the GeoDirectory data into it, and the legacy data could not be loaded until that task had been achieved. Anthony Smalldridge confirmed under cross-examination [1/152] that there was no correlation between this process and the separate process of loading the mapping data into the system, so that the former was not dependent in any way on the latter having first been accomplished.[146]As early as the meeting of 13 June 2001 Steria was requesting that this data be supplied by the end of July 2001 [D1/34]. Paul Kearney accepted under cross-examination [2/39] that Steria would have wanted the data early so that any problems could be identified and resolved without delaying the timetable. At the 1st project meeting on 21 September 2001 it was noted [D1/78] that Steria was to provide a list of its address and mapping data requirements to CAMP East, to enable them to supply what was required. Steria’s evidence was that this list was provided at or shortly after the meeting; the document at D6/1732, which is headed ‘data requirements for CAMP East’ and which was produced by Anthony Smalldridge [4/16] sometime prior to 3 October 2001 tends to support this evidence. This, coupled with the absence of any contemporaneous or subsequent suggestion that Steria had delayed in providing its requirements, confirms Steria’s account. In any event, once Steria had submitted its draft FDS showing that it was proposing to load Compass with GeoDirectory and then to load the legacy data, it must have been apparent that CAMP East would need to acquire a copy of GeoDirectory (unless of course it chose not to agree Steria’s proposals); the only further question was what types and scales of maps were required.[147]At the 5th progress meeting on 22 January 2002 [D1/103] the question of the GeoDirectory and mapping data was raised, and it was recorded that:(i) Steria, having ‘used’ certain sample maps provided, now required the GeoDirectory and mapping data for the whole region;(ii) CAMP East were still awaiting sample GeoDirectory and 1:25,000 map data, and were not prepared to place any order until they had approved those samples;(iii) Steria was asked to confirm firstly whether delivery of the GeoDirectory and mapping data was on the critical path, and if so its required timescales. In its e-mail of 30 January 2002 [D1/115.3] Steria confirmed that: (i) delivery of the full GeoDirectory and full mapping data were critical to progress; (ii) assuming that the data was delivered by mid-April 2002 Blue8 would need ‘4 to 5 weeks of focussed effort’ from then to complete their preparation for FAT2. Under cross-examination Paul Kearney agreed [2/77-78] that this was both right and perfectly logical. In my judgment, this was also a notice of delay under clause 6.1 of the sub-contract.[148]In a separate e-mail of 30 January 2002 [D1/115.1] Steria advised Sigma that, having checked with Blue8 following the meeting of 22 January 2002, it transpired that the sample smaller scale maps had not been loaded by Blue8 who were now experiencing difficulties in doing so, and that Blue8 had been told that this was delaying the ordering of the mapping data. It is clear, therefore, that Steria was not seeking to conceal this problem with Blue8 from Sigma. There is also an internal report produced by David Cartwright at around this time [D1/139], referring to a potential delay of 3 months in obtaining this data. This, when read with the minutes of the meeting and the e-mails, makes it clear that what was happening at this stage was that CAMP East were refusing to place an order for the GeoDirectory and mapping data until they were satisfied that the samples already provided could be loaded.[149]At the next progress meeting on 19 February 2002 [D1/146] it was reported that:(i) Blue8 were still having difficulties in loading the sample maps;(ii) CAMP East had obtained approval to purchase the GeoDirectory data; (ii) CAMP East would only order the GeoDirectory data if Sigma, Steria and Blue8 accepted that they were responsible for integrating the GeoDirectory, mapping and legacy data;(iii) CAMP East would only order the smaller scale vector maps once Blue8 had been able to load the samples. Again, therefore, it is clear that all parties were aware of the difficulties with Blue8. By a letter of 20 February 2002 CAMP East provided more details as to the assurance it required from Steria; its principal concern was that in buying and using GeoDirectory CAMP East would be committing to what was a ‘relatively new product [which] has not been tested or evaluated by CAMP East’.[150]It is clear that by this stage all parties were becoming increasingly concerned as to the impact of these data issues on the project, and on 2 March 2002 Steria e-mailed to Sigma [D1/166] a draft letter dated 1 March 2002 [D1/165.1], which was intended to be passed on to CAMP East / Mason. Paul Kearney’s response [D1/166] was that ‘at first sight it seems to set the right tone’. The letter itself:(i) stated that it was CAMP East who had decided, during the FDS stage, to use both GeoDirectory and the legacy data, and that Steria had agreed to do so at no extra cost to CAMP East;(ii) stated that Steria was not prepared to underwrite the quality or effectiveness of the GeoDirectory data;(iii) suggested one option of conducting a separate data load of the legacy data alone to have available as a longstop;(iv) expressed Steria’s concerns in relation to the delayed supply of the GeoDirectory data and the legacy data.[151]In relation to the legacy data, it appears that at some stage in late 2001 some sample legacy data had been provided. There is no hard evidence that any sample legacy data was provided pre-tender, or that any significant quantity of legacy data was provided until early 2002; I do not treat the correspondence at D6/1590, which significantly post-dates this time, as at all conclusive on this point. Thus in his e-mails of 18 February 2002 [D1/143] and 26 February 2002 [D1/162.1] David Cartwright makes reference to having received and reviewed samples of legacy data, and in the second e-mail he states that both the sample GeoDirectory and legacy data was ‘fine’. However, in his letter of 1 March 2002 he stated that Anthony Smalldridge had received and reviewed a CD-ROM entitled ‘complete CAMP East database’, and found that it was incomplete. The implication from the 1 March 2002 letter coupled with the absence of any earlier recorded reference to delivery of more than sample legacy data, in my judgment, is that the CD-ROM had only relatively recently been received. David Cartwright stated in his letter that without a ‘full data set’ Steria was unable to start a ‘meaningful load process’.[152]It appears that this letter was duly sent; under cross-examination Paul Kearney stated [2/91] that he remembered delivering it by hand. The only point which he disagreed with under cross-examination was in relation to whether the whole of the data was needed for FAT2, or only the data for Dublin and Longford, which is a point to which I shall return. There is no suggestion that CAMP East or Mason responded disagreeing with the letter. In my judgment it is clear that this letter:(a) accurately recorded that it had been CAMP East’s decision to adopt the hybrid option;(b) amounted to a delay notice under clause 6.1 in relation to the delivery of the data required to be delivered before FAT2 could proceed.[153]In March 2002 there were exchanges between Steria and Blue8 in relation to the problems that the latter were experiencing in loading the sample maps which, in summary, revolved around the fact that the Irish OS digital maps contained 3 co-ordinates (northings, eastings and altitude), whereas Blue8 was more used to dealing with English OS digital maps which only contained the first and second co-ordinates. Although at first blush surprising, it appears that the effect of this difference was that Blue8’s software was unable to load the sample maps without undergoing significant modification. On 8 March 2002 [D1/172.1] Blue8 confirmed to Steria that it would develop its software to accommodate this difficulty, and that CAMP East should therefore proceed to order the mapping data from OSI, and on 13 March 2002 [D1/177] Blue8 confirmed its timescale for delivery of the revised software as being 6 May 2002, which it noted would ‘tie in nicely’ with the delivery of the maps to CAMP East.[154]What appears to have happened is that by this stage CAMP East had agreed to order the mapping data from OSI, and had been quoted a delivery date in early May, but were extremely upset by the price quoted by OSI, and were seeking legal advice as to how they could reduce the price. These developments are reflected in the minutes of the 7th progress meeting on 26 March 2002 [D1/191]. On 27 March 2002 [D1/217] Steria sent an e-mail to CAMP East, copied to Mason and Sigma, asking for dates for delivery of the GeoDirectory and also the complete legacy data. Read in context, in my judgment this also amounted to a delay notice under clause 6.1. On 28 March 2002 [D1/218] Sigma replied, advising Steria first that Richard Sheehan would ‘begin to collect the outstanding legacy data immediately after Easter’, and second that they should continue to plan on the basis that the GeoDirectory and mapping data would be available by 6 May 2002. In his reply later that day [D1/218], David Cartwright advised Paul Kearney that according to Anthony Smalldridge there was ‘approx 5 weeks of effort once we get the GeoDirectory and legacy data for Blue8 and ourselves’.[155]On 9 April 2002 Steria sent an e-mail to Sigma [D1/230], suggesting various options to deal with the problem created by the delay in the provision of the mapping data due to the difficulties caused by OSI. It is pertinent to note that in that e-mail David Cartwright observed that whilst the GeoDirectory and legacy data were essential to run STORM, and needed to be procured without further delay, the same was not necessarily true of the mapping data. By this time the decision had already been taken that FAT2 could not conceivably take place by the planned date of 15 April 2002, and it was re-scheduled for a date in June 2002, apparently 6 June 2002. On 12 April 2002 Sigma wrote [D1/232] to CAMP East and Mason, with a copy for Steria, asking when the GeoDirectory, mapping and legacy data could be expected, with a view to maintaining the revised date for FAT2 in June 2002. It is clear that by this stage Paul Kearney was floating the idea of mitigating delays by conducting FAT2 using only a proportion of the mapping data, GeoDirectory and legacy data. Under cross-examination Paul Kearney accepted that the rescheduling of FAT2 was on the understanding that Steria was not responsible for the delay up to that point [2/111]. This is notwithstanding that, as I have already found, Paul Kearney had already been made aware of the difficulty which had been experienced by Blue8 in loading the sample maps and, moreover, that at no stage subsequently had he been advised that Blue8 had resolved the problem. It follows, in my judgment, that at the time Paul Kearney did not consider that the overriding cause of the delay to FAT2 was the problems being experienced by Blue8.[156]At the 8th project meeting of 26 April 2002 [D1/246] it was recorded that the purchase of GeoDirectory had finally been authorised, but that discussions as to what mapping data would be obtained were still ongoing because of the ongoing problems with OSI. At this stage, it appears that the planned date for FAT2 to commence was still 6 June 2003 [D1/256].[157]On 2 May 2002 David Cartwright contacted Blue8 to confirm that they were still on course to provide the revised software for the mapping data by 6 May 2002. His note of 8 May 2002 [D1/277.1] records that he was told that there had been ‘slippage’, and that the revised estimated date was now not until 25 June 2002. This was of course after the planned date for FAT2. Although David Cartwright noted that this could put FAT2 in jeopardy, he also noted that FAT2 was subject to possible further slippage anyway. On the same day Blue8 sent an e-mail [D1/277.3], confirming that their revised date for delivery of the software was 26 June 2002.[158]On 16 May 2002 [D1/278] David Cartwright sent an e-mail to Paul Kearney, following on from previous discussions between them. In the e-mail David Cartwright, having referred to the estimated date of delivery of the mapping data of 17 May 2002, stated that ‘from a scheduling point of view Blue8 will not be in a position to start loading the maps until they have finished loading up the gazetteer and the legacy data’. Since there is no suggestion from the note and the e-mails to which I have referred that Blue8 were unable to start loading mapping data until the gazetteer and legacy data had been loaded, the likelihood is that David Cartwright was using this as an excuse to avoid having to disclose the fact that Blue8 were in delay. However, it is also undoubtedly the case that it had always been made clear (see for example the e-mails of 30 January 2002 and of 28 March 2002 to which I have already referred) that Blue8 would require 4-5 weeks from receipt of the GeoDirectory and legacy data to load Compass. He then suggested that if there was insufficient time before FAT2 to load all of the mapping data, including the small scale vector maps which were causing the difficulties, just a couple of sample vector maps could be loaded for FAT2, with a view to demonstrating the loading of the remainder at the July progress meeting. Under cross-examination [3/147] David Cartwright confirmed that this option was always subject to CAMP East’s consent. In the event however there was no need to do so, because as will be seen Blue8 was able to provide the required revised software in time for the revised FAT2 date.[159]At the 9th progress meeting of 20 May 2002 [D1/280], it was recorded without comment or explanation [item 0904] that FAT2 for Steria’s element of the works was now scheduled to take place over the week commencing 24 June 2002. There is no suggestion in the documentary evidence, nor was it suggested by Sigma in cross-examination of Anthony Smalldridge or David Cartwright, that this postponement of FAT2 was deliberately instigated by Steria with a view to concealing the true extent of the problems with Blue8. In fact, as I find, since the GeoDirectory, legacy and mapping data had still not yet been supplied in full by this stage, it must have been obvious to all concerned at that stage that a commencement date of 5 June 2002 was completely unrealistic, given the 4–5 weeks of work that was required from receipt of the GeoDirectory and legacy data.[160]In the event, CAMP East was able to deliver the GeoDirectory data, the mapping data for Dublin and Longford, and a complete version of the legacy data (save for the county of Louth) by 23 or 24 May 2002. This can be gleaned from the e-mails at D1/285.3 – 285.4 and from the Blue8 report at D1/288.5. By this stage the decision had been taken only to load the mapping data for Dublin and Longford for the purposes of FAT2. Although there is no clear evidence as to the circumstances in which this decision was taken, CAMP East must have been involved in that decision, which was for their benefit as much if not more than for the benefit of anyone else, because it was they who were responsible for the delivery of the mapping data required for the project to proceed.[161]By 31 May 2002 Blue8 had produced [D1/288.1] the first version of the document which described the requirements for data take-on for the gazetteer, i.e. the loading of the gazetteer with the GeoDirectory and the legacy data. It is apparent from D1/288.17 that by this stage the proposal was to load the data for Dublin and Longford for FAT2, and to load the remainder by 15 July 2002. It is not clear precisely when, by whom and in what circumstances that proposal was made and accepted, but I agree with Steria that it appears to have been a relatively late decision; thus there is no reference to the outstanding legacy data being limited to these counties in the e-mail from Paul Kearney of 28 March 2002 or indeed in any other relevant correspondence prior to the Blue8 data take-on requirements document.[162]Blue8 proceeded to load the GeoDirectory, the legacy and the mapping data. It is apparent from Blue8’s e-mail of 21 June 2002 [D1/318] that by 20 June 2002:(i) it was engaged in the process of loading of STORM, having already loaded Compass;(ii) it was already aware that there was a problem with a low match rate between the GeoDirectory and the legacy data, so that it suspended proceeding with the full data load until after a planned meeting with CAMP East for 27 June 2002;(iii) it had been able to load the necessary mapping data, save where missing data had not been acquired by CAMP East. So far as that last point is concerned, David Cartwright confirmed under cross-examination that Blue8 had successfully loaded the mapping data by the time for FAT2, and there is no evidence or suggestion to the contrary.[163]It follows, in my judgment, that on any view there was a significant delay on the part of CAMP East in providing the necessary GeoDirectory, mapping data and legacy data. Although it is difficult to identify a specific date or dates when such data ought to have been provided by the latest, it is apparent that as from 30 January 2002 if not before Sigma and CAMP East knew that this data was critical to the progress of FAT2, and indeed the whole project, and that it was therefore important that it should be supplied as soon as possible. It is also apparent that for various internal reasons, including the need for approvals and difficulties with pricing and budgets, there was a substantial delay in procuring the data. There is no excuse at all in relation to the delay in procuring the GeoDirectory. The only possible excuse in relation to the mapping data seems to have been the stance by CAMP East that it was not prepared to place an order until Blue8 had resolved the problems in loading the samples, but in my judgment:(i) that was not a sufficient justification, because the mapping data was required in any event, and(ii) by mid March 2002 it is clear that Blue8 had committed to developing the software to load the problematic vector mapping data, therefore there was no justification for delay after that.[164]I am also satisfied that delay notices within clause 6.1 were sent in relation to this cause of delay on 30 January 2002, 1 March 2002 and 27 March 2002.

Completion of FAT2

[165]It follows from my findings above that the GeoDirectory, legacy and mapping data was loaded in readiness for, and for the purposes of, FAT2 commencing on the revised agreed date of the week commencing 24 June 2002. Considering that the data was delivered on 24 May 2002, 5 working weeks had elapsed between delivery of the data and commencement of FAT2, which was in accordance with the timetable provided by Steria in January 2002 and again in March 2002. Sigma contends that in fact the lesser work involved in loading GeoDirectory for Dublin and Longford alone took less than 3 weeks, and seeks to argue from this that the 4-5 weeks forecast by Steria was unnecessarily protracted. In my judgment however that is nothing to the point. Steria was entitled to a reasonable period from delivery of the requisite data, and before delivery they estimated that a reasonable period would be 4-5 weeks. In my judgment it would be unreasonable in the extreme to require them to have accelerated their timescale so as to complete that process in only 3 weeks. In any event, by that time there was no overriding need to do so, since by the time the data had been delivered FAT2 had already been put back to 24 June 2002 anyway.[166]As arranged, FAT2 took place at Steria’s premises at Hemel Hempstead. A progress meeting took place during the course of FAT2 on 26 June 2002 [D1/320], and at item 1004 it was recorded that ‘in general [CAMP East] is happy with the progress of the FAT and the functionality of the system. However [CAMP East] has expressed serious concerns about the data which are dealt with in paragraph 1006 below’. Paragraph 1006 went on to state that data integration issues were to be discussed the following day, but recorded Paul Kearney as saying that not only was data integration critical to the project, but also that no further payment for FAT2 would be made until the data for Dublin and Longford had been fully integrated and delivered, and no further delivery milestone would be paid until all data had been successfully integrated and delivered.[167]Other than in relation to the issue of data integration, the only other concerns in relation to FAT2 were 7 specific matters referred to in a fault summary index [D1/319.1]. It appears that these were all attended to by 26 July 2002. It is also apparent that on Friday 28 June 2002 Steria produced, and Keith Leonard and Stephen Roe of Mason signed, what was described as an ‘Acceptance Certificate’. This purported to certify CAMP East’s acceptance that the FAT2 milestone had been reached in accordance with the sub-contract. Attached to it, however, was a document headed ‘Conditions of Acceptance’, which recorded as the sole condition the resolution and demonstration of the items recorded in the fault summary index ‘prior to the start of SAT’.[168]There has been some debate about the status of this certificate. There is clearly no explicit reference to any certification procedure under the sub-contract. Moreover, Sigma refers me to clause 39.8 of MF/1, which provides that ‘no certificate of payment … shall be relied upon as conclusive evidence of any matter stated therein’. However, Steria retorts that this only relates to payment certificates, and I note that under clause 29 of MF/1 there is provision for the issue of taking over certificates by the engineer in relation to the completion of the whole or any section of the works, which do appear to have a deemed conclusive effect [clause 29.2]. Notwithstanding this, since Steria has already submitted and I have already found that:(a) Mason, although Engineer under the main contract, had no specific powers or functions under the sub-contract, and in particular had no certifying power under the sub-contract;(b) there was no provision for sectional completion under the main contract, it is difficult to see how this certificate could have any contractual conclusive effect as between Sigma and Steria.[169]That said, factually it is clearly a very significant piece of evidence. When read with the minutes of the progress meeting, it shows in my judgment first that with the exception of the 7 fault items CAMP East was happy with the functionality element of FAT2, second that CAMP East was willing to regard FAT2 as having been achieved on condition that these 7 items were addressed prior to SAT, and third that CAMP East was willing to ‘hive off’ the data integration issues from FAT2, albeit that it was also seeking to defer payment in full of the FAT milestone until the data integration in relation to Dublin and Longford had been fully achieved. In those circumstances I conclude that the parties had agreed between themselves that FAT2 was to be treated as having been achieved on 28 June 2002 subject only to the condition of resolution of the 7 outstanding items. I do not consider that Sigma can now contend that FAT2 was not achieved until:(a) the 7 outstanding items had been achieved;(b) the legacy data in relation to Dublin and Longford had been fully integrated. It cannot in my judgment be right that, having participated in a process under which Steria had been given until SAT to resolve these 7 outstanding items, and under which data integration could be hived off from FAT2, Sigma can now contend that in fact Steria should have proceeded on the basis that successful completion of these items was essential before FAT2 could be achieved. If Steria had been notified that resolution of the 7 items was necessary before FAT2 could be regarded as completed, it could and would have been able to resolve those items well before 26 July 2002, and probably within a period of 1 week from 28 June 2002.

Legacy data integration

[170]In relation to the data integration issue, I must now consider the events post-dating 28 June 2002, in order to address Sigma’s contention that despite the issue of the certificate in fact FAT2 cannot be regarded as having been properly completed by 28 June 2002, because of the outstanding legacy data integration issue which it says was the contractual responsibility of Steria. In any event, I also have to decide this issue in the context of the delays to the project post 28 June 2002.[171]Firstly, I must refer to the meeting of 27 June 2002 which had been fixed to discuss the problem of data integration. It is apparent from the note which was prepared by Steria [D1/330] which covers both the meeting held on that date and a further discussion on the following Friday, that:(i) there was a general acceptance that the existing low match rate was unacceptable;(ii) it was understood that a match rate of 100% was impossible to achieve, so that some manual intervention would be required, but that there was an aim to achieve a ‘significant improvement’;(iii) there was a discussion as to the options for improving the match rate;(iv) the initial approach was to use something known as ‘polygon data’ This process was explained in evidence by Anthony Smalldridge at 1/65. , but the subsequent approach, canvassed on the Friday meeting, was to use an approach known as ‘proximity matching’, under which the grid reference rather than the qualifier was to be used as the match;(v) Richard Sheehan was to provide rules to derive the map square from the easting and northing information. This approach was, according to Anthony Smalldridge’s evidence [1/66], preferred by CAMP East, and was evidently agreed by the parties [D1/333]. As a result on 5 July 2002 Blue8 produced a further version of the data take-on requirement [D1/339.3], which reflected these agreed changes.[172]In my judgment this is a clear indication that all parties accepted that the data loading rules which had been agreed in, or contemporaneous with, the FDS, and which had themselves been produced on the basis of the information provided by CAMP East in the CAD specification §9 as to the structure and content of the legacy data, needed to be revised because the legacy data actually supplied did not accord with the description contained in the CAD specification and, therefore, that a new basis of matching needed to be agreed in order to achieve a level of matching which was suitable for CAMP East’s purposes. The type of problem which was being experienced in integrating the legacy data was described by Anthony Smalldridge in his evidence [1/47] as follows: A. We had no idea how complete the legacy data would be. If you found one -- you might find one name for a townland, whether it is aliased or not, bearing in mind that the Geo directory did contain aliases that we were able to load, but when you find that townland name and that posttown, then you refer to the legacy data and you say can we find this townland with this qualifier, which is the same as the posttown. Then that is when we found that we had no match. Q. Yes. A. Then when we dropped the qualifier, because we had no match, we found that we had duplicates, and then you do not know which one you are going to take. Q. Those are typical of the problems that you get? A. It was typical of the problems that we found.[173]It is apparent from the exchange of communications between Steria and Mr Sheehan of CAMP East at D2/340 and D2/349 that very quickly Steria discovered that some of the data sets comprised within the legacy data supplied to Steria did not contain map references or, in some cases, either map references or map squares. It appears that proximity matching could proceed using map squares alone, but as a ‘coarser match’, whereas if there were no map references or map squares the proximity matching process was simply not possible. Richard Sheehan sought to address this problem by producing a further version of the legacy data, but accepted that even so a complete match was impossible using proximity matching.[174]It is also apparent from the Steria report of 16 July 2002 at D2/353.1 that Steria made enhancements to the further version of the legacy data provided by CAMP East and thereby demonstrated that it was possible, using the proximity matching process, to achieve a matching rate of 79%. On 18 July 2002 Paul Kearney reported to David Cartwright [D2/356] the result of his meeting with CAMP East the previous day; CAMP East were demanding that Steria achieve an ‘approx 80% match on townland data and a higher match rate on Dublin street data’. The inference, in my judgment, is that this figure was adopted as a target figure from the Steria report of 16 July 2002.[175]On 24 July 2002 Richard Sheehan wrote to David Cartwright [D2/362], and re-iterated CAMP East’s requirement that Steria should achieve a match rate of 80%, on the basis that CAMP East would need to consider how it could manually load the remaining 20%, which was a pre-condition to the system going live. It is clear that CAMP East’s position was that it would not permit SAT to proceed unless and until Steria had demonstrated to CAMP East by random sampling that it had achieved 80% matching and CAMP East had manually loaded the remainder – see also the notes of the progress meeting on 27 August 2002 at D2/409, item 1106.5.[176]In my judgment, there was no contractual basis for CAMP East to stipulate a matching rate of 80% or more in the case of Dublin, when the possibility of achieving that rate, using a process which was not that agreed in or contemporaneous with the FDS, was substantially if not entirely dependent on the quality of the legacy data which they had provided. In contrast, when considering the question whether or not Steria had complied with their contractual duty to exercise reasonable care and skill in loading and/or integrating the legacy data, it is noteworthy that at this time Paul Kearney was recording in an e-mail on 26 July 2002 to David Cartwright [D2/367] his belief that Steria had ‘done more than make a reasonable effort [to load Compass], particularly given the flaws in the legacy databases’. Paul Kearney stood by this in evidence [5/35]. In my judgment that is an accurate reflection of the position as it then was, and sits in stark contrast with Sigma’s current criticisms of Steria’s conduct.[177]In its written closing [§30.6] Sigma submitted that Steria did not challenge CAMP East’s stance through activation of the arbitration procedure. However in my judgment the sub-contract did not make provision for arbitration, other than in the limited circumstances set out in clause 19.1, and moreover – as I have already held – Mason’s role as ‘Engineer’ did not extend to the sub-contract, so that this is not one of those cases where the contract required or enabled Steria to challenge Richard Sheehan’s stipulation by reference to arbitration whilst the works continued. It is clear that all parties proceeded on the basis that, whatever the justification for CAMP East’s stance, the only way to resolve the practical problem was to work towards achieving the 80% match rate on automated loading of the legacy data, so that the project could proceed towards a satisfactory completion.[178]In his lengthy response [D1/325] to Paul Kearney’s e-mail of 26 July 2002, David Cartwright began by setting out Steria’s version of events so far as the problems with loading the legacy data was concerned, and proceeded to make it clear that in Steria’s view CAMP East’s stance was unwarranted, and that Steria was not responsible for the problems with the legacy data. The concluding reference to a change note in my judgment was a reference not just to the potential financial implications but also to the potential delay implications of these problems, which was consistent with the approach taken in January 2002 in relation to the delay to the FDS. Whilst I agree that Steria was not, in this letter, seeking to resile from its earlier agreement that it would load the data from GeoDirectory and from the legacy databases at no additional cost to CAMP East, nonetheless it is quite clear from the letter that David Cartwright was contending that this was in fact work which was not Steria’s contractual responsibility. Furthermore, in my judgment, this letter amounted to a delay notice under clause 6.1 of the sub-contract, in that Steria was clearly setting out its position that CAMP East’s insistence on Steria achieving an 80% matching rate, and CAMP East completing the manual process, before further progress could be made, was causing delay, and was a matter for which Sigma was responsible under the sub-contract.[179]At this stage, the envisaged timetable was for Blue8 to complete loading Compass (by 5 August 2002), for Steria then to load STORM from Compass, and for CAMP East to inspect the results at Steria’s offices at Hemel Hempstead. However it is apparent from the documents that the process became protracted. Paul Kearney’s contemporaneous assessment, at D2/379, was that ‘CAMP East are happy enough with database progress and are beginning to realise their own lack of preparation’. It is clear that Steria was asked to, and did, produce revised loading rules to assist in meeting the target set by CAMP East of achieving an 80% match rate; see e.g. D2/385 and the analysis of the issues at D2/387.[180]On 11 September 2002 Steria e-mailed Sigma [D2/463-464] identifying the data integration issue as causing delay, which I am satisfied was a notice of delay under clause 6.1. On the same day Paul Kearney e-mailed all parties [D2/474.5] to confirm that by 18 September 2002 the automated legacy loading process should have been completed by Steria ‘according to rules defined and agreed between CAMP East and Steria’. Under cross-examination [5/41-42] Paul Kearney accepted that he was concerned that he did not want any further delay to be caused by further changes to the load rules by CAMP East - or what he described as ‘specification creep’.[181]Again, in my judgment, this is an accurate reflection of the position as it was at that time, namely that delays were being caused because CAMP East was keen to maximise the automated legacy loading process by Steria so as to minimise the manual legacy loading process which it would need to undertake, and was therefore actively engaged through Richard Sheehan in seeking to promote revisions to the loading rules which would achieve that objective.[182]It appears that on 18 and 19 September 2002 Richard Sheehan and Shaun McGinley, who by then was in the process of taking over from Paul Kearney as Sigma project manager, visited Steria’s Hemel Hempstead offices to view progress. Richard Sheehan produced a note [D2/478], which recorded the results of the further load. It is clear from the note that there was a discussion about undertaking a new load process with a new set of load rules, in order to minimise the ‘manual intervention’ required by CAMP East. It is clear that CAMP East wanted re-assurances from Sigma before agreeing to this as a variation to the contract: see Mason’s letter at D2/490.1. Although there is no documentary evidence as to what was said in response, it is clear that subsequently this was agreed by CAMP East and Sigma as a formal change control notice. (The approval was recorded in item 1607 of the minutes of the progress meeting of 12 December 2002 at D2/648, and the notice dated 23 September 2005 produced by Steria is at D2/485.) Although in its closing submissions [§30.6] Sigma contends that this change notice related only to STORM, that is inconsistent with the note at D2/478-9, and is also inconsistent with Shaun McGinley’s admission under cross-examination [2/152] that one reason why CAMP East was willing to agree this change notice was to reduce the manual loading which was required of them, and therefore I reject that argument. In my judgment, this change control notice is another indication that at the time none of the parties believed that all of these revisions to the data loading process were Steria’s contractual responsibility.[183]It is apparent that the revised data loading process also became protracted. At the progress meeting of 23 October 2002 it was recorded [item 1402, D2/524] that ‘there is still an amount of fine tuning to be completed if the hit rate is to improve’. It is apparent from this, and from Richard Sheehan’s report of that date [D2/527.1], that there were no major concerns with the data loading process at this stage.[184]There were further reports and communications through November 2002, which demonstrated that the process was ongoing, but no indication that either Sigma or CAMP East were contending that Steria was unreasonably delaying the process. Indeed on 22 November 2002 David Cartwright sent an e-mail to Shaun McGinley [D2/589] stating that he was standing Steria’s team down, on the basis that Steria was now waiting for CAMP East to say when they were ready for SAT. Furthermore, on 25 November 2002 David Cartwright sent a very lengthy letter to Sigma [D2/590, D6/1588] explaining the 5 months of delays which had occurred due to the delayed delivery of data and due to CAMP East’s insistence on achieving 80% matching. This was in my judgment a further valid notice of delay under clause 6.1 of the sub-contract. There was no contemporaneous challenge to this from Sigma on the basis that in fact Steria’s failure to load data in accordance with the contract requirements was causing delay.[185]Accordingly, I reject any suggestion, insofar as made in §91 Sigma’s closing, that the continuing problems in completing the automated data loading to CAMP East’s satisfaction over this period were due to any default or want of diligence on the part of Steria.[186]Sigma contends [§91-92 closing] that the automated data loading process was not completed until 23 January 2003. This is based on the report from John Armstrong of Steria [D2/658.2, 659], which records that:(i) Compass had been loaded ‘as far as the automated processes will allow’;(ii) Compass had been installed onto 5 PCs at Tara Street;(iii) the next step was for CAMP East to start manual loading. However, Steria contends that it is apparent from Sigma’s own progress report of 9 December 2002 [D2/627] that the remaining problems with the automated data load (detailed at D2/626) were not such as to prevent CAMP East from starting the manual update, and under cross-examination Shaun McGinley did not contradict this [2/190]. It appears from a project meeting held on 10 December 2002 and involving CAMP East, Mason and Sigma [D2/633.2] that it was agreed that the manual loading process could start, subject only to the agreement of a process procedure, so that in my judgment Steria is correct in its submission that as at 10 December 2002 it was common ground that the automated load process was effectively complete, and the next step was the manual load.[187]As I have already indicated, I am also satisfied that notice within clause 6.1 of the sub-contract was given of CAMP East’s insistence of achieving an 80% automated loading process as a cause of delay by the communications of 26 July 2002 [D1/325], 11 September 2002 [D1/483-484] and 25 November 2002 [D2/590, D6/1588].

Sigma’s criticisms of Steria’s data loading and integration

[188]Sigma criticises Steria’s performance of the data loading and integration process on a number of grounds.[189]First, it is said that there was nothing in the CAD Specification from which Steria could have properly made any assumptions about the quality and consistency of the legacy data. I have already considered this point in section D. of this judgment, and concluded that Steria was entitled to expect the legacy data to be substantially of the standard identified in §9 of the CAD Specification. Whilst Sigma has adopted Paul Kearney’s repeated criticism of Steria that in his opinion it failed to undertake a sufficiently thorough ‘due diligence’ exercise in relation to the legacy data, in my judgment Steria was entitled to rely on what was said in §9 of the CAD Specification without the need for conducting its own investigation. Further, under the terms of the contract not only did Sigma not actively attempt to exclude liability for the accuracy of what was stated in §9, but it also gave a contractual warranty in relation thereto. As Anthony Smalldridge said under cross-examination [1/74], the real problem was that of the data content, and specifically the fact that the legacy data did not contain the data which it was stated in §9.7 of the CAD Specification that it should contain. Although Anthony Smalldridge was cross-examined to the effect that he did not rely on anything contained in the CAD Specification so much as his examination of the sample data which was provided to Steria, in my judgment the true picture from his evidence See the lengthy exchange at 1/166-170. was that he relied on what was stated in §9 of the CAD Specification, which was confirmed by his examination of the sample data with which he was provided.[190]Sigma also contends that by the time the FDS was produced and approved it was, or should have been, apparent to Steria, having seen the sample data for Dublin and Longford supplied, that it was not of the standard identified in §9 of the CAD Specification. However, what Anthony Smalldridge said about this was as follows: ‘When you look at the data in isolation, in samples, the data looks fine. When you match it across 1 million records, which is the sort of size that we are looking at for the CAMP East region, then you find that you had a poor hit rate.’ [1/51][191]He repeatedly stated that the initial load rules, i.e. the process of using the townland and qualifier fields for the matching process, were devised from his examination of the sample data provided [1/60-61], and he also said that his conclusion from the samples was that the qualifier and townland fields were properly and consistently present [1/168]. This was consistent in my judgment with what was stated in §9 of the CAD Specification. He explained that all that Steria could do was to rely on the representative data provided [1/62].[192]I accept the evidence of Anthony Smalldridge as a man with expertise in this specialist field in these regards, and I do not accept that it could be said that it was, or should have been, apparent to Steria by the time they came to produce the FDS that the samples were not in accordance with the description in §9 of the CAD Specification, as subsequently emerged to be the case.[193]Sigma also contends [§31.1 closing] that in any event any deficiencies in the FDS are still the contractual responsibility of Steria, because they – as experts - produced the FDS, and Steria cannot rely on Sigma’s approval to avoid responsibility for those deficiencies. However in my judgment this is incorrect. There is no evidence that there was some fault in the FDS, or that a proper and competent contractor could and should have produced some further or different loading rules at FDS stage which, if followed, would have achieved a satisfactory match rate. The problem in my judgment was with the quality of the legacy data, not the quality of the FDS.[194]Sigma also contends [§31.1 closing] that in fact the problem was not the loading rules in the FDS, but the loading routines provided by Blue8 in its data take-on requirements. However again in my judgment this is incorrect. The approach to data loading and integration was set out in, and agreed by and contemporaneous with, the FDS. There is no evidence before me which indicates that there was some deviation from the FDS by Blue8 in its data take-on requirements which caused the problem. Again the problem, in my judgment, was the quality of the legacy data.[195]Sigma also contends in its closing submissions [§18, 59 et seq] that Steria could and should have examined the data before carrying out the loading process, that it failed to do so because it was over-confident, that had it done so it would have identified and resolved the difficulties in advance and, if it had done so it could have achieved a 79% match within 3 weeks of receipt of the data.[196]I am unable to accept this submission for the following reasons:(i) Although Anthony Smalldridge did say in evidence that it was possible to examine data in a database by using an access data reader, he was not asked whether this was something which Steria should have done on receipt of the legacy data, whether under any specific provision of the sub-contract or by way of good practice. Indeed, under cross-examination [1/64] he stated that ‘it was impossible to run a manual process that says we will find this sub-area in this qualifier, this posttown, within the data set, because you do not have the whole of the gazetteer to work with, and you leave that to a programme to run’. Later, at 1/102-103, he stated that it would not have been possible to identify the problems which were in fact experienced before undertaking the actual data load. He was quite clear under cross-examination that this was not the type of process where it would have been practicable to run a preliminary test in advance of the actual data load [1/106-107]. This was a consistent theme of his cross-examination, and it received a consistent answer, and I accept his evidence on this point.(ii) As I have already found, in my judgment Sigma are to be treated as having provided a warranty to Steria as to the structure and content of the legacy data. In those circumstances, there is no proper basis for Sigma to contend that despite that warranty Steria was nonetheless obliged to conduct its own examination into the legacy data prior to the loading process beginning.(iii) The contention that a 79% match could have been obtained within 3 weeks if Steria had received all of the legacy data in May 2002 does not, in my judgment, follow from what actually happened in July 2002. The true position as at 16 July 2002 was as I have already found that Steria, having had the benefit of the results of the first automated loading process which had already been done by that time, and having received a further version of the legacy data from CAMP East post FAT2 and then enhanced it, was able to demonstrate by reference to a sample that it was possible to achieve a 79% match rate. In fact, as subsequently transpired, due to the continuing difficulties with the structure and content of the legacy data it took many months of further effort before that match rate was achieved in relation to the whole of the legacy data.(iv) Under cross-examination Anthony Smalldridge explained that this was not a case where there was only one problem which, once resolved, dealt with everything. Instead, adopting a solution to dealing with one problem produced a series of other problems, and so on, such that the process of improving the volume of legacy data which could be integrated into the GeoDirectory data became what he described as ‘iterative’ [1/52].[197]Accordingly, even if it is open to Sigma now to contend that in fact FAT2 was not completed as at 28 June 2002 due to the failure to integrate all legacy data pertaining to Dublin and Longford into Compass and thence STORM, I am satisfied:(i) Firstly, for the reasons I have already given in section D. of this judgment, that Steria’s obligations in relation to legacy data loading and integration were not strict and unqualified as contended for by Sigma.(ii) Second, that there is no basis for any suggestion that as at 28 June 2002 Steria had not complied with its obligations in relation to data loading and integration as I have summarised them in paragraph 60 of this judgment.(iii) Third, that it was the case that the problem of low matching described by Blue8 in its e-mail of 21 June 2002 was due to the quality of the data content in the legacy data supplied, as opposed to any deficiencies in Steria or Blue8’s approach to data loading and integration, which caused the difficulties.[198]I therefore conclude that FAT2 was achieved, and was treated by the parties as having been achieved, on 28 June 2002, subject only to the condition, which was performed, that the 7 fault items were resolved by the start of SAT.

To what extension of time is Steria entitled in relation to FAT2

[199]It follows from the findings which I have already made that Steria is entitled to an extension of time to the date of actual completion of FAT2, namely to 28 June 2002, because the causes of the delay from 15 April 2002 to 28 June 2002 were firstly the delay in approving the FDS and secondly the delay in providing the GeoDirectory, the legacy data and the mapping data, all of which are reasons falling within the scope of clause 6.1 and in respect of which written notice in compliance with clause 6.1 was given by Steria to Sigma.[200]Furthermore, if it be the case that FAT2 could only properly have been completed once the process of automated integration of the legacy data was complete, and if Sigma are not to be treated as having waived that requirement, then whilst in my judgment that was only achieved as at 10 December 2002, that was not the result of any fault on the part of Steria. Instead, it was due to CAMP East and Sigma insisting that Steria should undertake something which was outside the scope of its contractual obligations, properly construed, such that it was a relevant circumstance within clause 6.1, in that:(i) it was a circumstance which entitled Sigma to an extension of time under clause 33.1 of the main contract Either because it was a variation of the main contract, or because the instruction to achieve an 80% match before proceeding further was an ‘act’ of CAMP East or Mason, or because the problems due to the production of legacy data which did not comply with the description in §9 of the CAD Specification were circumstances beyond the reasonable control of the contractor arising after acceptance of the tender. ; and/or(ii) the insistence on Steria achieving an 80% match when Steria was not contractually obliged to do so amounted to a variation of the sub-contract; and/or(iii) the failure to provide data in accordance with §9 of the CAD Specification was a breach of the express term to that effect in that section, and also a breach of the warranty in Schedule 11. I have already concluded that notice within clause 6.1 was properly given on 26 July 2002, 11 September 2002 and 25 November 2002.[201]In particular, it follows from what I have already said that I do not regard the delays attributable to Blue8 as having had any causative impact upon the delay in achieving FAT2 from 15 April to 28 June 2002. This is because:(i) I am satisfied that Blue8 could not have begun work on the mapping data until 24 May 2002 in any event;(ii) since the GeoDirectory and legacy data was only delivered on that date, since FAT2 had already been postponed to the week commencing 24 June 2002 by then due to the delays in relation to the GeoDirectory, the legacy and the mapping data, and since on any view Steria was entitled to 5 weeks to get from receipt of that data to commencement of FAT2, in the event the delay by Blue8 in providing the revised software to load the mapping data in time for FAT2 did not further delay FAT2. I therefore conclude that the dominant cause of delay was not the problems experienced by Blue8, but the delays and problems with the data provided by CAMP East. Even if I am wrong about that, it cannot in my judgment be said that any delay due to Blue8 was any more than an equal cause of delay along with the delays and problems with CAMP East’s data; therefore, in accordance with the principle to which I have already referred, such delay does not disentitle Steria from relying on the other concurrent causes of delay within clause 6.1 which also delayed FAT2 over this period.[202]I am also satisfied on the evidence before me that there is no basis for any suggestion that Steria did not take reasonable action to minimise or to mitigate the consequences of such delay over such period.

H.2. CAUSES OF DELAY IN DELIVERY TO DUBLIN AND IN INSTALLATION AT DUBLIN AND OBI

[203]The date provided for under the sub-contract for completion of delivery to Dublin was 14 June 2002, and the date for completion of installation at Dublin and OBI was 25 July 2002.[204]However since I have already found that FAT2 was not completed through no fault of Steria’s until 28 June 2002, it is apparent that it was not reasonably practicable for these dates to have been achieved. On a simple linear basis, a delay from 15 April 2002 to 28 June 2002 would entitle Steria to an extension of time for completion of these tasks of 10 weeks 4 days, with the revised completion dates being 27 August 2002 and 7 October 2002 respectively.[205]Steria contends [§53 closing] that delivery was achieved on 24 September 2002 and that installation was achieved by 31 October 2002 at the latest, save that installation could not be fully completed because of the absence of a link between RCC and OBI, and because of the lack of air conditioning at OBI to allow the equipment to be used in full operational mode.[206]Sigma however now In its original Defence and Counterclaim Sigma contended that delivery and installation was made by 19 October 2002. In its amended Defence and Counterclaim Sigma contended that delivery was not ‘properly’ achieved until 23 January 2003, but in relation to installation accepted that it was ‘officially’ achieved on 22 November 2002, but not ‘fully’ achieved until January 2002. contends [§93 closing] that these milestones could not be effected until Steria had completed its obligations in relation to loading the legacy data, and therefore contends that these milestones were not achieved until the point at which computerised data loading was completed. Although Sigma also contends that this date was 23 January 2003, I have already found that it was achieved on 10 December 2002.[207]Sigma contends, and I agree, that it was always Steria’s plan to load the GeoDirectory and legacy data before transferring the hardware and the developed and loaded software from Hemel Hempstead to Dublin in preparation for SAT; see the programme at D6/6/1663 noted in §87 Sigma’s closing, and Anthony Smalldridge accepted as much under cross-examination [1/99]. I also agree that from July 2002 onwards the plan was that Steria would demonstrate to CAMP East that it had achieved 80% matching at its Hemel Hempstead premises, so that it would not have been possible to complete delivery and installation until then anyway.[208]In my judgment it is also clear from the evidence that:(a) sometime in late September 2002 / early October 2002 the decision was taken that the process of delivery and installation should not be further delayed until automated data loading was fully completed;(b) by 23 October 2002 the process of delivery and installation was completed, save in relation to those elements which were dependent on the missing WAN link. Thus: (i) In late September 2002 Steria was already delivering certain hardware and software to Dublin RCC; see for example the e-mail dated 24 September 2002 at D2/490.5 in relation to the server (and see also the delivery note at D2/490.2). (ii) The minutes of the progress meeting of 26 September 2002 record at item 1309 [D2/493] that the milestone for ‘Steria system delivery’ was ‘w/e 19 October 2002’. (iii) In early October 2002 Steria and Sigma were in discussions as to the timetable for the installation of the database and the network installation at Dublin: D2/500. (iv) It is evident that installation and loading was proceeding in Dublin in mid-October 2002: D2/503.1. (v) The revised programme in the minutes of the progress meeting of 23 October 2002 [item 1309] no longer includes reference to ‘Steria system delivery’, and the clear inference in my judgment is that by this stage delivery and installation were complete, or at least as complete as they could be given the absence of a microwave link between RCC and operational air conditioning at OBI: see item 1409 of the minutes. (vi) This conclusion is consistent with the following exchanges in cross-examination of David Cartwright [4/47]: Q. You, in fact, were ready to move from Hemel Hempstead in October, weren't you? Well, the end of September and first part of October because that is when you delivered the hardware and software. A. We delivered the OBI equipment earlier. Q. Yes. A. The delivery of the main service to the RCC was only able to go ahead when CAMP accepted that what we had done in terms of matching and merging was satisfactory to them. Q. Yes, because you wanted to cope with the matching and merging problem on the servers which you had installed in Hemel Hempstead. Right? And they wanted you to do that. A. That is what they insisted we did. Q. Yes. And you were not ready to -- at least they were not ready to give you the go ahead to move until somewhere around 20th September. Isn't that right? A. Yes, round about that time.[209]It follows in my judgment that although there was a delay in achieving the delivery and the installation milestones, the reason for that delay post FAT2 was due to CAMP East’s insistence that an 80% data matching should be achieved and that this should be demonstrated at Hemel Hempstead, and that this position did not change until sometime in late September 2002 / early October 2002. The result, in my judgment, is that Steria is entitled to an extension of time under clause 6.1 to the dates of actual completion of delivery and installation, having given the requisite notice of delay due to CAMP East’s insistence on achieving 80% automated loading by the communications of 26 July 2002 [D1/325], 11 September 2002 [D1/483-484] and 25 November 2002 [D2/590, D6/1588].[210]Moreover, even if I were to accept Sigma’s submission that these milestones were not completed until automated loading was completed, precisely the same conclusion would follow, since I have already found that Steria is entitled to an extension of time to reflect the full delay to the project over this period for that reason. Insofar as it is the case that installation could not be fully completed until the WAN link was made ready, which appears (see the next section) not to have been until late March 2003, then that is something for which Sigma was responsible and for which notices of delay were given (again see the next section), so that Steria would be entitled to a full extension of time to that time anyway.

H.3. CAUSES OF DELAY IN SAT

[211]The contract date for completion of SAT was 20 September 2002. It is common ground that SAT was not achieved until early April 2003 There is an issue as to whether it was achieved on 1 April or on 4 April 2002. . For reasons which have already been set out in this judgment, Steria was on any view entitled to an extension of time of just under 11 working weeks to reflect the delays to FAT2, which would take the time for completion of SAT to 3 December 2002.[212]However, as I have already recounted in this judgment:(i) CAMP East had insisted that SAT could not proceed until both the automated data loading process and the manual data loading process had been completed.(ii) That was an insistence on Steria doing something which was outside the scope of the sub-contract, and thus was an event falling within clause 6.1 for which Steria was entitled to a reasonable extension of time. (v) The automated data loading process continued until 10 December 2002, at which point the time came for CAMP East to perform the manual loading process. As set out in the immediately following section, the evidence is that once CAMP East realised the magnitude of the manual data loading process they decided to reduce very substantially the quantity of manual data loading required before SAT could proceed, and they only achieved this reduced loading in time for SAT to commence on the agreed revised date of the week commencing 10 February 2003.

Manual loading

[213]The project report for the meeting of 12 December 2002 recorded [D2/650] that:(i) Steria had already conducted its pre SAT tests, the vast majority (90%) successfully:(ii) SAT was provisionally booked for the week commencing 13 January 2003, but this was dependent on CAMP having loading sufficient manual; data to enable them to do so.[214]However by 13 January 2003 CAMP East had not even begun the process of manual data loading: see the progress report at D2/689. That report records that by this stage CAMP East had decided that SAT could proceed once it had loaded the data for Longford and for 25% of Dublin. On this basis, the SAT was postponed to the week commencing 10 February 2003. This was confirmed in the progress meeting of 23 January 2003 at D2/717.[215]It appears that the manual loading for Longford and 25% of Dublin was completed by this date, so that SAT was able to proceed in that week.[216]Notice of the delay due to the need for manual loading to be completed before SAT could proceed was given in correspondence, particularly in Steria’s letter dated 5 December 2002 [D2/621]. This communication was in my judgment a notice which complied with the requirements of clause 6.1 of the sub-contract.[217]It follows, in my judgment, that the true cause of delay up to the 10 February 2003 in relation to SAT was the delay due to the completion of the automated and manual loading processes, for which Steria is entitled to a full extension of time under clause 6.1.

Absence of WAN link to OBI

[218]Steria’s case is that the overriding cause of delay in completing SAT from 10 February 2003 to early April 2003 was the absence of a WAN* link from RCC to OBI. It is common ground that this is one of the items of infrastructure which were required in order to complete the acceptance tests specified by Schedule 12 to the sub-contract Clause 2.4.3 in relation to FAT and clause 2.5.3 in relation to SAT. . Although Sigma accepts that the link was not in place in time for the first SAT in the week commencing 10 February 2003, and was only in place in time for the adjourned SAT run in the week commencing 24 March 2003, it contends that this was not the dominant cause of delay over this period, because – it says – SAT failed for other reasons in any event. Sigma does not and could not credibly dispute that if delay was caused due to the absence of a WAN link that was a relevant circumstance within clause 6.1 of the sub-contract.[219]So far as the chronology is concerned, it is apparent that from an early stage Steria had identified the presence of this link as one of a number of items of infrastructure which was necessary to be in place before SAT could proceed. Thus for example on 26 July 2002 Steria e-mailed Sigma [D2/364] in the express context of beginning to prepare for SAT, asking for a progress report in relation to the network infrastructure items for which CAMP East was responsible. In his reply [D2/365] Paul Kearney acknowledged that this was a ‘timely reminder’, and that he was continuing to push CAMP East on these items. These fears were repeated by Steria in its e-mail of 29 August 2002 [D2/418]. In its e-mail of 11 September 2002 [D2/464] Steria identified this as a cause of delay. In the progress meeting on 26 September 2002 [D2/491] it was noted [item 1306] that CAMP East was awaiting approval internally for the circuits to OBI, and it is plain from the context that it was recognised that these were required to be installed in advance of Steria’s SAT. In the progress meeting of 23 October 2002 it was noted [item 100804, D2/523] that Sigma and CAMP East were still discussing the options in relation to what was by then proposed, namely a microwave link, and it was included in an ‘outstanding actions and issues list’ sent on 31 October 2002 [D2/536]. It was referred to in Steria’s letter of 5 December 2002 [D2/621 as being a cause of delay, and as at 23 January 2003 it was noted at item 1708 of the progress meeting [D3/719] that ‘the network equipment to link the OBI to Tara Street … is ordered but it may not be installed in time for the SATs’.[220]Sigma accepts [§100 closing] that the SAT was run on 12 February 2003 without the WAN link to OBI being in place. Sigma does not advance any positive case to the effect that there was a formal variation of the contract whereby those elements of SAT which were dependent on there being a WAN link were removed from the scope of Steria’s obligations. In §101 of Sigma’s closing it is asserted that the SAT test failed due to the presence of 27 specific identified defects, so that even had the WAN link been present SAT would still have failed, and in §102 it is asserted that the adjourned test proceeded on 1 April 2003 when the WAN link was in place, and following the resolution of 6 bugs was completed on 3 April 2003. David Cartwright’s evidence, which I accept, was that the adjourned test could not have proceeded until the WAN link was in place, thus: A. Because it was mandated by CAMP that they wanted the second SAT test to test the link, we could not schedule the second SAT until we had confirmation that that link had been installed. So it was the link being installed which dictated the date for the second SAT. Q. Right. A. So to say it didn't hold us up doing the second SAT, we couldn't do the second SAT until we'd had it confirmed that it was installed. So the lack of the WAN was delaying the running of the second SAT.[221]The 27 defects are identified in the problem summary list produced following the first SAT run [D3/782]. It appears that there was then a series of discussions about why these defects had occurred, and who was responsible for fixing them, and in the event it appears to have been agreed that some were the responsibility of Steria and others the responsibility of CAMP East. Following the re-run in the week commencing 24 March 2003 it appears that 6 further items were raised [D3/840, 840.1], and that those were resolved by 3 April 2003 [D3/844], with the result that CAMP East issued a payment certificate in relation to SAT on 4 April 2003 [D3/838]. I am satisfied, therefore, that SAT was achieved on 4 April 2003, and not on 1 April 2003, as Steria submitted.[222]In §78 of Steria’s closing the point is made that since the SAT did not formally exclude those elements dependent on the WAN link then the SAT could not possibly have succeeded until that link was provided, regardless of the other reasons for failure of the first run of SAT. In my judgment that point is well-made, and Sigma has no real answer to it. Although David Cartwright was cross-examined by Mr Blunt Q.C. for Sigma [4/40-43] on the basis that CAMP East would not have failed SAT in February 2003 if the WAN related problems had been the only problems, David Cartwright retorted that this was not what was said or done at the time, and of course in the event SAT was not re-run until the WAN link was in place. When challenged by Mr Hargreaves for Steria as to whether or not he was positively suggesting to David Cartwright that Sigma had in fact waived the need for Steria to complete those elements of SAT which were dependent on the WAN link, Mr Blunt clearly acknowledged that this was not Sigma’s case. Whilst it is true that in paragraph 74 of his witness statement David Cartwright stated that ‘Steria understood that it would be acceptable to Sigma and DCC for there to be a ‘qualified’ SAT which did not include the non-functional tests’, that does not contain the necessary ingredients either for a variation or contractual waiver. I have little doubt that if in February 2003 the SAT run had been successful save in relation to those elements which depended on a WAN link it is likely that some form of conditional certificate would have been issued, in the same way as it was for FAT2. However, that is very different from expressly excluding such elements from the scope of Steria’s obligations in relation to SAT, which was never done either before or after the February SAT.[223]I conclude therefore that the absence of the WAN link was a substantial cause of delay, and was in fact the dominant cause of delay, from 12 February 2003 through to the conclusion of the re-run SAT on 28 March 2003. I am sure that if the WAN link had been in place by the time of the first SAT, then the approach by Steria to the resolution of the other problems would have been very different, because they would have known that any delay in fixing these bugs was:(a) holding up payment; and(b) potentially exposing them to liquidated damages. Furthermore, I conclude that the absence of the WAN link was a cause of delay falling within clause 6.1, that proper notice of that delay was given by the communications of 11 September 2002 [D2/463] and 5 December 2002 [D2/621], and that Steria is entitled to an extension of time under clause 6.1 to reflect the delay caused by the absence of the WAN link.

Other causes of delay to SAT

[224]That would justify an extension of time to 28 March 2003, i.e. the Friday of the week fixed for SAT. However, it also follows in my judgment that there was a further week of delay to 4 April 2003 for which no adequate explanation has been advanced or notified by Steria as to why these further 6 bugs arose and took 1 week to resolve, in circumstances where this was a re-run of a test conducted a number of weeks earlier, and where 27 faults had already been observed and apparently rectified in the intervening period. Other causes of delay to SAT Steria also relies on a number of other matters as causing delay to SAT. Thus Steria argues that there were delays in approving test scripts for SAT, and the evidence appears to establish that this was so. However, in my judgment these delays were incidental to the overriding delays caused by the automated loading process, the manual loading process, and the absence of a WAN link. Steria also relies on delay due to ongoing industrial negotiations between DCC and the fire officers’ trades union. Again, I agree that the evidence discloses that throughout the whole project DCC were extremely sensitive to the whole question of staffing sensitivities, and in particular did not wish to cause difficulties by introducing the new system, or training in it, until they were completely satisfied that it would work. However again this in my judgment was incidental to the overriding causes of delay noted above, or perhaps more precisely was merely one of the reasons causing those delays; for example fear of antagonising staff by working with an incomplete system appears to have been a factor in CAMP East’s desire to have an 80% automated load complete before beginning training. Furthermore, none of these reasons would justify the delay from 28 March 2003 onwards in completing SAT.[225]It follows, in my judgment, that Sigma has established a claim to liquidated damages in relation to one week of delay to SAT from 28 March 2003 to 4 April 2003.

I. SIGMA’S COUNTERCLAIMS

[226]As stated above, my conclusion is that Sigma is entitled to recover liquidated damages for 1 week’s delay to SAT, in the sum of IR6,055.08 (which at the rate provided for by Schedule 4 of the sub-contract amounts on my calculation to €7,688.37). Otherwise, the claim for liquidated damages for delay must fail.[227]The claims for unliquidated damages, as pleaded in the Amended Defence and Counterclaim, are made under clause 3.4 of the sub-contract. This clause, which is expressly stated to be subject to clause 7.1, requires the sub-contractor to indemnify the contractor ‘against any liability which the contractor may incur to any other person and against all claims, demands, proceedings, damages, costs and expenses made against or incurred by the contractor by reason of any breach by the sub-contractor of the sub-contract’. (There is also an aggregate cap on liability set at the sub-contract price, but that is not relevant here, since the claims on any view come nowhere close to that amount.) The claims, which are expressly pleaded to arise ‘by reason of the Claimant’s aforesaid delays in breach of the Supply Agreement It should be noted that the only pleaded causes of the delays in handover of the system under the main contract are:(i) Steria’s delay in achieving SAT;(ii) CAMP East’s loss of confidence in Steria during the course of the project’ [§20 Amended Defence and Counterclaim]. ’, are said to be as follows: (i) 12 months’ loss of income under its maintenance agreement with CAMP East, in the sum of €275,000. This is said to arise on the basis that whilst Sigma’s liability to make maintenance payments to Steria began on 14 March 2003, it was not until system handover under the main contract on 20 February 2004 that Sigma began to earn income under the maintenance agreement under the main contract. (ii) The future cost to Sigma of having to obtain an extra 12 months’ extension to the maintenance service from Steria with effect from March 2008, when the existing 5 year contract expires, down to February 2009, when the maintenance liability under the main contract expires.(iii) The cost of allocating 2 engineers to the project on a full time basis from March 2003 until February 2004, said to be approximately €105,000.(iv) The loss due to the delayed receipt by Sigma from CAMP East of the payments due under the main contract on handover and completion of defects liability, said to be approximately €20,000.[228]So far as these claims for unliquidated damages are concerned, I am satisfied that they are prohibited by the concluding words of clause 7.1 which, it will be recalled, provides that any payment of liquidated damages under that clause shall be ‘in full satisfaction of and to the exclusion of any other remedy’ of the contractor against the sub-contractor in respect of the failure of the latter to complete the sub-contract works within the time for completion. Clause 3.4 is expressly stated to be subject to clause 7.1, and I have already held that clause 7.1 is a valid and effective clause. There is no reason, nor does Sigma advance any reason, why the concluding words of clause 7.1 are not effective to bar any claims for unliquidated damages for delay.[229]I should however simply and shortly state that if I was wrong about that, I am satisfied firstly that Steria cannot be held responsible for any delay to the project post SAT and secondly that Sigma has not proved a case for unliquidated damages in relation to any such delay.[230]So far as delay post SAT is concerned, the first difficulty for Sigma is that the last of Steria’s time-related obligations under the sub-contract was the completion of SAT. Since I have already found that only one week of the total delay of almost 6 months in completion of SAT from the contract completion date of 20 September 2002 to the actual completion date of 4 April 2003 can be laid at Steria’s door, it follows that any substantial delay in completion of the main contract works as a result of the delay in completion of the sub-contract SAT cannot be laid at Steria’s door. This is the only pleaded cause of delay due to Steria, other than the allegation that CAMP East lost confidence in Steria. So far as that is concerned, what Mr Robinson said in §42 of his witness statement was that ‘because of the difficulties experienced in the data integration and acceptance testing CAMP East lost confidence in the system and insisted on a full system check before agreeing to handover’. Since I have already held that the difficulties in data integration and acceptance testing were, save for 1 week of delay in completion of SAT, not the contractual responsibility of Steria, it follows that Steria cannot be held legally responsible for any such loss of confidence.[231]The second difficulty for Sigma is that it is unable to advance a coherent case as to why the entirety of the delay from completion of sub-contract SAT to main contract system handover is Steria’s responsibility. The evidence of Shaun McGinley on this point in the section entitled ‘Project Handover’ is lacking in detail insofar as it is intended to explain why a delay of almost 12 months can wholly be attributed to Steria. Furthermore, it is apparent from the chronology to which I have already referred that there was no possibility of the system going live until the manual loading for the entire CAMP East area had been completed. However Shaun McGinley makes no explicit reference to this at all in his witness statement. He eventually accepted under cross-examination however [3/18-19] that CAMP East’s stance was that it was not prepared to accept handover until such time as the manual loading process was complete. He also accepted under cross-examination that this process ‘could have been’ ongoing until handover, and given the volume of manual data required to be input, and given the difficulties experienced by CAMP East in achieving that process pre-SAT, the likelihood in my judgment is that it was. When one considers that despite what was, on Sigma’s case, a delay of almost 12 months from SAT to system handover which was entirely due to Steria, for whom it was contractually responsible vis-à-vis CAMP East, it is remarkable to say the least that no liquidated damages were ever levied against it by CAMP East. Sigma has advanced no explanation as to why CAMP East decided to forego what was a substantial entitlement. The only sensible explanations, in my judgment, are either:(i) that CAMP East was in no particular hurry to proceed to system handover anyway, probably because of the industrial relations issues which so clearly heavily influenced its approach over the life of the project; or(ii) that CAMP East accepted that since it was responsible for manual loading it could not complain about the delay in achieving system handover when the delay was at least in part due to the delay in completing that process.[232]I also accept Steria’s submission [§§90-93] that other causes of delay to system handover over this period, for which Steria could not have been responsible, were:(i) the completion of simulation testing;(ii) DCC's earlier decision to postpone training due to industrial relations issues. The consequence, as Steria submits, is that Sigma have not only failed to make out a case on their pleaded case as to the reasons for delay, they have also failed to make out a case that any specific part or parts of the overall delay was due to matters for which Steria alone was responsible.[233]So far as the heads of claim are concerned, the claims summarised under paragraph 227(i) and (ii) above arise due to the disparity between the commencement date and the duration of the maintenance agreement between Sigma and Steria and that between Sigma and CAMP East. However, it is apparent from Sigma’s pleaded case, from the evidence in the witness statement of Niall Robinson [§§32-34], and from the contemporaneous correspondence, that:(i) Sigma freely Although complaints tantamount to duress were advanced, they were not pursued in Sigma’s pleaded case or its case at trial, and the evidence shows clearly that the primary motivation for Sigma to enter into the maintenance agreement when they did was to guard against the risk of having to pay an increased rate if they delayed entering into the agreement later on. entered into the maintenance agreement with Steria at a time when the issues of delay were very much to the fore;(ii) Sigma’s understanding was that Steria had agreed to review the start date under the maintenance agreement if the timetable was delayed due to Steria. The difficulty for Sigma is that: (a) it has never pleaded or advanced a case based upon a contractual interpretation of the maintenance agreement under which Steria ought to have reviewed and extended the start date; (b) in any event, given my findings as to responsibility for delay there would have been no basis for an extension beyond 1 week anyway. I agree therefore with Steria that the real cause of the losses complained of is not a delay due to Steria from SAT to handover, but is due to Sigma having agreed to enter into a maintenance contract with Steria under which it accepted the risk of there being a potential imbalance between the start date under that contract (and thus the start of payments under that contract), and the start date under the maintenance contract as between Sigma and CAMP East.[244]So far as the claim for the extra engineers’ time on the project is concerned, no evidence was provided by Sigma beyond the bare assertion in §42 of Niall Robinson’s witness statement, and the same is true of the claim for loss due to delay by CAMP East in releasing retention monies, which in any event appears to have been of the order of 2 years [§44 Niall Robinson] compared with an eventual delay under the main contract of only 1 year of thereabouts.[245]For all of those reasons, the counterclaim for unliquidated damages fails in its entirety in my judgment.

J. CONCLUSIONS

[246]It follows, in my judgment, that Steria is entitled to judgment on its claim in the sum pleaded, namely €153,786.89, and that Sigma is entitled to recover liquidated damages in relation to one week of delay to SAT in the amount of IR6,055.08 (€7,688.37). Steria has not submitted to me that there should not be a set-off of one claim against the other and so, subject to converting the sums into the same currency, it appears that the end result is that Steria should be entitled to a net judgment in its favour in the sum of €146,098.52.[247]I will address questions of interest and costs once the parties have had the opportunity to digest this substantive judgment.[248]It remains only for me to express my gratitude to all involved in the preparation for and the presentation of the case, which was of the highest order.241. Glossary of organisations: Name Description Blue8 Blue8, previously known as SER. A sub-contractor to Steria, and the company responsible for the provision of the GIS. CAMP East Computer Assisted Mobilising Projects East, the employer under the main contract. The lead organisation for the employer was the Dublin Corporation. DFB / DFA Dublin Fire Brigade / Dublin Fire Authority ERAS Eastern Regional Ambulance Service Mason Mason Communications Ireland. Communications consultants employed by CAMP to design and project manage the CAMP East project. OSI Ordnance Survey Ireland Sigma Sigma Wireless Communications Limited, the Defendant main contractor. Steria Steria Limited, the Claimant sub-contractor. Previously known as Bull Information Systems Limited (‘Bull’), and subsequently Integris UK, before becoming Steria.242. Glossary of persons: Name Organisation & Role John Armstrong Steria. Technical programmer, working alongside Anthony Smalldridge. David Cartwright Steria. Senior project manager, responsible for the project throughout. Paul Kearney Sigma. Project manager, responsible for this project until October 2002. Anthony Maguire Sigma. Managing Director, responsible for main contract negotiations. Shaun McGinley Sigma. Project manager in succession to Paul Kearney. Niall Robinson Sigma. Financial Director. Richard Sheehan CAMP East. DMS Manager Anthony Smalldridge Steria. Storm product consultant243. Glossary of places: Place Description Hemel Hempstead Steria’s UK premises Longford A (small) county within CAMP East RCC The CAMP East Regional Control Centre at Tara Street, Dublin. The principal location for the system. OBI The O’Brien Institute in Dublin. The disaster recovery centre in Dublin, where the back up system was to be located, and where staff training was to take place.244. Glossary of terms: Name Description CAD system Computer Aided Dispatch system: The system whereby emergency calls are taken by the emergency operator, appropriate emergency vehicles are despatched, and appropriate records maintained. Compass The gazetteer database produced by Blue8 and from which data was loaded onto STORM. FAT Factory Acceptance Tests: The tests to be undertaken at Steria’s premises on its element of the works before delivery to Dublin. FDS Functional Design Specification: The detailed description of the sub contract works. Geodirectory The commercial database of addresses in Ireland produced by Ordnance Survey Ireland (OSI) and An Post (the Irish postal service). Its equivalent in the UK was known as ‘AddressPoint’. GIS Geographic Information System: A system of hardware and software used for the storage, retrieval, mapping and analysis of geographic data. Legacy data Data held by the authorities forming CAMP East in their existing databases. Mapping The provision of computerised (digital) maps. There are references to vector and to raster maps, which are both particular types of digital maps. MIS Management Information System: A part of the mobilisation and communications system, involving the production of management information for the system. Although supplied by Steria as part of the sub contract, it is not directly relevant to this case. PDA Pre-Determined Attendance: A feature under which when the incident location is called up by the operator the system is able to determine the nearest fire or ambulance station to the incident location. Note also a further optional requirement of the system was an ‘AVLS’, which is an Automatic Vehicle Location System’, under which the closest fire appliance or ambulance to the incident location could be identified. SAT Site Acceptance Tests: The tests to be undertaken at Camp’s premises in Dublin. STORM The mobilising system developed by Steria and supplied to Sigma under the sub contract. WAN link Wide area network link: The connection between RCC and OBI which allowed data to be transferred between both sites.

Cited in 3 later judgments