![]() |
[Home] [Databases] [World Law] [Multidatabase Search] [Help] [Feedback] [DONATE] | |||||||||
England and Wales High Court (Technology and Construction Court) Decisions |
||||||||||
PLEASE SUPPORT BAILII & FREE ACCESS TO LAW
To maintain its current level of service, BAILII urgently needs the support of its users.
Since you use the site, please consider making a donation to celebrate BAILII's 25 years of providing free access to law. No contribution is too small. If every visitor this month gives just £5, it will have a significant impact on BAILII's ability to continue providing this vital service.
Thank you for your support! | ||||||||||
You are here: BAILII >> Databases >> England and Wales High Court (Technology and Construction Court) Decisions >> Steria Ltd v Sigma Wireless Communications Ltd [2007] EWHC 3454 (TCC) (15 November 2007) URL: https://www.bailii.org/ew/cases/EWHC/TCC/2007/3454.html Cite as: [2007] EWHC 3454 (TCC), [2008] CILL 2544, 118 Con LR 177, [2008] EWHC 3454 (TCC), [2008] BLR 79 |
[New search] [View without highlighting] [Printable RTF version] [Help]
QUEEN'S BENCH DIVISION
BIRMINGHAM DISTRICT REGISTRY
TECHNOLOGY AND CONSTRUCTION COURT
HIS HONOUR JUDGE STEPHEN DAVIES SITTING AS A JUDGE OF THE HIGH COURT
33 BULL STREET BIRMINGHAM B4 6DS Date of draft judgment: 28 September 2007 |
||
B e f o r e :
Between:
____________________
STERIA LIMITED | Claimant | |
and | ||
SIGMA WIRELESS COMMUNICATIONS LIMITED | Defendant |
____________________
Mr David Blunt, Q.C. of Counsel (instructed by Pinsent Masons) for the Defendant
____________________
Crown Copyright ©
A. INTRODUCTION
Structure of the judgment
A. Introduction (pp.2-3)
B. The history leading up to the conclusion of the sub-contract and the main contract (pp.3-5)
C. The terms of the sub-contract (pp.6-20)
D. The scope of Steria's obligations in relation to legacy data loading and integration (pp.21-24).
E. The terms of the main contract (pp.25-28)
F. The extension of time provisions of clause 6.1 of the sub-contract (pp.29-36)
G. Is clause 7.1 of the sub-contract a valid liquidated damages clause or a penalty? (pp.37-42)
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. Sigma's counterclaims (pp.83-86)
J. Conclusions (p.87)
K. Glossaries (pp.88-92)
B. THE HISTORY LEADING UP TO THE CONCLUSION OF THE SUB CONTRACT AND THE MAIN CONTRACT
(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.
(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.
C. THE TERMS OF THE SUB CONTRACT
- 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.)
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 |
(i) Clause 3.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) Clause 3.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'.
"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."
"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."
"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 |
"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).
…"
The ITT Contract specification
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.
Sigma relies on certain conditions of the MF/1 Conditions as incorporated into the sub-contract.
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.
CAD specification
(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.
(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.
(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.
'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'.
'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'.
'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 …'
(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.
The FDS
D. THE SCOPE OF STERIA'S OBLIGATIONS IN RELATION TO LEGACY DATA LOADING
(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.
(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].
(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.
(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[1].
(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.
E. THE TERMS OF THE MAIN CONTRACT
'… the percentage stated in the Appendix of the contract value[2] 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 …'
(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'.
F. THE EXTENSION OF TIME PROVISIONS OF CLAUSE 6.1 OF THE SUB-CONTRACT
What is required of a notice under clause 6.1?
Is the notice requirement a condition precedent?
'Insofar as the extension of time clause is ambiguous, it should be construed against the contractor.'
'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.'
The application of the 'prevention' principle
"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."
G. IS CLAUSE 7.1 OF THE SUB-CONTRACT A VALID LIQUIDATED DAMAGES CLAUSE OR A PENALTY?
(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%.
Is the liquidated damages provision of the sub-contract contractually uncertain?
'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%'.
(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.
H. CAUSES OF DELAY AND DELAY NOTICES
The individual witnesses
Anthony Smalldridge
(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[7].
(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
Shaun McGinley
David Cartwright
Niall Robinson
Absent witnesses
Clause 6.1 and concurrent causes of delay
'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.'
H.1. CAUSES OF DELAY TO FAT2
Delay in agreeing the FDS
Delay in providing GeoDirectory, mapping and legacy data
Completion of FAT2
Legacy data integration
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.
Sigma's criticisms of Steria's data loading and integration
'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]
(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].
(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.
To what extension of time is Steria entitled in relation to FAT2
H.2. CAUSES OF DELAY IN DELIVERY TO DUBLIN AND IN INSTALLATION AT DUBLIN AND OBI
(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.
H.3. CAUSES OF DELAY IN SAT
(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
Absence of WAN link to OBI
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.
Other causes of delay to SAT
I. SIGMA'S COUNTERCLAIMS
(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.
J. CONCLUSIONS
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. |
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 consultant |
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. |
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. |
Note 1 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. [Back] Note 2 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. [Back] Note 3 In its response to Steria’s closing submissions Sigma accepted that this was a ‘should’ rather than a ‘must’ [paragraph 1.2]. [Back] Note 4 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. [Back] Note 5 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. [Back] Note 6 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. [Back] Note 7 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]. [Back] Note 8 In the original version of the Defence and Counterclaim it was pleaded that FAT2 was completed on 4 July 2002. [Back] Note 9 This process was explained in evidence by Anthony Smalldridge at 1/65. [Back] Note 10 See the lengthy exchange at 1/166-170. [Back] Note 11 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. [Back] Note 12 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. [Back] Note 13 There is an issue as to whether it was achieved on 1 April or on 4 April 2002. [Back] Note 14 Clause 2.4.3 in relation to FAT and clause 2.5.3 in relation to SAT. [Back] Note 15 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]. [Back] Note 16 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. [Back]