England and Wales High Court (Technology and Construction Court) Decisions

IN THE HIGH COURT OF JUSTICE
QUEEN'S BENCH DIVISION
TECHNOLOGY AND CONSTRUCTION COURT

		Royal Courts of Justice Strand, London, WC2A 2LL
		16/12/2010

 


Mr Justice Edwards-Stuart:

Introduction

1. The Claimant in this action, to whom I shall refer as De Beers ("DB") although at the relevant time its name was the Diamond Trading Company ("DTC"), probably needs no introduction. Unsurprisingly, this action arises out of the movement and handling of diamonds.
2. In about May 2006 DB entered into a joint sales agreement for 5 years with the Government of the Republic of Botswana ("GRB") which included an undertaking by DB to move a major part of its operations, in particular what is known as the aggregation process, to Botswana (although it is not clear whether this obligation was contractually binding). This undertaking came about partly because Botswana produces about 25% of the diamonds handled by DB and partly because DB wished to make a contribution to the economy of the Republic of Botswana. This transfer of operations would have involved the development of a software system to support the diamond supply chain management and DB decided also to take the opportunity at the same time to upgrade its existing software systems, which were out of date and often differed from department to department.
3. In April 2007 DB put the software contract out to tender with a view to selecting a shortlist of two potential suppliers from whom it would obtain a Best and Final Offer ("BAFO") before finally entering into a contract with one of them.
4. The Defendant, to whom I will refer as Atos, was one of the companies who responded to the invitation to tender. It was ultimately successful. However, at some point during the tender process DB decided to enter into a preliminary contract, known as the Initiation and Analysis Phase ("IAP"), in order to give the chosen software supplier an opportunity to investigate and analyse the business requirements of DB so that it would be in a better position to enter into a fixed price contract for the project.
5. This duly happened and, by a letter of intent dated 11 July 2007, Atos agreed to carry out the IAP. They did so between the end of June and October 2007, at the end of which they entered into a fixed price contract for the project in November 2007 ("the Contract").
6. Unfortunately things did not go well. In spite of attempts by Atos to replace the weaker members of its team and to bring in additional senior managers and other staff, progress fell well behind schedule and this continued until March 2008 when Atos told DB that it would not be able to deliver the software by the end of June 2008, as the Contract required, and would probably not be able to do so before mid October 2008. This was not acceptable to DB and protracted discussions ensued with a view to arriving at an acceptable revised programme, which the parties did in early April 2008.
7. In the meantime, on 3 March 2008 Atos issued its fourth invoice, which DB failed to pay. It was for a sum a little in excess of £320,000, and was due for payment at the beginning of April 2008. The reason given by DB for refusing to pay this invoice was its dissatisfaction with delays and with the quality of the work being done by Atos. At the same time the senior management within Atos had become very concerned about the substantial cost overruns on the contract.
8. By a letter dated 21 May 2008 Atos claimed that the progress of the work had been delayed and obstructed by the lack of co-operation from DB and by very significant increases in the scope of the work and that, unless DB agreed to renegotiate the contract by 31 May 2008, Atos would suspend all further work. Atos relied also on the non-payment of the fourth invoice. Although, at DB's request, the deadline was extended to 6 June 2008, DB was not prepared to negotiate on these terms and Atos suspended work at the end of the first week in June. The work was never resumed.
9. In these proceedings each side is asserting that the termination was the result of a repudiatory breach of contract by the other which it accepted. Which of them is right about this is the central issue in the case. Depending on the outcome of that issue, there are consequential and difficult issues of causation and quantum of damages. Both sides claim substantial sums.

The De Beers operation

10. Since DB's business concerns diamonds, for reasons of security it has always been anxious to ensure that its internal processes were kept confidential, with the result that different departments within the company operated in a series of organisational "silos" in which the particular business processes involved were carried out in relative secrecy. For the same reasons the company was reluctant to use third party consultants or service providers in relation to matters such as IT systems. Historically, therefore, DB had developed its own IT systems using in-house resources and these tended to be configured specifically for each different department. The result was that instead of having what is known as an "end to end" system, many departments had their own bespoke software so that there were a large number of interfaces between different parts of the system and a good deal of duplication. This was obviously inefficient.
11. Accordingly there was a strong case for updating and harmonising the DB IT systems throughout the company. Previously, in about January 2000, DB had engaged Accenture to redevelop its integrated stock management systems, but the project did not go well and after three years it was terminated without achieving most of its objectives. Accenture complained that the project had gone badly because Accenture's team had not received sufficient cooperation from the relevant personnel within DB, and so one of the lessons that came out of this unsuccessful project was that DB came to recognise just how unusual the nature of its business was and the difficulty facing outside consultants who needed to understand it.
12. DB has a long connection with GRB and, as I have already mentioned, in 2006 it decided to move its aggregation process from London to Botswana. Aggregation is the process by which operators combine and blend batches of sorted uncut diamonds, some of which have been extracted by DB in its own mines in Botswana and others of which have come from mines elsewhere in the world. The identification, classification and valuation of the diamonds take place before they get to the aggregation process. This sorting and blending process requires highly trained experts because there are over 16,000 different categories of uncut diamond based on a stone's size, shape, quality and colour. This gives an indication of the sophistication of the operation. The object of aggregation is to ensure consistency and accuracy in supply for DB's customers, who are known as "sightholders" (because they attend the "sights" or sales weeks at which the rough diamonds are sold).
13. The following description of the physical processes which take place along the Aggregation part of the supply chain (or pipeline) is largely taken from Atos's opening submissions. For the purposes of this action it starts with the diamonds which are already sitting in a local sorting office ("LSO"), to which they have been transported from the mine. The first module in the pipeline is "Export for Aggregation": this covers the steps which need to be taken in order for the diamonds to be transported (exported) from the LSO to their destination for Aggregation (which was to be Gaborone in Botswana). The next module, "Import for Aggregation", covers the steps taken when the diamonds are received for Aggregation. Having received the diamonds, the next stage is described as "Rolling Management": here the diamonds from the different mines, which have been imported for Aggregation, are aggregated or "rolled" together - a process which, as will now have become apparent, is not as simple as it sounds. After the stones have been aggregated, they are split up into the groupings in which they will be presented to the sightholders for sale: this is known as "Splitting". It is common ground between the parties that "Splitting" was originally outside the scope of the Contract: it was introduced by means of a change request. Once the diamonds have been split up (into boxes), they are then exported for the purposes of the sights which are to be held: this is "Export for Sight". The next module is "Import for Sight", which consists of the steps to be taken at the LSO (now a local sales office) when the boxes of diamonds are received. The final stage in the pipeline is the steps to be taken in order to prepare for and hold the sight, attended by sightholders from all around the world, "Prepare and Hold Sight".
14. From an IT point of view one of the challenges of the aggregation process was that it required a system that would keep a precise check on the diamonds as they moved through the process so as to ensure that no stones are lost and would provide facilities for valuing the stones (or groups of stones) as they went on - as well as providing a proper audit trail of the movements of the stones.
15. Although it was the decision to move the aggregation process to Botswana that may have provided the trigger for a new IT system, DB says that a new IT system was desirable in any event because of the increasing obsolescence of and difficulty in maintaining its old "legacy" systems. The proposal to improve or replace a number of its existing legacy systems and to reduce information bottlenecks became the Enterprise Application Integration Project ("EAI Project").

Description of roles and glossary of terms

16. For those unfamiliar with the software industry it may be helpful to describe some of the principal actors involved in designing and developing software and to say something about the language. I emphasis that these are largely my own descriptions and they are not intended for any purpose other than that of making this judgment intelligible.
17. First, there are business analysts ("BAs"), whose job it is to analyse the client's business and establish precisely what is involved in the processes under consideration. They need to have IT experience as well as the ability to extract and analyse the relevant information from the customer.
18. There are technical architects, whose role is to evaluate the system in terms of its individual components and to design the outline of the software. At the detailed level, this involves the design of programmes. At the macro level it involves looking at "services and systems in the large" (Mr Cotter's description, at Day 9, 105/16-17). A person performing the latter role would sometimes be called an enterprise architect. Another design role is performed by the systems analyst or engineer, who takes an overall view of how the system should work and what should be built (taken from Dr Thomas's evidence, at Day 13, 67/20 - 68/7).
19. Finally, there are developers, who write the code, and database designers, who designed the databases. Each of these might either be employed by the supplier or be an external consultant engaged for a particular project or period of time. The Atos project team included people in all these roles, both employed and consultants, except for a systems analyst or engineer (or, at least, until very shortly before the contract was terminated).
20. On DB's side there were also in-house technical architects and business analysts, as well as business or subject matter experts, to whom Atos's business analysts needed to speak in order to establish - or, as they would say, to "capture" - the requirements of the processes. Like many industries, the IT industry has its own jargon: for example, in the IT industry it seems that people do not see or know things, rather they have "visibility" of them.
21. The following glossary of terms and abbreviations is taken largely (and gratefully) from the glossaries provided by the parties in their opening submissions (for ease of reference a copy of this table is appended to this judgment). I will avoid using the less common abbreviations where possible, but inevitably they will appear in documents that are quoted in this judgment.

AO	Atos Origin (Atos)
BA	Business Analyst
BAFO	Best and final offer
CAB	Change Control/Approval Board
CCP	Change Control Process
CR	Change Request
CUT	Code and unit test
DA	Detailed Analysis (in particular in the context of change requests)
EAI	Enterprise Application Integration Project
EDS	Enterprise Data Store
ER	Elaboration Request
FPM	Fixed Price Model(ling)
FRG	Flexible Reporting Group
IAP	Initiation & Analysis Phase
IA	Impact Assessment (in particular in the context of change requests)
LSO	Local sorting (or sales) office
MDL	Master Data Library
NFR	Non-functional requirement
PHS	Prepare & Hold Sight
PID	Project initiation document
PR	Process Requirement
RAG	RED AMBER GREEN
RDD	Requirements Definition Document
RoMgt	Rolling Management
SACs	The South African countries: Botswana, Namibia & South Africa.
SAN	Storage Area Network
SCMS	Supply Chain Management System
SKU	Stock Holding Unit
SME	Subject Matter Expert
SOA	Service Oriented Architecture
UAT	User Acceptance Testing
UI	User interface
WAN	Wide Area Network
Agile development	An approach to software development that features a less formal description of the client's requirements at the outset, with the software being developed through a high level of interaction between the supplier and customer.
Iterative development	An approach to software development that involves the documenting of some requirements at the start of the project with development taking place through an "iterative" process of production of developing software and feedback from the client in ongoing cycles.
Waterfall	The classical software development method: an approach where all requirements are expected to be ascertained to a low level of detail before any development effort takes place.

The witnesses who were called at the trial

22. It is convenient at this point to introduce the witnesses of fact (although in reality many of them were experts in their field), and the two experts, who were called at the trial and to give my brief impressions of them as witnesses. By way of a general observation, there was no-one who really had any very clear memory of any of the many messages, meetings or conversations referred to in the documents to which he or she was taken. This is hardly surprising given that the relevant events occurred 2½-3½ years ago and at a time when each of them was very busy.
23. As with many commercial disputes, therefore, it is the contemporaneous documents that tell the most reliable story, particularly those e-mails or minutes of meetings where there was little likelihood of their being composed for the benefit of posterity. It is upon the contents of these documents that I shall base the majority of my findings of fact.

Mr McKendrick

24. Mr Bob McKendrick was the IT Development and Demand Manager of De Beers UK Ltd between about 2005 and when he left the company on 30 June 2009, having been made redundant along with many others following the downturn in the diamond market following the global recession in 2008. He had been in the IT department at DB since he joined the company in 1986. By way of background he is an IT professional specialising in applications development and delivery.
25. He had the day to day responsibility for overseeing the Aggregation Project from a technical delivery standpoint. He reported to and worked closely with Jeremy Newell, who was then the Director of IT and Programmes. He had made two witness statements for the purposes of the proceedings. The first was a very lengthy statement running to 115 pages and over 400 paragraphs; the second was a shorter statement made in response to witness statements served on behalf of Atos, which ran to some 30 pages and over 60 paragraphs. His first witness statement took the form of a chronological commentary on the documents and was really too lengthy and detailed to provide a digestible statement of his evidence. Witness statements in this form have frequently been the subject of criticism by the courts, but I am reluctant to be over critical in this case because I can readily understand the difficulty of presenting his evidence in this case in any other form. He was cross-examined over a period of 2½ days and so the most relevant parts of his evidence were both given and tested during that time. I have had the benefit of having a daily transcript of the evidence.
26. Given his role, it would be surprising if Mr McKendrick did not have a strong emotional interest in the outcome of this litigation even though it is now over 15 months since he left the company. However, whilst there were passages in his witness statement that were plainly the product of reconstruction, rather than accurate recollection, I found him on the whole to be a careful and truthful witness. Where errors in his witness statement were pointed out to him in cross examination, he was generally ready to agree that this was so without any prevarication. I find that the principal issue which arises out of his evidence is the extent to which he (or others within DB) told the Atos representatives of the extent of the lack of confidence which he said that DB had in Atos's performance and lack of understanding of the diamond handling processes that went on within the DB supply chain, particularly during the Initiation and Analysis Phase.
27. This is neatly summarised in the following passage during Mr McKendrick's lengthy but well directed cross-examination by Mr Christopher Lewis, who, together with Mr Peter Land, represented Atos. On 7 October 2010 Mr Lewis was asking Mr McKendrick about a "lessons learned" document that was prepared by DB after the termination of the contract:

Q. "Atos assumed that high level requirements would give them enough information to understand business complexity", and they were wrong about that, weren't they?

A. Yes.

Q. And De Beers knew that at the time, didn't they?

A. They knew it to a degree and flagged it.

Q. We differ, Mr McKendrick, on whether it was flagged or not. That wasn't my question.

MR JUSTICE EDWARDS-STUART: Well, just put your question again, Mr Lewis, because you said "At the time". Precisely what time are you talking about?

MR LEWIS: At the end of the initiation and analysis phase, at the end of August 2007 and the beginning of September 2007.

A. There were concerns still within the business as to whether or not Atos had fully understood the depth of requirements. There were reassurances from Atos that they indeed had understood fully the requirements.

Q. But that was because they assumed that the high level requirements would give them enough information to understand that complexity?

A. But that is a failing, surely, on Atos' behalf, not De Beers.

Q. Who knew how complex the business processes were?

A. De Beers.

Q. So if they knew that Atos was misunderstanding that, why didn't they tell them?

A. But I think they did.

Q. That's where we differ.

28. Whilst he was generally familiar with the aggregation process, it emerged, perhaps unsurprisingly, that he did not have a detailed knowledge of every step in the process.

Mr Newell

29. Mr Jeremy Newell was the Director of IT and Programmes at DB at the relevant time. He was responsible for running DB's IT department whilst also having responsibility for managing its business transformation programme. He was a member of DB's Executive Committee and he reported directly to Ms Varda Shrine, the Managing Director. He joined DB in September 2006, prior to which he had held a number of senior IT professional positions in other companies.
30. Although Mr Newell was not dealing with the project on a day to day basis, his office was close to that of Mr McKendrick and they probably discussed the project several times most days.
31. I found Mr Newell generally to be a defensive and unforthcoming witness. There were occasions on which his evidence strained credulity. The most glaring example of this was given by one conflict between a passage in his witness statement in which he expressed views about Atos's competence and what he said in an Executive Committee meeting about six weeks later. In evidence he said this during cross-examination:

Q. And your point here was that if Atos was only just starting to understand that, that was Atos' own fault?

A. Correct.

Q. Because their original requirements gathering exercise hadn't been good enough?

A. That's what I am saying here.

Q. And so you are really questioning the competence of Atos' original requirements gathering exercise?

A. And ongoing.

32. The following day Mr Newell was asked about the minutes of an Executive Committee meeting held on 3 April 2008 (Mr Newell had been sent a draft of these minutes a few days later on which he had made some minor corrections). The minutes recorded Mr Newell has having said this:

"He commented that the issues with the delay from Atos does [sic] not lie with their competence but with the project elaboration process - moving from the concept to delivery phase where, invariably, suppliers to DTC realise that they have under-estimated the complexity of DTC business processes and the uniqueness of our environment."

33. Mr Newell told the court that at the time of this meeting it was still his view that Atos had not been competent at capturing DTC's requirements. He explained the apparently contradictory statement recorded in the minutes by saying that he wanted to give his colleagues an impression of confidence in the programme and that it was being managed properly. The most he would concede was that the view he gave to the Executive Committee was "subtly different" to his own view at the time.
34. Faced with evidence of this sort, and other less glaring examples, I find myself reluctant to rely on evidence given by Mr Newell that does not accord with the relevant contemporaneous documents unless it appears consistent with the prevailing state of affairs at the time. It seemed to me that when he was giving evidence he was often at pains to commit himself as little as possible to any particular position.

Mr Aythora

35. Mr Jatin Aythora was employed by DB as a Technical Solutions Architect. He joined the company in February 2005 with some eight years of experience in the IT industry. For the five years prior to joining DTC he had been employed by a company called Kudos Communication in the UK during which time he had been involved in a project involving service oriented architecture ("SOA"). On that project he had been a programmer but had also carried out system design. Before his employment with Kudos he had worked for a software consultancy in India.
36. Mr Aythora came across as a confident witness who held firm views about software design. He told the court that he had written two papers at an early stage in this project for the guidance of Atos. The first was "Domain Model for SOA: Realising the Business Benefit of Service Oriented Architecture" and the second was "DTC Enterprise Architecture". In relation to the latter document Mr Aythora said this, in paragraph 9 of his witness statement:

"I also wrote a document called "DTC Enterprise Architecture" which contains a description of how technology would be used to support the mission and business of DTC's entire organisation. It sets out how DTC's "vision" (as referred to in paragraphs 6 and 8 above) could be achieved by developing a number of new systems in order to support the business. The document contained key information about what DTC wanted to achieve from a technical perspective. It covered all architectural components and outlined DTC's standards and policies. It also outlined DTC's expectations. I first started developing the document in July 2006. On 4 April 2007, DTC gave the document to a number of its key suppliers to be used as a set of standards and a benchmark for them to build solutions on. I continued to amend and update the document until 28 November 2007."

37. It transpired that this document had been largely lifted, in many places word for word, from the National Institute of Health enterprise architecture, a document which had been last updated on 16 May 2007, although first written several years earlier.
38. By the same token, Mr Aythora's "Domain Model for SOA" turned out to have been lifted, almost entirely word for word, from a white paper prepared by BEA called "Domain Model for SOA Realising the Business Benefit of Service Oriented Architecture". BEA Systems describes itself as a world leader in enterprise infrastructure software and in providing standards-based platforms to accelerate the secure flow of information and services. Mr Aythora said that this document was in effect an industry standard. When asked earlier how he had gone about preparing his document, he said that it was based on his research on service oriented architecture. He was then asked what research he had done, to which he replied that there were various sources on the internet and named two sources in particular, neither of which was BEA.
39. Whilst I do not find that Mr Aythora said anything about these documents that was actually untrue, the impression given by his witness statement was that they were substantially the product of his own work. In fact, they consisted of little more than wholesale copying of other materials, which were then altered slightly to make it appear that they had been specifically written for DTC.
40. However, it is clear that Mr Aythora took a very close and critical interest in what Atos was doing. He was not slow to challenge Atos about its approach if it did not appear to conform with his notions of what ought to be done and, as events showed, arguably too much so.

Mr Page

41. Mr Michael Page has been the Finance Director of DTC since July 2004. With one particular exception his evidence was largely uncontroversial. At paragraph 41 of his witness statement Mr Page stated:

"The SCMS Project remains essential for DTC's business and DTC fully intends to implement it so that it is operational within the next 2 to 3 years (bearing in mind that the Project and its implementation may take about 18 months itself)."

42. Mr Page said also that in the fourth quarter of 2008 the diamond market ground to a standstill. As a result the move of the aggregation project to Botswana was postponed because of the state of the economy. It was not until July 2009 that DB was able to release a press statement reconfirming its intention to relocate the aggregation function to Botswana and announcing that relocation would take place by the fourth quarter of 2010. Mr Page agreed that by that time DB was sufficiently far out of the recession to restart the project. However, the documents showed that there was another reason which prevented the move from going ahead. The relevant documents which showed this to be the case had been heavily redacted on disclosure so as not to reveal what this reason was. I was told that it was something confidential and highly sensitive. It was referred to in evidence as the "blank" issue and so I shall adopt the same expression in this judgment.
43. In paragraph 39 of his witness statement Mr Page said this:

"DTC intends to recommence the aggregation project from where it left off. Unfortunately DTC is unable to predict with authority when this will be because although the market has improved, the economy is such that decision on timing cannot yet be finalised. But it is very likely that the process of moving aggregation to Botswana will commence in the first quarter of next year, 2011."

After Mr Page had been taken by Mr Lewis through the relevant documents about the "blank" issue, there was the following exchange (Day 6, 109/11 - 110/9):

"Q. Now, that can't be, can it, Mr Page, a fair representation of the reasons why there have been further delays to moving aggregation?

A. At the time that this witness statement was made, the issue which was causing the particular blockage had not at that stage developed to an extent that it appeared that it was going to be a serious ongoing problem. It was - I certainly felt that it was, an issue that was capable of resolution, and certainly in May of 2009 we were by no means out of the woods in terms of the effects of the recession. Our Sales had by no means recovered to anything like previous levels.

Q. Why do you say May 2009?

A. Because that's when the witness statement was made. No?

Q. No, it wasn't, Mr Page. Look at the last page.

A. Ah, my error, I apologise.

Q. It's a pretty significant error, isn't it, Mr Page? Because we have just seen the chronology going through, that the issue that was holding things up through late 2009 into early 2010 was the blank issue. So you must have known that it was that that was holding things up, and not the recession, when you made this witness statement in May 2010?

A. Well, I was suddenly aware of it, yes, of course I was.

A little later, there was the following exchange:

"Q. The real reason why you were not recommencing the aggregation project was the blank issue, wasn't it?

A. That remains a serious obstacle today."

44. The first answer given by Mr Page in the above exchanges was indeed a surprising answer. In direct contrast to what had been said in his witness statement, Mr Page was forced to concede that the issue which was holding up the relocation of the aggregation project was not the recession, but the confidential "blank" issue to which I have already referred.
45. Mr Page was then questioned about whether there was any budget for the renewal of the SCMS project and whether he had seen a single piece of paper indicating a plan to start that work within the next 12 months or so. He accepted that there was neither.
46. In the end, it became abundantly clear that, as at May 2010 when Mr Page made his witness statement, there was no prospect whatever of the SCMS project becoming operational within the next 2 to 3 years. Since, as Mr Lewis pointed out in cross examination, Mr Page had said that implementation of the project would take about 18 months, it would have to start between November 2010 and November 2011 in order to achieve completion within 2 to 3 years. Given that at the time of the trial (October 2010) there is not a single piece of evidence to suggest that DB proposes to resurrect this project in the near future, Mr Page's evidence on this aspect in his witness statement was at best an extreme case of wishful thinking and, at worst, simply untrue. At a later stage of this judgment I will deal with the repercussions of this on the question of damages.

Mr Culshaw

47. Mr Simon Culshaw was the first witness called on behalf of Atos. He is currently the Head of Private Sector Systems Integration at Atos, but at the time of this project he was the Delivery Director. He has worked in the IT industry for over 17 years.
48. On the whole I found Mr Culshaw to be a candid and truthful witness. Indeed, his veracity was not really challenged at any point during his cross examination. However, his recollection of the precise sequence of events was not always good and his evidence was effectively confined to commenting on the contents of the contemporaneous documents.
49. One aspect of his evidence which I did find surprising concerned the Atos counterclaim, for the preparation of which Mr Culshaw was responsible. He was cross-examined about a claim in the schedule where it was alleged that between September and December 2007 (that is 3 months, as he confirmed) the two Atos Business Analysts, Mr Adelman and Mr Figoni, had wasted more than 50% of their time as a result of the non-availability of key DB personnel. Mr Culshaw said that he was not aware of this at the time and that the estimate has been based on what he was told later. I have to say that I find it extraordinary that the two business analysts could have had 50% of their time wasted over a three month period without there being any contemporaneous report of it, or that Mr Culshaw, as Delivery Director, did not know about it. In the light of the view that I had formed generally of Mr Culshaw as a witness, I was surprised and a little troubled that he had been prepared to support such an improbable claim.

Mr Adelman

50. Mr Ralph Adelman was the Lead Business Analyst on the Atos team. He has worked in the IT industry for over 40 years, initially as a programme designer and, from 1976, as a business analyst. I found Mr Adelman to be a truthful witness. He was particularly candid in relation to the Initiation and Analysis Phase, the programme for which he regarded as too short with the result that he expected that what Atos would produce during that period would be neither complete nor accurate.

Mr Cyril

51. Mr Frederick Cyril joined the project on 17 September 2007, initially as a process coordinator working with the Business Analysts team. He was a straightforward witness who was clear and articulate. His evidence was largely unchallenged.

Mr Cotter

52. Mr Joseph Cotter was Technical Architect on the project, which he joined in September 2007. He was an Enterprise Architect, that is to say that he was concerned with the larger issues relating to the design of the software rather than with detailed coding. He was not involved in the Initiation and Analysis Phase, but joined the project in September 2007.
53. Mr Cotter was a rather expansive witness, being rather inclined to treat any question as a prompt for a short speech on the topic in question instead of giving a direct answer. He made no secret of the fact that he held strong views on certain issues, and tended to be somewhat partisan in his approach. Where he gave evidence of fact, I did not consider that his evidence could always be relied on.

Mr Roberts

54. Mr Matt Roberts is a Design and Developer Lead within the Application and Life Management Practice at Atos. He was the development team lead responsible for both the UK and the India development teams on this project and he reported directly to the Project Manager. He had over 10 years experience of developing Microsoft applications in a commercial environment, and more recent experience as a team leader and project manager.
55. I found Mr Roberts to be an articulate and truthful witness and one on whose evidence I felt able to rely.

Mr Cunningham

56. Mr David Cunningham is a Principal Technical Architect with Atos. As a TA9, he was at the highest level of technical architect within the Atos structure. He has had over 40 years experience in the IT industry, and has been a technical architect for the last 15 years. It is clear that he is held in high regard within Atos in relation to IT matters. He was brought into the project in early May 2008 to assess the position in relation to the quality of the software and to make recommendations as to the way forward.
57. I found Mr Cunningham to be a careful witness whose evidence, in the event, was not really challenged. I accept it.

Miss Morgenstern

58. Miss Ursula Morgenstern is the Senior Vice President for Enterprise, Finance and Transport for Atos. She was promoted to this position in September 2007 having formerly been Head of Enterprise, Financial Services and Transport for Systems Integration. She joined Atos in 2002, when KPMG consulting was acquired by Atos. She has been in the IT industry for over 15 years, and was formerly a business analyst and project manager. As this brief career history indicates, she is clearly a person of drive and ability.
59. She became closely involved in the project towards the end of March 2008 when things had started to go badly wrong. Her immediate subordinate (at least, in the context of this project) was Mr Ieuan Jones who had become the Head of Enterprise, Financial Services and Transport in Systems Integration following her promotion. Reporting to Mr Jones was Mr Mike Isaacs, who had been brought in as a supernumerary project manager, effectively above the existing (but outgoing) project manager, Mr Ken McGuirk, (Mr Simon Culshaw also reported to Mr Isaacs).
60. Another person reporting directly to Miss Morgenstern was Mr Paul Bray, who in October 2007 took over as Head of Enterprise, Finance and Transport. In this role he assumed the responsibility for the delivery of this project in place of Miss Morgenstern.
61. It was clear from her evidence as a whole that Miss Morgenstern had few, if any, direct dealings with the members of the project team on the ground. Her information about what happened or had been happening on the ground was derived from her subordinates, in particular Mr Isaacs (Day 11, 106/17-19). This made her evidence in relation to what was happening in this project on the ground of somewhat limited value.
62. However, on matters in relation to which she was able to give direct evidence, for the most part I did not find her evidence to be of very great help. In fairness to her, I must record that although English was obviously not her mother tongue, her level of command and understanding of English appeared to be very high as one would expect of someone in her position. The main difficulty with her evidence was her occasional unwillingness or inability to answer a question directly and concisely. To illustrate the point I take the following passage from her evidence, when she was being cross examined about a letter which she had received from Mr Newell of DB on 5 June 2008. In the letter Mr Newell had said that the commercial proposal put forward by Atos on 2 June was being referred to DB's executive committee on 5 June (the day before the deadline imposed by Atos expired) and that he would respond to her more fully when the committee had considered the position; he then concluded the letter by saying that he saw no point in having a discussion the following day. The exchange was as follows:

Q So, what Mr Newell was saying is this is not necessarily the final word on the subject. Do you see that? The message from De Beers to Atos is that De Beers have yet to consider it at executive committee level and he will respond to you once the executive committee have considered it.

Now, if, Miss Morgenstern, you had been interested in doing a commercial deal and would have been prepared to negotiate a commercial deal and extend time to do so, then the natural thing for you to do then would be to extend the period of time before the suspension bites in to hear what the executive committee have to say, wouldn't it?

A. I must say I cannot recall my -- how I read that paragraph, or how I read that sentence. The only thing I recall from that time is that I assumed we would have talked again the day after and we would have got an understanding of what went on in the project board, so -- yes, I can see that that -- how that sentence reads, but I must admit I cannot remember how I read it because if I read it like that, somehow in my mind I'm saying: yes, they have accepted the position and they will tell us later on what they will do.

63. In addition, Miss Morgenstern was very keen to emphasise the fact, as she saw it, that right up until April and May 2008 DB was still changing its requirements. She would make this point insistently whenever a suitable opportunity presented itself. I felt that in this respect she was acting more as an advocate for Atos's case, rather than as a witness of fact. However, I did not find her to be in any way an untruthful witness and, when pressed, she was usually prepared to concede a point.

Mr Bray

64. Mr Paul Bray who was, as I have said, the Head of Enterprise, Finance and Transport, was the last factual witness called by Atos. I found him to be a candid and straightforward witness, who was willing to concede points against the interests of Atos if he felt that they were justified. In relation to those matters of which he had direct knowledge I found him to be a reliable witness.
65. However, like Miss Morgenstern, his knowledge of what was happening on the ground was largely, if not wholly, derived from others. His primary source of information was what he described as "high-level" information given to him by Mr Isaacs (Day 11, 130/19). So, in his case also, I found his evidence on the details of what was happening on the ground of relatively little value.

Dr Gifkins

66. Dr Michael Gifkins was called by DB. I have to say that I did not find his evidence particularly cogent, since many of his conclusions appeared to rest on very limited material. Whilst he wrote some long and detailed reports, it became clear during cross-examination that many of his conclusions were impressionistic, rather than being founded on careful analysis. His credibility was not helped by the fact that he reached few, if any, conclusions that were unfavourable to his client, DB, partly as a result of his firmly held view that the commercial risk under the Contract rested with Atos.

Dr Thomas

67. Dr Martyn Thomas was the expert called by Atos. On the whole I found him to be an impressive witness, although there were two or three occasions in his oral evidence when I thought that he came a little close to espousing his client's cause rather too enthusiastically. However, unlike Dr Gifkins, he was prepared to reach conclusions on particular issues that were adverse to the case of the party instructing him.

The decision to have new software

68. In March 2007 DB's Executive Committee decided to engage the services of an external IT supplier to design and deliver the software for the aggregation and EAI projects. At that stage the projects were to be put out to tender separately. Atos put in its initial response to the request for proposal in relation to aggregation on 30 April 2007 and, in relation to EAI, on 4 May 2007.
69. However, subsequently (probably in early April 2007 - the evidence is not very clear on this), the EAI Project was integrated with the aggregation project, and the resultant project became known as the Supply Chain Management System ("SCMS").
70. The upshot of the tender process was that four suppliers put in bids, or rather Best and Final Offers ("BAFOs"), for the combined project. Atos was the successful tenderer. It submitted its BAFO in the sum of £2,965,868 on 1 June 2007.
71. As a result of the ensuing discussions between DB and Atos it was agreed that, before the SCMS contract was finally let, Atos would be retained under a separate agreement to carry out the Initiation and Analysis Phase ("IAP"). The formal instruction for this was in a letter from DB dated 11 July 2007. The work was to be carried out between 25 June and 17 August 2007. The services to be provided included the preparation of Requirements Definition Documents ("RDDs") for the business functions specified, together with high level design for both parts of the project. More significantly, the IAP gave Atos the opportunity to appraise the project generally before finally committing itself to a price for the main contract. It was intended that the requirements would be captured down to detailed analysis level (according to Mr Adelman).

The Initiation and Analysis Phase

72. Unfortunately, the IAP was not a great success. The outcome was that the business requirements were captured at a high level only and were necessarily incomplete as a result. The reason why the IAP did not achieve its aims is not a matter for decision in this judgment. However, very shortly it seems that there were two main problems: first, Atos did not allow sufficient time or resources to achieve what was required and, second, DB's business users did not know exactly what they wanted and so the workshops that were set up to enable Atos's business analysts to identify the requirements turned out to be unstructured discussion groups in which much time seems to have been spent by the DB users in trying to establish what they required as well as identifying to the Atos business analysts what those requirements were to be.
73. One particular aspect of the IAP was that the DB business users reported that they were unimpressed by the Atos team. Since none of the DB business users who attended these workshops gave evidence, it remains unclear precisely what grounds formed the basis of the criticisms of Atos. In one sense, it probably does not matter because the perception, whether justified or not, is what was relevant so far as the relationship between the parties on the ground was concerned.
74. At an early stage during the IAP DB decided to retain KPMG to keep a watching brief. On 20 August 2007 KPMG produced a report which concluded, amongst other things, that Atos was not sufficiently proactive and was responding to major issues only after they had been flagged up by DB. A few days later, on 24 August 2007, DB gave a presentation to members of the Atos senior management at which the perceived weaknesses in Atos's performance were set out. In particular, in separate notes that were sent to Atos later the same day, specific criticisms were made of certain members of the Atos team, including the project manager, Mr Wong, the lead business analyst, Mr Adelman, and the technical architect, Mr Connor. A rather surprising aspect of this was that the criticisms of, at least, Mr Adelman were never fed back to him. I regard this as a failure by the management within the Atos team: it was certainly not for De Beers to pass on these criticisms, as Mr Culshaw agreed. When Mr Adelman gave evidence he said that he had no idea that these criticisms have been made, although he could understand why it was that the DB business users may not have been satisfied with the outcome of the workshops.
75. However, steps were taken by Atos to remedy the situation as described to them. Mr Wong, the project manager, was replaced by Mr McGuirk in October or November; during September a more senior architect, Mr Cotter, was brought in to reinforce the design side, and a workshop/requirements process facilitator was brought in, Mr Cyril. In addition, an EAI designer, Mr Cowell, and a Programme Director, Mr Noon, were also added to the team at around the same time. Mr Adelman remained in post, but a third business analyst, Mr Brown, joined the team in September.
76. In practice, the IAP continued beyond the original end date of 17 August and effectively ran on into October 2007 and merged with the start of the work under the main Contract.

The course of the work under the Contract

1 October to 31 December 2007

77. Between October and the end of December 2007 the work under the Contract got off to a slow start. The identification of slippage in the provision and gathering of functional requirements first appeared in an Atos internal Project Status Report dated 7 November 2007. The summary in this report recorded that five requirement areas had some form of delay, but this was said to have no impact on the next iteration schedule. One process requirement ("PR"), Container Management, was in delay and this was said to have potential impact on the Phase 1 schedule and was therefore under investigation. It seems that in the case of that PR, and some of the others that had fallen behind, the delay was probably caused by a lack of decision information from the DB users.
78. A further report, covering the period 29 October to 9 November 2007 described the position in much the same terms. One issue identified was that information in relation to export for aggregation was missing from the users in the South African Countries ("SACs").
79. At a Project Steering Committee Meeting (this was a joint DB/Atos committee) held on 14 November 2007 the problem of the missing information from the SACs was raised again and a need to take action was identified. A further problem that was recorded was missing information in relation to finance requirements. However, it was noted that Mr McKendrick, of DB, was to be informed of "any future availability issues of staff that could affect the plan". This suggests that there was a problem with the availability of key DB users, although the latter was not being raised in very strong terms.
80. The Information Pack for the Steering Group Meeting to be held on 23 November 2007 showed the project to be in red status. It noted that the project was "Significantly behind schedule on 7 core requirement areas. Urgent action is being taken to push requirements through the development life cycle to make up lost ground". Six reasons were identified as to why the 7 requirement areas were behind schedule. Two of these referred to the lack or late provision of information from the DB business users, and one was the availability of DB staff. The other three reasons were matters that were primarily within Atos's control, such as activities taking longer than expected owing to complexity or the identification of new requirements that were "in scope" but which required further elaboration.
81. On 23 November 2007, Mr Mike Isaacs, who was then overseeing the management of the project on the Atos side, sent an e-mail to the project manager, Mr McGuirk, identifying the areas upon which the Atos team needed to focus. Whilst the e-mail is not inconsistent with the fact that delays were being caused by the lack of timely information from the DB users (for example, the opening words of the first paragraph were "if [DB] aren't delivering ensure you have KPMG on your side understanding the issues - e.g. if Jeremy can't control all the stakeholders required to deliver and approve the business requirements . . ." ), the principal focus of the message was on potential shortcomings within the Atos team and what steps should be taken to remedy them.
82. An Information Pack for a Steering Group Meeting on 12 December 2007 (which covered the period 12 - 23 November 2007) included the following extract in its Executive Summary:

"Significantly behind schedule on 7 core requirement areas due to:

• Identification of new requirements that are in scope but require further elaboration e.g. Container Management functional area

• Amendments to requirements still being advised by the business e.g. Export for Aggregation still not nailed down despite start in I1. SAC"

(My emphasis)

83. A further Information Pack for the Steering Group Meeting on 12 December 2007 (which covered the period 26 November to 7 December 20007) included the following extract in its Executive Summary:

"Further action needed to make the kind of productivity leap required including:

• Freezing all functional requirements by end of Jan 2008. (We are simply not getting requirements nailed down quickly enough. We must continue the rapid decision making workshops through New Year and this will require significant business commitment - plans to be confirmed with Pat over the next few days)

• Streamlining development (already doing this where possible, but renewed focus required on building as much of the detailed specification alongside the analysis is necessary)

• Further tuning of delivery approach in terms of design and delivery of "pipeline" vs "foundation" processes. This may include bringing some AOI resource on-shore. (Visas /Space etc will need consideration)

• Revision of the Plan in line with the activities above and further review to identify any additional actions.

Non-functional requirements still RED status, but progress is being made and expectation is that workshop today will drive finalisation.

Splitting Process has been had assessed and it is clear that this will be a significant project in its own right. Impact Assessment expected at the end of this week for review."

(My emphasis)

84. I think that the reference to "business commitment" in the passage emphasised refers to commitment by DB business users (because "Pat" is a reference to DB's Pat Meredith). Although in cross examination Mr Culshaw said that availability of resources was not seen as a key issue or risk by 12 December 2007 (Day 8, 74/12-21), if one goes through the table in the report that sets out the details of the activities during the period under review and progress achieved, it can be seen that there are several items where the reason for the delay is given as something for which DB is responsible. For example, against Valuation Requirements it is noted that "DTC/AO resource availability. DTC Resource availability is the knock on effect from delays in completing other RDDs. Also AO new starter and staff sickness". This suggests as well that there was a problem with resource availability on Atos's part also. In relation to matters for which DB was responsible, examples are PR 6, Export for Aggregation, where the entry for DTC action reads "TR to provide documentation requirements for SACs (originally requested early August) - 20/11 (to ensure 16(3) delivery) (OVERDUE) Now due following workshops in week commencing 10/12", and PRs 41-44, where the entry for the reason for delay reads "Delayed start through DTC decision on MDL/Data Warehouse causing subsequent delay. No overall impact that needs monitoring". However, there are many entries where the essential action is shown as being due from Atos. On the basis of this document alone it is not possible to infer the relative importance, in terms of either delay to the project as a whole or cost, of the matters for which DB was responsible as against the matters for which Atos was responsible.
85. On 10 December 2007 there was a quality gate meeting in respect of the Container Management processes (PRs 49-52, and 55) at which it was concluded that the system testing had been passed. This was the completion of system testing for Phase 1, which was Key Milestone 2 and triggered the second stage payment under the contract. Although DB's case as pleaded and opened was that Milestones 1, 2 and 3 had not been fully completed, by the end of the evidence it was not seriously disputed that Milestone 2 was successfully achieved on 10 December 2007. Indeed, in its closing submissions DB said that the debate as to "whether Milestones 2 and 3 had been met do not matter".
86. At about the same time Atos had begun to realise that it would no longer be possible to deliver the software using an iterative approach as had been the original intention. It resolved, and agreed with DB at a meeting held on 18 December 2007, that delivery would be in the form of a "Big Bang" at the end of June 2008, which meant adopting a waterfall approach to the delivery of the software. In order to achieve this it was decided that Atos would capture all DB's business requirements by early February 2008 through a series of "fast track requirements gathering workshops" during January and February 2008.
87. On 2 January 2008 Atos gave a presentation for the induction of six new business analysts who had been brought in to strengthen the team. The organisation chart contained in the presentation shows that there were already three business analysts in the team, in addition to Mr Adelman, so this brought the number of business analysts on the Atos side up to 10. The presentation was largely explanatory and gives very little indication of the reasons for the delay that had resulted in the need for so many additional business analysts.
88. The witness statements also provide fairly limited insight as to what was causing the delay to the project during this period. Mr Adelman's statement contained the following passages:

"81. A significant issue that impacted the project was the fact that the DTC resources were time constrained or unavailable. Mike Smith, Geoff Tomkins and Steve Isted were the "business experts" who had the detailed knowledge of the application process, however they were often engaged with their day-to-day roles and as such were unable to commit sufficient time to the project. Mike and Geoff were originally not part of the project team. Geoff had detailed knowledge of the diamond handling processes and more significantly the data that was used to enable and control these processes. Mike Smith was the only person with a complete view of the existing systems as well as detailed knowledge of the legacy systems.

82. Steve Isted was often simply unavailable to attend meetings and as a consequence some meetings had to be cancelled.

83. . . .

84. Mike Large resigned from DTC or around the middle of September 2007. Mike Large had previously worked in the DTC business and understood the processes well, he was also a very enthusiastic and hard-working member of the analysis team. This meant that when he resigned there was a gap in both knowledge and effort."

89. Whilst these passages make it reasonably clear that the unavailability of key personnel within DB caused Atos difficulties, as one would expect, it really provides no indication at all of the extent of the difficulties which this presented, still less the amount of delay or time wasted as a result. In relation to some issues Mr Adelman gave an estimate of the additional time that he considered that he had spent on them because of the alleged failings of DB either to provide information or to decide what they wanted. However, he did not do so in the case of Atos's complaint about the lack of availability of DB key personnel, either in his statement or in evidence.
90. The only evidence about the amount of time wasted by the unavailability of key DB personnel was given by Mr Culshaw, but he accepted that his estimate, prepared in March 2008, was based on what he was told by others - because there were no timesheets that provided details of the work that any particular person was doing at a particular time (beyond identifying the project on which he or she was working - see Day 8, 93/11-15) - and that he was unaware of the extent of the problem at the time (Day 8, 100/17 - 101/21).
91. The witness statement of Mr Cyril, who joined the project on 17 September 2007, contained the following passages:

"9. Around the middle of December 2007, I recall that Atos was becoming increasingly aware that the task of capturing requirements could not be undertaken only by the two BA's and I was therefore asked by Simon Culshaw and Ken McGuirk to assume the role of Team Lead for the requirements team.

10. . . .

11. Broadly my role consisted of: managing the BA team resources and allocation of project tasks; facilitating team meetings; inducting new members of the team; updating and monitoring the BA aspects of the project plan; coordinating the compiling project status information in respect of the BA team for input into documents such as the Steering Committee Packs and reporting to Ken McGuirk, the Atos Project Manager.

12. In an internal meeting that took place before Christmas 2007 with Ken McGuirk, Simon Culshaw and myself, we discussed the fact that the requirements gathering exercise was not progressing as well as it should have been due to the fact that DTC had still not finalised its business requirements and it had not fully scoped what the new system needed to be able to deliver. At this meeting, I suggested a change in approach and proposed that we suggest to DTC that both parties commit to a focused process and period in which to ensure that all requirements were captured in one go."

92. Whilst in these paragraphs Mr Cyril clearly raises the issue of DB's failure to finalise its requirements, he says nothing about difficulties being caused by the lack of availability of key DB personnel. The reason for this is probably that he did not assume the role of the leader of the business analysts until early December 2007 (see Day 9 86/3-7). He accepted in evidence that the discussion to which he referred to paragraph 9 of his statement probably took place at a meeting in early December. Again, as with Mr Adelman's statement, these passages provide little indication of the extent of the delay caused by the matters raised or the additional cost to Atos.
93. In his witness statement Mr Roberts, who was the development team lead on this project, said, at paragraph 12:

"It is my recollection that Atos had allocated time and resources to attempt to capture the NFRs, however they were hindered by the fact that the DTC business team were too busy on other issues to be able to address this issue properly. The problem of capturing the requirements was made worse by the fact that a number of key users and other information that DTC was requesting from its business units across Africa was not fixed. It is my understanding that because of these issues that DTC took the decision to capture the NFR requirements itself."

94. NFRs are non-functional requirements. These can generally be described as consequences of the functional requirements. For example, the number of users who need access to a particular system or the bandwidth required, are non-functional requirements. Functional requirements, by contrast, are the business processes themselves: in other words, what the operatives actually do on the ground during the application process are functional requirements. During the period under consideration in this part of the judgment, October to December 2007, the business analysts were concentrating primarily on establishing the functional requirements. In general, identification of the non-functional requirements followed this. It is therefore not clear from paragraph 12 of Mr Roberts's statement, to what period he is referring but it is unlikely that it was much before December 2007.
95. It is apparent from this summary that neither the evidence nor the documents provide a very clear explanation of why it was that the project fell behind during this period or any reliable evidence as to the amount of time wasted by the unavailability of key DB personnel. As to the causes of delay, four reasons appear to be the most likely. First, Atos did not have enough business analysts working on the requirements gathering exercise (and, to a lesser extent, the same may have been true on DB's side). Initially, during the IAP, DB had had two business analysts working with the Atos BA team: Suzie Law and Mike Large. Mr Adelman said that he had a good working relationship with Mike Large, but with Suzie Law it was "problematical" and not a good working relationship (Day 9, 17/19-21). Unfortunately, Mr Large left the project in September 2007 and, after a short interval, was replaced by Mr Brown.
96. The second likely reason for the lack of progress was the unavailability of the relevant key personnel within DB. There is plenty of evidence to the effect that there were problems with DB staff attending workshops and generally being available to provide information. This was because many of the key people with knowledge of the business processes simply did not have the time to make themselves available. This was probably the result of a lack of direction from the senior management of DB, but - subject to one point - the precise reason for it probably does not matter. The one point is the possibility that the Atos business analysts did not give enough notice of when they wanted to see people or wanted them to attend meetings or workshops. Mr Culshaw accepted that this probably happened in some instances (see Day 8, 78/1-16).
97. The third likely reason is the extended time taken to establish DB's requirements because the complexity of the processes had not been fully appreciated at the outset by Atos. The fourth likely reason is that in certain areas DB had not made up its mind as to what it wanted.
98. Fortunately, it is not necessary for me to consider which of these causes of delay may have been dominant or critical because, as I will explain shortly, in early April 2008 DB agreed to a revision of the programme which put back the dates for delivery of the software. Although there was no express agreement to this effect, I find that this agreement effectively compromised any mutual claims for delay up to about the middle of March 2008.

The effect of the unavailability of key DB personnel up to 31 December 2007

99. At this point I propose to digress to consider Atos's claim in respect of the loss of time caused by the unavailability of DB's key staff during this period. Mr Culshaw prepared a quantum table, which set out, by reference to the various heads of claim being put forward by Atos, the time allegedly lost by Atos as a result of that particular head of claim. In relation to the failure to make available the key staff, Mr Culshaw's table showed that, between September and December 2007 (he said that "September to December" meant a three month period), 67 man days of business analyst time were lost. This was the time of Mr Adelman and Mr Figoni, and it was claimed that the former lost 33 man days and the latter 34 man days. This represented about 50% of their time over the three month period. As I have already noted, these estimates were prepared in March 2008 and represented, according to Mr Culshaw, the best recollections of Mr Adelman and Mr Figoni. However, as pointed out above, Mr Adelman gave no evidence in relation to the figure that related to him. Mr Figoni was not called as a witness. When he was being asked about the claim for the time wasted by the business analysts, which he had earlier described as a "high level estimate", Mr Culshaw said this (Day 8, 100/3-18):

MR JUSTICE EDWARDS-STUART: What percentage of Mr Adelman's time do you think was wasted in this way?

A. Quite a significant amount, from what I was told.

MR JUSTICE EDWARDS-STUART: Fifty per cent?

A. Yes.

MR JUSTICE EDWARDS-STUART: But that's an astonishing amount of time, just wasted?

A. I think it was a fairly large amount of time, yes.

MR JUSTICE EDWARDS-STUART: But surely if that had been the case, one would have seen that in emails week on week, wouldn't one? You wouldn't have tolerated, as the delivery director, having two chaps idle for 50 per cent of their time without making an almighty fuss about it, [would] you?

A. Well, I didn't make an almighty fuss about it, because I didn't know the extent of it at the time.

100. As I indicated during this passage, I find it very hard to accept that two business analysts could have lost 50% of their time during this three month period without Mr Culshaw, the development director for the project, being aware of it or there being any written complaint to DB about the enormous amount of time that was being wasted as a direct result of the non-availability of key staff. Passing references in reports or minutes of meetings to difficulties caused through the unavailability of key personnel are not, in my view, consistent with a loss of time on the scale claimed by Atos in respect of Mr Adelman and Mr Figoni during the last three months of 2007. Mr Culshaw accepted that this was an estimate made on the basis of information that he was given some months after the relevant period.
101. I am prepared to accept that some time must have been lost, because it is clear that DB did not make its key personnel available as it should have done and this must have caused some time to be wasted, but on the material before the court I cannot accept that for Mr Adelman and Mr Figoni it was anything like as high as 50% of their time during this period. I consider that a figure of 20% would be more consistent with the evidence as a whole. For the relevant period - the last 13 weeks of 2007 - this would amount to 26 man days for these two business analysts.
102. However, Atos's claim under this head during this period is not confined to the time of Mr Adelman and Mr Figoni. Time lost by other members of the Atos team, together with further time of Mr Adelman, is claimed as follows, but unfortunately in the case of these employees the claim is not divided between the years 2007 and 2008 (apart from 38 hours that fell exclusively in 2008, which I have excluded). I summarise the figures (man days) in the table below:

Name	Role (and activity)	Period	Time lost
Developers/Designers	Oct 07 - Jun 08	145	145

Mr Roberts	Development Manager	Oct 07 - Jun 08	30
Mr Gathercole	Designer	Oct 07 - Jun 08	15
Mr Cowell	Designer	Oct 07 - Jun 08	15
Mr Cotter	Enterprise Architect Workshops and meetings to discuss NFRs + chasing NFRs + rework for security and audit	Oct 07 - Jun 08	20
Mr Philpott	Senior Developer Ditto	Oct 07 - Jun 08	23
Mr Cowell	Senior Developer Ditto	Oct 07 - Jun 08	14
Mr Gathercole	Senior Developer Ditto	Oct 07 - Jun 08	13
Mr Adelman	Business Analyst Ditto	Nov 07 - Jun 08	3
Mr Brown	Business Analyst Ditto	Nov 07 - Jun 08	7
Mr Cowell	Lead Designer Re-design	Nov 07 - Jun 08	5
Mr Gathercole	Lead Designer Ditto	Nov 07- Apr 08	5
Mr Lally	Senior Developer Recode	Nov 07- Apr 08	20
Mr Adelman	Business Analyst Workshops, meetings, chasing requirements	Nov 07 - Jun 08	5
Mr Adelman	Business Analyst Workshops, meetings, chasing requirements	Nov 07 - Jun 08	8
		Total:	328

103. If the above figures are simply adjusted pro rata to cover that part of the period that fell within 2007, and excluding Mr Adelman (because I have already concluded that his time lost would not have exceeded 13 hours during this period) the figures would become:

Name	Role	Period	Time lost
Developers/Designers	Oct - Dec 07	100	100

Mr Roberts	Development Manager	Oct - Dec 07	10
Mr Gathercole	Designer	Oct - Dec 07	5
Mr Cowell	Designer	Oct - Dec 07	5
Mr Cotter	Enterprise Architect Workshops and meetings to discuss NFRs + chasing NFRs + rework for security and audit	Oct - Dec 07	7
Mr Philpott	Senior Developer Ditto	Oct - Dec 07	8
Mr Cowell	Senior Developer Ditto	Oct - Dec 07	5
Mr Gathercole	Senior Developer Ditto	Oct - Dec 07	5
Mr Brown	Business Analyst Ditto	Oct - Dec 07	2
Mr Cowell	Lead Designer Re-design	Oct - Dec 07	2
Mr Gathercole	Lead Designer Ditto	Oct - Dec 07	2
Mr Lally	Senior Developer Recode	Oct - Dec 07	10
		Total:	161

104. Of those named in the table above who gave evidence, namely Mr Roberts and Mr Cotter, neither said anything in either his witness statement nor his oral evidence about the extent to which his time had been wasted by the unavailability of key DB personnel, whether in 2007 or at all.
105. When Mr Culshaw was being asked about the methodology used to put together his quantum table, albeit in the particular context of the claim in relation to view process requirements, he said this (at Day 8, 93/90 - 94/5):

A. Yes. So -- but I just want to try to be clear. The estimates that we put together just estimated "It will require this amount of additional work to do this requirement". The estimate wasn't then split down into "Well, that's already happened and that's still to come", it was just one estimate. What I --

MR JUSTICE EDWARDS-STUART: I see, so you didn't consider any particular individual or the hours any particular individual had spent, but you simply said the difference between case A and case B one would expect to involve X hours work?

A. Yes, that's correct.

106. Whilst I can understand that this could be one method of estimating the amount of additional work that a particular new requirement would have involved, it is not clear to me how this approach could be adopted in relation to estimating the time wasted as a result of the unavailability of DB employees, if indeed it was the approach adopted. It seems to me that the only way of putting together a claim in respect time wasted as a result of the unavailability of the relevant personnel would be either by reference to contemporaneous notes or timesheets or, possibly, by way of evidence from those involved as to how much of their time they thought had been wasted. In addition, it might, I suppose, be possible to lead evidence from certain witnesses by way of a sample, from which figures could be extrapolated to give an estimate of time wasted by other employees who were not called, but not even that has been done by Atos in this case. In any event, any such method of extrapolation runs the risk that it may include time that was lost or wasted through a lack of a proper understanding of DB's requirements.
107. Accordingly, I find that Atos's claim for time wasted by members of its team during this period (other than the two business analysts) has not been established to anything like the extent claimed. However, I am prepared to accept that time was lost by the Atos staff as a result of the non-availability of key employees of DB but, in the absence of any more cogent evidence, I am not prepared to find that it was more than about 20% of the time claimed, or about 32 man days for the members of staff other than Mr Adelman and Mr Figoni.
108. Consequently, any claim that Atos might have in respect of the unavailability of key DB personnel during this period would, in my judgment, be limited to the 26 days (in total) that I consider were probably wasted by Mr Adelman and Mr Figoni plus a further 32 days for the remainder of the Atos team, making 58 days in all.

1 January to 1 May 2008

109. The new year began with an intensive programme of fast track requirements gathering workshops which it was intended would be completed by 8 February 2008. An Atos internal progress report dated 5 February 2008 noted "Strong progress with Fast Track Requirements workshops. On target to get sign off of core functional areas by 8/2". DB appeared to share this view (as reflected in an e-mail from Mr Newell to Mr Culshaw dated 25 February 2008). However, the report continued:

"Build phase is not progressing to plan. [Atos India] have delivered a number of modules which are now in system test, but core pipeline process areas have not started due to a need to review technical architecture issues as a result of elaborated requirements. These must be resolved in order to provide a clear template to build the remaining pipeline processes. Action required now to build a communication pack for the client re causes of delay, options around a revised delivery timeline and propose commercial management of the implications."

110. On 19 February 2008 DB issued a document describing the Non-Functional Requirements for the SCMS project. However, there were still important requirements of all aspects of the project that remained unresolved. First, and a running sore for some time, were DB's undefined finance requirements. In addition, workshops on DB's invoice tracking requirements were still being held in mid March 2008. In an e-mail dated 18 March 2008 Mr McKendrick wrote "I think that the Impact Assessment will yield a hefty price tag - which to my mind Finance should stump up for if we determine that it is all necessary". DB's finance requirements were not resolved until well into April 2008, if then.
111. Second, was the addition of Splitting: although the parties had agreed to include Splitting as an additional deliverable under the contract, and a price of £415,000 had been agreed, by the end of March 2008 the formal Change Request had not been signed off and its impact was still under review. Third, were the requirements in relation to Large Stones, which still needed information from DB.
112. But one of the other major problems facing Atos in mid February 2008 was that the fast track requirements gathering workshops had thrown up many more process requirements than Atos had envisaged. Not only did this generate a lot of work by way of further development, but also Atos had begun to realise that it was likely to have an impact on the design of the technical architecture. As a result, both parties appreciated that this, together with the other outstanding matters that I have mentioned, was likely to put the present programme in jeopardy.
113. On 7 March 2008 Atos presented a revised plan to DB which showed delivery by 17 October 2008. The plan contained three fire breaks of one week each by way of contingency against overrun. The grounds put forward by Atos were that the elaborated requirements had revealed significantly more complex and intricate business processes than it had originally envisaged. Atos said that there had been a huge increase in overall scope because the original 65 PRs had risen to 128 PRs, or 106 PRs excluding Splitting. It was said also that there had been significant technical design changes that had resulted in the need to re-code various modules. In short, Atos was asserting that the combined effect of these changes was that it had "to fundamentally revisit" its design, build and test plans. During the discussions at this presentation it became clear that Splitting was a key module because it was on the critical path to completion.
114. DB was not prepared to accept this revised plan and so it subsequently asked Atos to separate the delivery of priority modules from the delivery of non-priority modules, which became known as bundles 2 and 3, respectively. What DB wanted was to have bundle 2 (the "Gold" bundle) delivered as close as possible to 30 June 2008.
115. Atos presented its revised plan on 28 March 2008. This focused solely on the Gold Bundle and showed a delivery date for that bundle of mid-August 2008. However, much of the contingency in the earlier plan had been removed and, in particular, the second phase of Splitting, which was effectively driving the end date, contained no contingency at all. In addition, there were 5 CRs needed for bundle 2 which had been approved for detailed analysis and which would have to be completed to fit in with the mid August delivery date if the plan was to be achieved. It was agreed that three outstanding CRs (Intelligent Scanning, Finance Requirements and Invoice Tracking) would not be included in bundle 2.
116. In an e-mail dated 1 April 2008 headed "Without Prejudice and Subject to Contract" Mr Newell told Atos that DB was prepared to accept the proposed revised plan for the delivery of the Gold bundle, saying that it was not ideal but that DB had little choice. DB made it clear that its acceptance of the revised plan was subject to the acceptability of the revised plan for bundle 3.
117. That revised plan was presented to DB by Atos on 4 April 2008. The delivery date for bundle 2 remained at mid August 2008 as before, but the delivery date for bundle 3 was pushed back to 27 October 2008. In presenting the plan Atos stated that "Although the plan contains some contingency in most modules the timeline for both Bundle 2 and Bundle 3 are challenging . . . Splitting does not contain any contingency in Part 2 of Bundle 2".
118. At about the same time, in early April 2008, DB engaged the services of an external consultant, Mr Casey Charlton, to review the quality of the software that had been developed to date by Atos. He did this in conjunction with Mr Aythora. Although Mr Charlton only arrived on 7 April, he and Mr Aythora very quickly produced a document entitled "SCMS Initial Architectural and Code Review" on 9 April 2008.
119. In his witness statement Mr Roberts said that the Atos team was told that Mr Charlton was a specialist in unit testing and that he had been recruited by DB to assist Atos and DB in this area. He said that DB had not given Atos any warning that it intended to carry out an architectural and code review and, as a result, he said that the report gave an unrepresentative and inaccurate view of the code base and the architecture, although he accepted that the work that Atos had undertaken by the date of the review was neither complete nor in a final state. He felt that DB, in carrying out this review without any prior consultation with Atos, broke a previously good relationship between the Atos development team and the DB technical team. His evidence about this finds some support in the comment made by Atos in its draft response to the Architectural and Code Review, dated 20 April 2008, that:

"The Atos Origin and development team is perplexed that such a review could have been commenced and initial results published with little reversion to the Atos Origin technical management and the Atos Origin Architect."

120. When Mr Aythora was asked about this, he said that he believed that he told the Atos team that Mr Charlton had been recruited to review the coding standards of the project. When asked whether that is what he now believed or what he actually remembered, he said that he did not remember saying that specifically but he said "that was the purpose of recruiting him, and that's what I believe I said". He did not agree that the involvement of Mr Charlton damaged the relationship between DB and Atos: he said that he believed that they had a very good relationship throughout the project (Day 6, 39/17 - 43/5).
121. Following the issue of the Architectural and Code Review there were various meetings between the Atos team and Mr Charlton and Mr Aythora. Mr Roberts said in his witness statement that he had hoped that in these meetings they would have understood further the points being made and could have attempted to counter them in a non-aggressive manner. However he said that Mr Charlton held "dogmatic and immovable views" on many of the points raised within the document and was either unable or unwilling to understand the position put forward by the Atos designers and developers. On this point, the evidence of Mr Roberts received some support from Dr Thomas, who, in a rather outspoken passage in his evidence, described Mr Charlton as a "polemicist for a particular style of system design" (Day 13, 123/3-4).
122. It was following these discussions that Atos prepared the draft response to which I have already referred. However they decided against sending the document to DB as it was felt that this was more likely to aggravate the situation rather than help it.
123. The Architectural and Code Review covered three main areas: the build process, the technical architecture and the code quality. Very broadly, the Atos response contended that the build process either met the DB guidelines or was on course to do so; agreed in general terms with the areas that needed to be addressed in respect of the technical architecture (but said that activities were already in hand to deal with these points); and disagreed with the observations about the code quality.
124. In cross examination Mr Roberts was shown the following extract from an e-mail that he sent on 14 April 2008 to Mr Charlton and Mr Aythora:

"The extremely ambitious plan is to have all of these elements implemented by COB Friday 18th April. There are a couple of things that have prompted this. There was a review from Casey around our code base. Many of his comments weren't far from the mark, but hopefully what we produce next week will be a bit closer to what we expect to deliver. The second point which is more important to me is that we need to get all the devs [developers] up and running and I believe if we can create something as a template will start producing output relatively quickly."

He explained that the phrase "his comments weren't far from the mark" was in fact pasted in from a document prepared by his colleague Mr Gathercole, and so the words were not his own. However, he went on to agree that code quality was an issue that Atos had not been hiding from, and that he accepted that Atos had not been meeting the code quality targets over the period between January and April 2008, but that that was a matter of which DB was well aware (Day 10, 77/3-9).

125. Another reason given by Mr Roberts as to why Atos did not send its draft response on the Architectural and Code Review to DB was that matters were being overtaken by events. Whilst the discussion about the Review was going on it had been decided to set up some workshops to deal with the question of the reference architecture. The term "reference architecture", as it was being used in this context, referred to a discrete sample of code that reflected the design decisions that had been taken to date. It was a very thin functional slice of code intended to show the technical, rather than the functional, decisions. In effect, Atos was being pressed to demonstrate that it could produce code of an appropriate quality that would meet the requirements of the contract.
126. On 24 April 2008 Mr Newell sent an e-mail to Mr Isaacs raising various concerns of DB about software quality, and in particular about the technical architecture/framework. Mr Newell suggested that it was essential for Atos "to embed improvements into the wider UK and AOI teams without delay if the rest of the project is to be delivered to quality and to plan". The reference to AOI was to Atos India.
127. The information pack for the Steering Group Meeting on 30 April 2008, which covered the period from 14-25 April 2008, recorded in the Executive Summary:

"• The delivery plan especially Bundle 2 remains high risk whilst the reference architecture remains un-finalised and the change baseline is still not complete

• Bundle 2 end date requires investigation to understand impact as a result of incorporating Gold required CRs and delay due to s/w architecture activity."

128. The reference to "delay due to s/w architecture activity" was a reference to the actions required in the light of the Architectural and Code Review. About six weeks or so before this, or perhaps a little earlier, Miss Morgenstern decided to become more closely involved with the progress of the project. She was very concerned about the dispute over the quality of the software - she said that it was something that she had not come across before on a project of this sort - and she felt that expert advice was required. She therefore called upon the services of one of Atos's most senior technical architects, Mr David Cunningham.
129. At this point it is probably helpful to jump forward a few weeks to the issue of Mr Cunningham's report on 22 May 2008. The report was entitled "The DTC Problem" and consisted of two pages. Whilst Mr Cunningham said in evidence that in some places in the report he exaggerated for effect, because the report was intended for internal distribution only, he did not seek to resile from the thrust of any of the comments or criticisms contained in the report. I set out below the relevant extracts from it:

"DTC was originally intended to be developed agile-style. To this end, the team was organised into BAs who would define the requirement, and then a pool of devs who would be organised into teams to build elements of the solution incrementally, with the project beyond the requirements definition set up SCRUM-style; all supported by an architect and a few key designer/devs. This is all very DSDM as an approach, and can work fine in the right context, and of course with the right customer.

It became apparent that this wasn't going to work. This is for several reasons.

• The application is much larger than was originally thought, in terms of function points.
• The application is much more integrated and complex than was originally thought: a huge end-to-end multi-country workflow, with many of the same business concepts and sub-processes popping up at many points in the workflow and many "wrinkles" in the detail of the processes..
• At contract signature the requirements were high-level. Detailed requirements were defined in January 2008 and signed off in February, and only then were the maintainability and extensibility requirements expressed in PR69/71 apparent..
• The customer is demanding, particularly on the technical side, and this did not fit well with an agile approach to build.

Accordingly the decision was taken to move towards a much more waterfall-style approach. However, this was not reflected in the team organisation, or in the definition of the artefacts to be produced. As soon as I arrived I observed that the build team organisation was still reflecting the BAs, being effectively divided into functional silos. This was not appropriate given the points above, and we have started "specialising" so as to be able to provide the specific system support such a large and complex system requires. So for example, we now have a dedicated workflow team building the patterns and mechanisms that will be needed by the functional developers so as to build on top of Windows Workflow Foundation. We are in the process of setting up a dedicated UI team to do the same for Smart Client Software Factory and Composite UI Application Block. And more of the same will certainly follow; I see the need to pull the BAs and devs into integrated teams.

However, the workflow work in particular (which is well under way) has exposed a massive gap. We have signed-off business functional requirements, courtesy of the BAs. We have a team of devs ready to build to those requirements. We have a number of architects and key designers busily defining how the devs are to build the system (defining the architecture, that is to say). But we have no definition of what system is to be built: how the workflows in the various functional areas interact, exactly what behaviour in each functional area is to be allocated to the client and what to the server, exactly what messages are passed between client and server, and so on.

In short, what is missing is systems analysis. This seems to be something of a lost art (within Atos Origin at any rate), and I am at a loss to understand why. To build a system of this size and complexity it is an essential activity, and doing it now will undoubtedly pay for itself in the long term and address many painful risks. But of course, it casts the current plan into outer darkness and will undoubtedly go down like a bucket of cold sick with DTC. Note also that this will have implications for both sides of the V-model: testing as well as analysis.

. . .

What specifically do we have to do now? We need to create a Systems analysis team, combining perhaps two of the best BAs (we know who we want), an architect, and if possible a Systems analyst with manufacturing process experience . . . We need to re-plan to account for this team and activity. We need to plan for and start issuing analysis artefacts from this team as soon as possible in order to get the dev team is rolling (that it is, we don't have to do everything before we can do anything).

130. It is important to remember that this was effectively a report to the Project Manager, Mr Isaacs, and was not a document intended for eyes outside Atos and certainly not, I imagine, for production in court. I bear these points in mind, but the fact remains that on any reading the report discloses a project that was in considerable disarray from the design and development point of view. Mr Cunningham confirmed that his recommendations in the last paragraph from the extracts quoted above were based on the analysis and thinking recorded in the previous paragraph quoted. It is clear, therefore, that whilst it may be an exaggeration to describe the recommendations made by Mr Cunningham as ones that would cast "the current plan into outer darkness", the change in approach advocated by Mr Cunningham would cause some significant delay to the delivery date. It is not clear whether this delay was factored fully into the revised programme that was submitted at the end of May 2008, but I rather doubt it. In any event, the evidence as a whole suggested that the delay that would result from the implementation of Mr Cunningham's proposals might be measured in months rather than weeks (in an internal e-mail dated 22 May 2008, Mr Roberts said that once a systems analyst had been brought on board Atos would then need about another 2 months in order to complete the relevant work).
131. Reverting back to the narrative, in early April 2008 Atos commissioned an "in-flight Review", whose purpose was "to determine if the project management approaches being used is [sic] adequate to deliver the "Gold Bundle" on time and to budget, and to recommend changes where necessary". The report was based on interviews during the third week of April 2008 with the Project manager, Mr McGuirk, and three other key members of the Atos team. The report was fairly critical (although one must remember that it was intended for Atos eyes only) and noted that the latest plan assumed 100% efficiency (so that no one could take unplanned leave, go sick, etc), and a 30% increase in Atos India staff over the next 6 weeks. It noted also that at that stage there had been no "detailed independent review of software architecture, development methodology, coding standards etc" (that, of course, was the exercise that was about to be carried out by Mr Cunningham). The programme was described as a "VERY aggressive plan".
132. The findings stated that there was "hands off" interaction with the offshore development (Atos India) and that neither the project manager nor the test manager had visited India. It recorded that Atos India was reporting RED consistently. Whilst the report noted some shortcomings on DB side, such as a "lack of continuity of client involvement", the report did not reflect the extent of the difficulties that Atos were encountering with DB as subsequently described in the witness statements. However, that may be because the object of the report was to focus on Atos's performance, rather than the conditions under which it was operating.
133. On 21 April 2008 a Mr Dailey, of Atos, sent a copy of the In-flight Review to, amongst others, Miss Morgenstern. He described the short term actions that had been agreed as follows:

"• replacement for current project manager

• assignment of experienced software architect

• detailed review of existing plan to understand estimates behind various activities . . .

• review of development approach and quality of code being produced

. . .

Longer term action is to look at how to address contract management and the proficiency of DTC Programme Management"

134. Whilst the In-flight Review may have concentrated on the performance of the Atos team, it was clear that by early April 2008 the members of the Atos team were complaining internally about the "significantly more complex and intricate business process than originally envisaged", in that there were originally 65 PRs and that these had now increased to 128 PRs (or 106 excluding Spitting).
135. In evidence Mr Roberts agreed that, as late as May and into June, Atos India was still complaining about outstanding architecture decisions that had by then become critical (Day 10, 89/16-22).

The workflow engine

136. Another problem that had surfaced by the beginning of May 2008 was the question about the use of a workflow engine. A workflow engine, described crudely, is a tool which helps to configure the various steps in a system and which assists both in the development of the system itself and the running of the system once developed. Broadly speaking, the developers of the software can either write the workflow engine themselves as a bespoke system or use an off-the-shelf workflow engine, such as Microsoft Windows Workflow Foundation. A further possibility is for the developers to take an off-the-shelf workflow engine and modify it by adding code around it.
137. It was explained to me that for a fairly simple system it is often easier and cheaper to write one's own workflow, rather than use an off-the-shelf engine. Apparently this is fairly common in straightforward supply chain systems.
138. However, Schedule 2 to the contract (paragraph 2.3) specifically required Atos "to use Microsoft Workflow Foundation to create the workflow and process flows" of the system. Nevertheless, in November 2007 Atos brought in a Microsoft architect, Morgan Skinner, who was a workflow specialist, in order to advise it about whether or not to use an off-the-shelf workflow engine in the light of DTC's requirements as they were seen to be at the time. There was a meeting attended by a Mr David Cowell, an Atos workflow specialist, and Mr Skinner. Mr Roberts and Mr Aythora joined the meeting towards its end and were told that Mr Skinner had advised that an off-the-shelf workflow engine was not required. According to Mr Roberts, Mr Aythora agreed to this. Mr Aythora did not accept this: he said that, whilst he agreed that there was a recommendation that a workflow engine would not be required, that recommendation was acted upon by Atos without any approval of DB.
139. Mr Aythora's position, although not taken in his witness statements, was that by developing its own workflow engine Atos was taking a technical risk and adding unnecessary development work, thereby increasing the development effort and taking longer.
140. In fact the decision proved to be unfortunate because in about late February 2008, following the Fast Track Requirement Workshops held in January and February 2008, Atos realised that the extent of the complexity of the system meant that a workflow engine would need to be incorporated into the software architecture, so it decided to reverse the earlier decision and to use Windows Workflow Foundation.
141. On this issue, I prefer the evidence of Mr Roberts. I consider that Mr Aythora must have been aware at the time that as a result of the meeting in November 2007 Atos intended to write its own workflow engine contrary to the provision in Schedule 2. I find it unlikely in the extreme that Atos would have gone ahead with a decision to write its own workflow engine in breach of an express provision in the contract unless it thought that DB had agreed to this course. Even if, contrary to the evidence of Mr Roberts, Mr Aythora did not expressly agree to the course that Atos was proposing to take but, knowing what had been decided upon, simply decided to say nothing and to wait and see what happened - which is rather what his evidence suggested, I would conclude that DB must be taken to have waived any right to object to Atos taking that course.
142. Mr Roberts said in his witness statement, and I have no reason to doubt it, that the introduction of a workflow engine at this late stage in the project had a major impact on the development of the architecture of the system. In fact, the final decision to introduce a workflow engine was taken following the arrival of Mr Cunningham in May 2008 (see Day 10, 149/5).
143. However, I find that the fact remains that the reason for the late choice of workflow engine arose out of Atos's initial lack of understanding of the complexity of DB's processes. I am also inclined to think that Atos should probably have become aware of the need for a workflow engine rather sooner than it did, but the evidence does not enable me to reach a positive conclusion about this.

The events from 1 May 2008 up to the termination of the contract

144. On 2 May Mr Newell sent another e-mail to Mr Bray to inform him that DB would not be paying Atos's invoice for Key Milestone 4 because Atos's performance was "far from satisfactory". He went on to say that "I will not be paying any other invoices until such time that Atos has demonstrated that the project is being delivered to plan and to quality". Mr Bray responded to say that he had forwarded the email to Nikki Ash, who was the person dealing with commercial issues within Atos, saying, "In my mind, there is a time for a commercial discussion but it isn't right now".
145. On 6 May Mr Newell met Mr Bray to review progress. By this stage Atos had arranged for Mr Cunningham to join the project, in the circumstances that I have already described. In an e-mail sent shortly after that meeting, Mr Bray reported Mr Newell as saying that he had no faith in the revised plan, which had no credibility within DB.
146. On the afternoon of 16 May Mr Bray had a further conversation with Mr Newell, the substance of which he set out in an e-mail later that day in the following terms:

• He was extremely perturbed by Nikki's call and sounded really shocked we would consider termination. I also think he doesn't know what to expect now because Nikki didn't talk about timescales under which we might terminate (as we had agreed). He has really taken this personally and said "the prospect of being let down seriously by Atos only for us to then terminate is unbelievable". The man is clearly concerned about his job and his credibility;

• He said that the over-run in costs is very definitely not all down to DTC and that AO would have a hard job proving that the scope is more complex than first envisaged and planned;

• . . . He told me that if we are able to continue to build their confidence over the next 2-3 weeks and we can come up with a viable plan which we jointly agree and we can guarantee we can deliver, he is not averse to a discussion with us about money. He did also say, however, that it won't be anything like the large numbers Nikki mentioned yesterday as he would not pay for our failures and any additional money that is agreed would have had to be contingent on delivery;

. . .

• We agreed I would go and see him next Thursday afternoon (time to be agreed). He was concerned he might receive notice of termination before then. I told him that I believed that was an unlikely outcome.

• He asked me if there is anything he could do to help to persuade AO to give this a little more time. I said I would get back to him on this. I agree that I would be available by phone Monday-Wednesday if he wanted to talk."

(Original emphasis)

147. Nikki Ash was a member of Atos's commercial team who was primarily concerned with the financial implications of the project from Atos's point of view. Two important points emerge from this e-mail, the contents of which both Mr Newell and Mr Bray were prepared to accept as accurate. First, it is quite clear that Atos was contemplating termination, not just suspension, and had communicated that to DB. This is apparent from the fact that Mr Bray himself used the word "terminate" - he did not use it only in the context of what Nikki Ash was reported to have said to Mr Newell. Second, it shows that DB was prepared to have a commercial discussion with Atos with a view to DB making some additional payment to Atos, albeit not at the levels for which Atos might have hoped. Whilst DB clearly felt that the contractual responsibility for the present situation rested primarily with Atos, I find that DB would have been prepared to make some extra contractual payment to Atos in order to see the project through.
148. On 21 May Mr Newell received a letter from Miss Morgenstern which asserted that the reasons for the slippage in the timetable were due to various causes for which DB was responsible, together with the assertion that there had been a significant increase in project scope. This was the first time that some of these complaints had been put in writing. The terms of the remainder of that letter need to be set out in full:

"The cumulative effect of the above is that the Project has now fundamentally changed from the original contracted terms in terms of scope, time to complete and cost and we are therefore entitled to require a formal variation to the contract to deal with these changes…

Accordingly, whilst Atos Origin remains fully committed to work with DTC to continue to deliver a successful Project, we feel that we will not be in a position to do so unless we both agree, as a matter of urgency, a formal variation to the Agreement, reflecting the new reality of the Project, the changes which have occurred so far and DTC's commitment to increase the level of funding for the Project and provide further payments to Atos beyond those set out in the original Agreement.

You have advised us that you have a programme review board on 29^th May 2008 in which you are yourselves considering the future of the project. I would ask you to call me to discuss the contents of this letter prior to your internal meeting as I must advise that in the event we are unable to reach an agreement with DTC by the close of business on 30^th May then Atos Origin will have no alternative but to suspend all work on the Project.

In addition, DTC is currently withholding payment of a milestone payment to the value £324,462 which was due to be paid upon sign off of the project requirements. I have been advised that DTC has no basis for withholding payment of this milestone given that the payment milestone trigger (project requirements sign off) has been completed. I would be grateful therefore if you would arrange for payment of this outstanding invoice without delay."

(My emphasis)

The reference to the non-payment in the last paragraph was to DB's non-payment of the invoice in respect of Key Milestone 4.

149. On 22 May Miss Morgenstern and Mr Bray met Mr Newell and Mr McKendrick in DB's offices, but the meeting was not very productive and the DB representatives did little more than listen to what Miss Morgenstern had to say. Mr Newell said that the reason why the meeting was short was because DB needed to understand what the cost and time implications were going to be before they could really have a meaningful discussion (Day 5, 82/8-11).
150. On 23 May Atos provided DB with a further revised project plan, which showed that the software would be delivered in two bundles, the first on 22 December 2008 and the second on 17 April 2009. As Mr Newell subsequently indicated in an e-mail to Miss Morgenstern (on 28 May 2008), these dates were of concern to DB given the importance of timely delivery of the project to the Government of Botswana.
151. On 27 May (the following Tuesday), following a meeting earlier that day, Atos submitted a revised plan giving slightly improved delivery dates of 19 December 2008 and 18 March 2009. It is not entirely clear what activities were driving the end dates on this new plan, but CRs were one of the factors identified, and these included CRs 37 and 38, which related to changes to the core functions as a result of Splitting. One of the assumptions contained in the Splitting CR was that the core SCMS processes would not need to be changed or would need to have only minor changes in order to accommodate Splitting. Mr McKendrick did not dispute, although he did not expressly accept, that there had to be changes to the core functions of the SCMS processes in order to accommodate Splitting (see Day 4, 19/3-11).
152. In the meantime, on the same day, Mr McKendrick had sent an e-mail to Miss Morgenstern requesting confirmation that any suspension would not take place until close of business on 6 June. He mentioned also that DB was awaiting the financial proposal from Atos for taking the project to completion, saying that he assumed that this would take into account the most recent version of the programme. Miss Morgenstern replied the same day, 27 May, as follows:

"As you are aware I wrote to you on 21^st May 2008 in relation to the Project. In that letter I informed you that Atos Origin would have no alternative but to suspend all work on the Project with effect from 30^th May 2008 unless Atos Origin and DTC entered into a variation to Agreement covering the matters referred to in the letter.

I understand that DTC's Steering Committee, which oversees the Project within DTC, will not meet until 4^th of June 2008. Taking this into account and following our conversation I can confirm that Atos Origin is now prepared to extend the deadline, for suspension, previously set at 30th of May 2008, to 6 June 2008.

Regarding the financial proposal, Paul and myself will have high level figures with us at our meeting on 29 May 2008 based on the revised plan."

(My emphasis)

153. On 29 May Messrs McKendrick and Newell met Mr Bray and Miss Morgenstern to discuss Atos's letter of 21 May 2008. This was a fairly short meeting and DB asked for written confirmation of the figures that were discussed in relation to Atos's financial proposal to continue work on the project. On the same day Mr Newell wrote to Atos expressing DB's concerns over the latest proposed delivery plan.
154. On 30 May Mr Newell wrote to Miss Morgenstern to say that Atos was not entitled to suspend work and that DB expected Atos to perform its obligations in accordance with the Contract. He wrote:

"Like you, I have a desire to see this Project completed, but I am having difficulty in understanding how that translates to a proposal to suspend work from (a revised date of) 6^th June? Whilst we are aware of your wish to renegotiate the terms of the contract, Atos does not have any right to suspend work on the Project and this will only cause further delay from Atos' already revised delivery date for the Project of 18^th August and 27^th October. Our project team is ready and available to work with your development team and it is wholly unacceptable for you to waste our time by threatening suspension

Your demand for payment of £324,462 is disputed. Atos has not fully delivered the Key Milestones for Phase 1, for which you have already received payment in full. In the circumstances, DTC is entitled to withhold further payments pending resolution of the dispute.

You claim that the delays and cost overruns are attributable to work that is not your fault and which is outside the scope of contract. We disagree. You have not given us any specific examples of the complaints listed in your letter, which makes it difficult for us to respond, but you have never given us notice of our failure to perform our contractual obligations (as the contract requires).

We do not understand how there can have been an increase in the Project scope when Atos has available to it and has been using and controlling the change control process. We expect you to deliver the Project in accordance with the Specification and the contract."

155. As I have already noted, the point about Atos not having delivered the Key Milestones for phase 1 was not a good one, and by the conclusion of the trial it had effectively been abandoned. There was no justification for DB's refusal to pay the invoice. It was done, as I find, simply to put pressure on Atos.
156. On 2 June 2008, Miss Morgenstern replied setting out the terms that Atos expected DB to agree before 6 June 2008 if DB wanted to avoid Atos's suspension of work. This e-mail included the following passages:

"Our estimate is that the total cost to complete would be an additional £4.6Million over and above the original contract value of £2.9Million. This figure represents our estimate of the costs to complete without their [sic] being any element of profit in Atos Origin's charges.

There are a number of assumptions that underpin this estimate including:

• The business requirements are as set out in Requirements Definition documents that represent the baseline after analysis on 8th February 2008, and all changes approved at 2nd June 2008 and do not change. [The RDDs were then listed.]

• The current version of DS-SY003, Aggregation and EAI Architecture Blueprint, is accepted as meeting DTC Enterprise Architecture (AR-EA002) and the SOA Domain Model (AR-EA001) and any future changes to AR-EA002 and AR-EA001 shall be subject to change control. All outstanding issues need to be finalized and agreed as part of any commercial settlement including a clear understanding between both parties how the acceptance will be achieved.

• The implementation plan dated 23rd May 2008 (DTC replan v0.4) is accepted as the baseline plan.

Without any admission of liability we are willing to complete the project on a time and materials basis at our own internal standard rates (i.e. these rates would not anticipate any element of profit being paid to us). Our offer to complete the project on this basis is subject to the following:

• DTC's agreement to waive any claim that it may have against us in relation to our delivery to date

• Our agreeing with DTC a detailed change control note modifying the terms of the contract to record the new pricing structure and record agreement of the applicable rates and the full scope of the contract as now agreed. We would also need to incorporate all pricing assumptions and deal with any other matters that have arisen between us and which need clarification.

• Payment of the outstanding milestone payment that DTC is withholding to be made prior to execution of the change control note."

157. On 4 June 2008, Miss Morgenstern wrote to Mr Newell to confirm that Atos's position had not changed and that Atos would suspend work on the project on 6 June 2008 at 5pm in the absence of DB's consent to a formal variation of the Contract.

"In the meantime we regret that our position as outlined in our letter of 21^st May has not changed. Accordingly as set out in that letter we believe we are entitled to suspend the continued provision of the services should we be unable to come to a commercial resolution with you by 5pm on June 6^th 2008 and further on the basis of non payment of the outstanding issued invoice.

Accordingly unless we are able to come to a commercial resolution of the issues Atos Origin will suspend all work on the Project with effect from 5pm on June the 6^th 2008."

(My emphasis)

158. On 5 June 2008 Mr Newell wrote back saying that Atos was not entitled unilaterally to change the contract whilst threatening to suspend work if DB did not agree to its terms.

"It appears to us that you are demanding a wholesale renegotiation of the contract, abandoning our original agreement. We are staggered by your cynicism by demanding these payments at such a critical stage in the Project timetable – the point when the Project ought to have been delivered for user acceptance testing.

As you know, I met with The DTC Project board this week to discuss your proposal. You will not be surprised to hear that my recommendation was to reject your proposal not only because of the huge monetary implications and the failure to meet our deployment schedule, but also because I doubt Atos Origin's ability to deliver the Project even to the new dates you propose. Due to the seriousness of my recommendations and the implications this has on The DTC's entire business plan, the Project board has referred the issue to the Executive Committee. I will therefore respond to you more fully when our Executive Committee has considered its position.

In the meantime, I do not think it appropriate that we have our telephone call tomorrow, but I will be in touch soon with The DTC's response."

(My emphasis)

159. On 6 June 2008, Atos sent a further letter confirming that it would be instructing staff to suspend work on the project that afternoon unless a commercial agreement could be reached. The letter was in the following terms:

"As you are aware, we have made it clear that we have no alternative other than to suspend work with effect from 5pm 6^th June 2008, unless a commercial settlement on the project can be achieved. It is Atos Origin's objective to continue with the Project based on a revised approach agreed between us.

We asked for a full statement of your position following our letter of 21st May 2008. You have not provided such a statement nor given any indication that you are willing to make any contribution to the increased costs.

By reason of the matters set out in our letter of 21^st May 2008 Atos Origin cannot be expected to continue with the Project unless a revised agreement is entered into.

You now say that the matter has been referred to your Executive Committee. You do not say when that Committee is either meeting nor whether it will be in a position to make a definitive conclusion on the matter. You have been fully appraised of Atos Origin's position for several weeks, which has given you ample time to seek Executive approval.

Unless you can confirm the Executive Committee will meet today and make such a decision, we will have no alternative other than to suspend. To this end, we will be giving instructions to our staff this afternoon. We will issue a further notice when suspension has actually taken effect.

Keith Wilman, our UK CEO, is available through today for a discussion on the matter."

(My emphasis)

160. In line with this, at the end of the day on Friday 6 June 2008 Atos's project staff suspended work and handed in their security passes to DB staff. Thereafter, no-one from the Atos project team attended DB's premises on the following Monday (9 June 2008) to continue work on the project.
161. On 9 June 2008 Mr Newell received a letter from Miss Morgenstern confirming that Atos had indeed carried out its threat and had suspended work on the project:

"As set out in our letters of 21^st May 2008 and 6^th June 2008, it has been Atos Origin's intent to reach a revised Agreement with DTC which would address all issues in respect to the changes in specification, timescales and costs. We are disappointed that DTC did not make any response to our proposals in regard to such a revised Agreement.

It is unreasonable to expect Atos Origin to continue to work on the project without having such fundamental contract principles agreed between us and without any commitment to pay outstanding sums due. We gave DTC ample notice to enable DTC to consider its commercial position and reach agreement with Atos Origin.

Accordingly, as advised in our letters of 21^st May 2008 and 6^th June 2008, there is now no alternative but for the project to go into suspension. We note on Friday 6^th June 2008 you took steps to put this process into effect. By this letter we confirm that the project is now suspended and Atos Origin's staff have ceased work.

We would be happy to discuss with you the basis for the resumption of our services once your executive committee has met and considered our proposal (as you mentioned it would in your letter of 5^th June)."

162. In response, Mr Newell wrote to Atos's General Counsel accepting Atos's renunciation of the contract and thus bringing the contract to an end.

"The position that Ursula Morgenstern has adopted in correspondence and Atos Origin's suspension of work clearly show that Atos Origin does not intend to comply with the existing contract. Atos Origin is attempting, unilaterally, to force us to accept a wholesale change to the agreement and refusing to perform at all unless we accept. This is a repudiation of the contract. In the circumstances, we hereby accept this repudiation and terminate the contract."

163. The final shot in this exchange was Miss Morgenstern's letter to Mr Newell of 10 June 2008, which was in the following terms:

"Atos Origin denies it has repudiated the contract. Up to 6^th June 2008, Atos origin continued to work on the project notwithstanding that it had altered substantially in terms of scope, timescales and costs.

Atos origin has behaved reasonably throughout. Your reference to demands by Atos origin were, in fact, commercial proposals which reflected the changed circumstances. They were issued as the basis of a negotiation which would have enabled the project to continue.

In our letter to you of 9^th June 2008 we made it clear that, following suspension, we were available for discussions concerning the project and its restart, subject to reaching agreement on revised terms. However, by your actions on 6^th June 2008 and in your letter of 9^th June 2008 you have made it known that you do not intend to proceed with the project being delivered by Atos origin. Your assertion that Atos origin has repudiated the contract is invalid, but in the circumstances Atos origin has no alternatives other than to consider it is discharged from any further performance of the project."

The reasons for the delay and additional work carried out during 2008

164. I consider that there were four, possibly five, major reasons for the delays and additional work that was carried out between 1 January and 6 June 2008. They are as follows:

(1) Change Requests that were a true change in the scope of the work, such as, for example, Splitting.

(2) Additional work that resulted from elaboration of the original high level requirements, but which did not amount to changes in scope.

(3) Failures and delays by DB in finalising certain requirements, in particular the finance requirements.

(4) Errors or shortcomings in the design of the system, in particular the lack of proper systems analysis or engineering, and delays in producing the reference architecture and in making the decision about the workflow engine. And, possibly,

(5) Lack of effective communication between Atos and Atos India.

Delay

165. As I have already noted, the March/April re-plan showed that the second phase of Splitting was driving the final delivery date. The final version of the Impact Assessment for Splitting was submitted on 20 December 2007. Following the acceptance of the revised plan, the CR for Splitting was updated. In a covering e-mail dated 1 April 2008, attached to which was the updated CR, Mr Culshaw wrote to Mr McKendrick as follows:

"Please find attached the updated CR for Spitting. I have changed the following in this version to bring it in line with current plans:

1. Timescales- I have suggested revised timescales based on the current view of the plan.

. . .

4. LDs - I have amended the LDs to be payable against the fixed price (£415,000) less any unused contingency, as you requested. They are payable if we miss the Final Acceptance Date which, in accordance with the Timescales section, I have suggested is expected to be by the end of October 2008 and is, in any case, to be agreed by DTC and AO by the end of April.

Please let me know if you have any questions. Otherwise, I would be grateful for confirmation that this is now agreed and I will ask Ken to liaise with you with regards to getting this signed physically."

166. On 2 April 2008 the RDD for the set of processes within Splitting was reissued by Atos. The document runs to over 100 pages and indicates the very high degree of complexity of the Splitting processes. On the same day there was an exchange of e-mails between Mr Culshaw and Mr McKendrick, in the course of which Mr Culshaw said that he did not think that it would be appropriate to tie in the LDs for Splitting to bundle 2. The exchange concluded with Mr McKendrick agreeing to a suggestion from Mr Culshaw that "we tie LDs to the delivery date or dates which we will agree to agree by end of April".
167. I have not been directed to, and I have been unable to find for myself, any document recording a discussion and agreement about the dates by reference to which LDs would run in relation to Splitting. On 27 May 2008 Atos submitted a further revised programme which showed the delivery dates for bundles 2 and 3 being put back to 19 December 2008 and 18 March 2009, respectively. A few days before that, on 23 May, Atos sent DB two documents showing the drivers for bundle 2 and bundle 3. These showed that one of the factors driving the completion of bundle 2 was implementing workflow and another and more significant factor, was the development of CRs. In addition, Atos had included further drivers to bundle 2 in the form of 80% utilisation of manpower and additional contingency of 10-15%. For bundle 3, the principal driver was the development of CRs, together with similar allowances for contingency as were made for bundle 2.
168. Taking the documents that I have summarised above as a whole, I conclude that Splitting, or at least the CRs associated with it, probably remained a principal driver to completion of both bundles 2 and 3 in all the programmes prepared up until the end of May 2008. I find also that there was never any agreement in relation to the application of LDs in relation to Splitting. Whilst it is clear that the price for Splitting, £415,000, had been agreed, the implications of the CR in relation to time had never been agreed. Accordingly the time for completion of Splitting was at large, that is to say that Atos's only obligation in relation to delivery of Splitting was to achieve it within a reasonable time.
169. This conclusion renders it unnecessary to consider other causes of delay for this purpose because they were, in my judgment, at best only concurrent causes of delay and would therefore attract no liability in the form of LDs provided that they were achieved or delivered no later than the delivery of the relevant Splitting modules. However, the other causes of delay have to be considered because they are relevant to any claim by Atos for loss caused by delay.

Entitlement to additional payment

170. Whilst I have found that the CRs in relation to Splitting were probably on the critical path to the completion of both bundles 2 and 3, that does not imply that they were the only causes of delay that were on the critical path. Other causes of potentially critical delay, if taken together, for which Atos was alone responsible were: the additional work that resulted from elaboration of the original high level requirements, but which did not amount to changes in scope; the errors or shortcomings in the design of the system (as summarised by Mr Cunningham), together with the delay in making the decision about the workflow engine; and, possibly, the lack of effective communication between Atos and Atos India.
171. In addition, as I have mentioned, there were other causes of delay, such as the delay in providing DB's finance requirements, for which DB was responsible. There has been no analysis of the critical delays to the project, and so I must do my best to assess what delays were in truth driving completion of both bundles 2 and 3.
172. I consider that the delays caused by the need to introduce a workflow engine and to implement the recommendations made by Mr Cunningham would have amounted together to about an additional 2 months to the programme shown in the March/April re-plan.
173. I consider that the ongoing process of elaboration of DB's underestimated requirements (i.e. changes in depth that were not changes in scope) would, by mid-May 2008, have added a further 4 weeks - at least - to the March/April programme.
174. Finally, I consider that the March/April programme was never achievable in the first place because it relied on 100% performance by the members of the Atos team, so that there was no allowance for sickness or holidays, and because it carried no contingency. These two factors alone probably meant that it was over optimistic by at least a month, so that the true completion date for bundle 2 would not have been earlier than mid September, and possibly later, not mid August 2008, and the true completion date for bundle 3 would have been not before the end of November 2008.
175. The effect of these assessments is that the delays for which Atos was responsible would have resulted in a delivery date for bundle 2 of about mid December 2008 (in other words, 3 months from mid September 2008) irrespective of any delays caused by failures on the part of DB or by true changes in scope.
176. I conclude, therefore, at least so far as bundle 2 is concerned, that both Splitting and causes for which Atos was responsible were driving the completion date. In other words, each party was responsible for critical delays to completion that were operating concurrently. Upon the evidence available I am not able to distinguish between the causes of the delay to bundle 2 and the causes of the delay to the completion of bundle 3. I therefore reach the same conclusion in relation to bundle 3.
177. The general rule in construction and engineering cases is that where there is concurrent delay to completion caused by matters for which both employer and contractor are responsible, the contractor is entitled to an extension of time but he cannot recover in respect of the loss caused by the delay. In the case of the former, this is because the rule where delay is caused by the employer is that not only must the contractor complete within a reasonable time but also the contractor must have a reasonable time within which to complete. It therefore does not matter if the contractor would have been unable to complete by the contractual completion date if there had been no breaches of contract by the employer (or other events which entitled the contractor to an extension of time), because he is entitled to have the time within which to complete which the contract allows or which the employer's conduct has made reasonably necessary.
178. By contrast, the contractor cannot recover damages for delay in circumstances where he would have suffered exactly the same loss as a result of causes within his control or for which he is contractually responsible.
179. This means, that as things stood out as at the date of termination, Atos would have been entitled to an extension of time until about mid December 2008 in relation to bundle 2, but would not have been entitled to recover from DB the prolongation costs consequent upon the delay up to that date. For the reasons given, I am not satisfied that the result in relation to the completion date of bundle 3 was any different.
180. Thus when considering DB's loss, to which I will turn later in this judgment, DB is not entitled to the benefit of any sum in respect of an accrued liability on the part of Atos for LDs and Atos is not entitled to a deduction in respect of any claim for prolongation costs.

The correct approach to the construction of the Contract

181. Before I turn to consider the terms of the contract, I should remind myself of the correct approach to the construction of its terms. It is well established that a commercial contract must be read as a whole and in the context of the events that gave rise to it. In Reardon Smith Line Ltd v Hansen-Tangen [1976] 1 WLR 989, at 995-996, Lord Wilberforce said:

"No contracts are made in a vacuum; there is always a setting in which they have to be placed. The nature of what is legitimate to have regard to is usually described as "the surrounding circumstances" but this phrase is imprecise: it can be illustrated but hardly defined. In a commercial contract it is certainly right that the court should know the commercial purpose of the contract and this in turn presupposes knowledge of the genesis of the transaction, the background, the content, the market in which the parties are operating."

Lord Wilberforce also went on to say, at page 996:

". . . when one is speaking of aim, or object, or commercial purpose, one is speaking objectively of what reasonable persons would have in mind in the situation of the parties."

182. More recently, in Investors Compensation Scheme Ltd v West Bromwich Building Society [1998] 1 WLR 896, at 912-913, Lord Hoffmann said, in respect of the factual matrix, that:

"Subject to the requirement that it should have been reasonably available to the parties . . . it includes absolutely anything which would have affected the way in which the language of the document would have been understood by a reasonable man."

183. By contrast, in relation to what the court may not take into account, in Prenn v Simmonds [1971] 1 WLR1381, Lord Wilberforce summarised the position as follows:

"In my opinion, then, evidence of negotiations, or of the parties' intentions, and a fortiori of [the claimant's] intentions, ought not to be received and evidence should be restricted to evidence of the factual background known to the parties at or before the date of the contract including evidence of the "genesis" and objectively the "aim" of the transaction."

184. In this case the parties would have been aware of the events leading up to the making of the contract including the tender process, the Best and Final Offer ("BAFO") made by Atos and the implementation of the IAP.
185. More specifically, the parties must be taken to have known, because the business analysts on both sides soon formed a view to that effect, that the time available for the IAP was insufficient; indeed, Atos's lead business analyst, Mr Ralph Adelman, thought that it was probably about half the time required. Further, as Mr Adelman fairly accepted, Atos was aware at an early stage during the IAP that the level 5 process plans provided by DB were in many respects inaccurate and were not a reliable starting point (Day 9, 9/25 - 10/5).
186. Mr Adelman accepted that he appreciated that the requirements that would be produced as a result of the IAP would be at a high level only, would not reflect accurately or fully DB's business processes and would therefore be incomplete. That was the effect of his evidence on Day 9, 11/11-22, and at 30/20 - 32/14. Mr Adelman said that he communicated his concerns to Atos's project manager, who was then Mr Wong. Mr Wong's reaction was that they would just have to make assumptions which, as Mr Adelman accepted, meant that Atos took the risk that those assumptions might prove to be wrong.
187. For its part, DB had concerns at the conclusion of the IAP that Atos still might not have grasped the complexity of DB's processes. The position is probably best summarised by the following extracts from the cross-examination of Mr McKendrick. In the first, Mr McKendrick was being asked about the position as at 3 October 2007 (Day 2, 129/17-24):

MR LEWIS: We saw earlier the concerns which the De Beers business had that Atos was trivialising its business requirements. Had the De Beers business by this point in time got to the stage where it was comfortable that Atos was no longer trivialising its business requirements?

A. I think it fair to say that they had improved their situation in terms of understanding, yes.

Then, a little later (Day 2, 134/21 - 135/13), but referring to a slightly earlier point in time, is the exchange that I have already set out above, but which I repeat below for ease of reference:

MR LEWIS: At the end of the initiation and analysis phase, at the end of August 2007 and the beginning of September 2007.

A. There were concerns still within the business as to whether or not Atos had fully understood the depth of requirements. There were reassurances from Atos that they indeed had understood fully the requirements.

Q. But that was because they assumed that the high level requirements would give them enough information to understand that complexity?

A. But that is a failing, surely, on Atos' behalf, not De Beers.

Q. Who knew how complex the business processes were?

A. De Beers.

Q. So if they knew that Atos was misunderstanding that, why didn't they tell them?

A. But I think they did.

Q. That's where we differ.

188. It seems to me that a reasonable organisation in Atos's position in October 2007 would have appreciated the following: that Atos had only captured DB's requirements at a high level, in other words in fairly broad terms only, and that it was likely that a significant amount of information leading to further detailed requirements - but within the scope of the high level requirements - would emerge during the detailed analysis stage. It would follow that this was an element of risk that would have to be reflected by including provision for an appropriate contingency when the final price for the contract was being negotiated.
189. On DB's side, it must have been appreciated that, whilst Atos had had the benefit of the IAP in which to acquire a good understanding of the complexity of DB's business, it had probably not done so to the extent that DB had hoped and anticipated would have been the case. It is not possible to conclude on the basis of the evidence before the court what, if anything, DB said to Atos about this. I have already referred to the presentation given by Mr McKendrick at a meeting on 24 August 2007 at which DB raised concerns about the strength and calibre of several members of the Atos team, including the project manager, Mr Wong, and the lead business analyst, Mr Adelman. For present purposes, it does not matter whether those considerations were justified although, as a matter of fact, amongst other changes, Mr Wong was replaced as project manager about a month later and a new technical architect, Mr Cotter, was brought in to strengthen the design side of the team. What is important is that I consider that DB was on notice of the fact that the IAP had not fully achieved its objective and that Atos might still not have grasped the full complexity of DB's processes.
190. One of the reasons for this state of affairs, which was known to both parties and recorded in contemporaneous documents (see, for example, the project status report dated 16 July 2007, at D21/50), was that the workshops in which the business requirements were to be gathered by Atos during the IAP were fairly unstructured affairs, with some of the users on the DB side disagreeing amongst themselves as to precisely what the business required in terms of its detailed processes and a large number of issues emerging. The problem was exacerbated by the fact that the Atos business analysts never saw the relevant processes in operation on the ground: it was suggested much later (internally by DB) that it would have been a good idea if they had attended some sort of diamond familiarisation course before embarking on the IAP. In short, by the time when the contract was made both parties would have been aware that the IAP had not proved as successful as it should have been.
191. In my judgment, Atos went into this contract with its eyes at least half open, in the sense that it knew or should have known that it had not acquired a good grasp of the detail of DB's diamond sorting and aggregating processes and that consequently a great deal of work remained to be done in the way of gathering the detailed requirements, with consequent implications for the development of the design - both in terms of time and resources. However, as subsequent events showed, it is clear that it seriously underestimated this risk, a problem that I suspect may have been compounded by an additional factor, namely that those responsible for the commercial negotiation of the contract did not liaise very thoroughly with Atos's project manager and business analysts who had been involved in the IAP. However, since there was very little evidence before the court as to the manner in which the figures were put together when the final contract price was being negotiated, I can make no positive findings about this.
192. It seems to me that DB acted reasonably in agreeing to the IAP, which was done in order to give Atos a reasonable opportunity to understand DB's business before committing itself to the contract. This was not a contract of the utmost good faith and I consider that a reasonable business organisation in the position of DB, having indicated some of its concerns about Atos's performance during the IAP, was entitled to leave Atos to assess the risk for itself, to put forward a price that included a realistic contingency in case the project should prove much more complex than was apparent from the investigations to date and, if it could do so, to negotiate any variation of the terms of the proposed contract in order to reduce its exposure should it turn out that DB's business was much more complex than Atos had originally anticipated.
193. However, DB should have learned from the IAP that it was absolutely essential that those of its employees who possessed the detailed knowledge of the various areas of the business would have to be made available to Atos as a matter of priority, and not simply as and when they could find the time. It would also have been aware, if for no other reason because it was obvious, that Atos had little or no control when it came to gaining access to DB's employees or process information. DB should have appreciated that, without considerable impetus and management of resources on its part, access by Atos to the relevant subject matter experts within the DB organisation was never going to be satisfactory. I consider that certain provisions of the Contract need to be read and applied with this in mind, because Atos should not be expected to have to make an inordinate number of requests to DB in order to gain access to any particular subject matter expert.

The Contract

194. The Software Development and Supply Agreement ("the Contract") was signed on 2 November 2007 (although the document is dated 1 November). However, the Project Plan was not agreed until 16 November 2007. For the purposes of this judgment it probably does not matter whether the Contract was in fact concluded on 2 or 16 November 2007.
195. In this section of the judgment I will set out the relevant parts of the main provisions of the Contract, together with my conclusions as to how they are to be construed (where this was in issue).
196. Clause 1 (the interpretation clause):

Specification(s) means the detailed functional and/or technical specifications (including the Custom Software Specification) and performance criteria for the Commissioned System as further described in Schedule 2, as may be updated pursuant to the terms of Schedule 1 or otherwise amended pursuant to clause 5 from time to time;"

197. Clause 2:

2. PROVISION OF THE SERVICES

2.1 Subject to the terms of this Agreement (including the assumptions and dependencies set out in Schedule 12), and in consideration for the Price to be paid by the Customer under this Agreement, the Supplier will:

2.1.1 perform the Services and deliver the Deliverables in accordance with Schedules 1 and 3, the PID, the Project Plan, the Specifications and the terms and conditions of this Agreement;

2.1.2 procure, deliver and install the Commissioned System on the Hardware as provided in Schedule 1;

2.1.3 create and maintain a Product Log.

2.2 The Supplier will carry out its obligations under this Agreement in accordance with the timetable set out in the Project Plan.

2.3 The parties agree that the Commissioned System and the Application Development Services will roll out using a phased approach in accordance with the Project Plan, with the delivery of the various Deliverables and completion of each phase being marked as Milestones which will be reflected accordingly in the pricing structure contained in Schedule 9. Unless identified as a Key Milestone Date the dates contained in the Project Plan are intended for planning and estimating purposes only and are not contractually binding.

2.5 Notwithstanding the above, and for the avoidance of doubt, the parties agree that the Supplier will not incur liability and any dates quoted in the Project Plan for delivery of any part of the Services or Deliverables shall be extended by a reasonable period, if such delay is caused by (i) any act or omission of the Customer, its servants or agents; or (ii) any cause beyond the Supplier's reasonable control. To the extent that the Supplier suffers loss or incurs extra costs, due to the scope of the Services or Deliverables being increased or the Project Plan being lengthened by reason of such a delay or failure by the Customer to comply with any of its obligations contained in this Agreement or any of the assumptions or dependencies stated in Schedule 12 not being met the Supplier may charge the Customer for any such loss or extra cost, provided it agrees to use reasonable endeavours to mitigate such loss or extra cost and that the extent of such loss or extra cost is agreed through the Change Control Procedure.

2.6 The Supplier shall provide the Services and supply the Commissioned System in accordance with the reasonable directions of the Customer's Project Manager as given to the Supplier in accordance with the terms of this Agreement (provided always that such directions do not entail the provision of services which are outside the scope of the Supplier's obligations under this Agreement, unless agreed pursuant to the Change Control Procedure).

198. I pause here to consider clause 2.5 a little further. In my judgment, for the purpose of construing it, the clause must be broken down as follows:

Notwithstanding the above, and for the avoidance of doubt, the parties agree that the Supplier will not incur liability and any dates quoted in the Project Plan for delivery of any part of the Services or Deliverables shall be extended by a reasonable period, if such delay is caused by (i) any act or omission of the Customer, its servants or agents; or (ii) any cause beyond the Supplier's reasonable control.

To the extent that the Supplier suffers loss or incurs extra costs, due to

(1) the scope of the Services or Deliverables being increased or

(2) the Project Plan being lengthened by reason of such a delay or

(3) failure by the Customer to comply with any of its obligations contained in this Agreement or

(4) any of the assumptions or dependencies stated in Schedule 12 not being met

the Supplier may charge the Customer for any such loss or extra cost, provided it agrees to use reasonable endeavours to mitigate such loss or extra cost and that the extent of such loss or extra cost is agreed through the Change Control Procedure.

I think that it was common ground that the first part of the clause is essentially concerned with time and the second part with entitlement to money. When broken down in this way it can be seen, contrary to the submissions of DB, that the second part is very wide ranging. The words that I have set out after (3) are apt to embrace any breach of contract, as well as compliance with the assumptions or dependencies. Further, Mr Simon Croall QC who, with Mr Yash Kulkarni, appeared for DB, submitted that Atos cannot recover any money under the second part of the clause simply because the Project Plan has been lengthened by a cause beyond its control. However, I consider that the clause says exactly the opposite. If the Project Plan is lengthened as a result of a cause that is beyond Atos's reasonable control and Atos suffers loss as a result (in the form of delay costs), Atos can recover that loss under the clause.

199. Another result of this analysis, which may at first seem curious, is that any claim for breach of contract must be channelled through the Change Control Procedure. However, I consider that what this really amounts to is a form of dispute resolution procedure that should be followed before either party embarks on litigation. If it were otherwise, DB could effectively stifle any claim for breach of contract by the simple expedient of refusing to agree it within the Change Control Procedure. I consider that if the parties cannot agree the amount of the loss or extra cost there will be a dispute which can be referred to litigation. The court would then assess the amount of the loss or extra cost in the usual way applying the well established principles for claims for breach of contract in the context of this contract.
200. Clause 3 provides:

"3.1 The parties acknowledge that the Customer may require or the Supplier may identify, Additional Services to be provided by the Supplier during the term of this Agreement.

3.2 Such Additional Services, if within the scope of the Project, shall be agreed between the parties pursuant to the Change Control Procedure. However, if such Additional Services are outside the scope of the Project, the parties shall use reasonable endeavours to agree the terms for such Additional Services.

3.3 . . ."

Interestingly, neither of the parties referred to this clause in the course of their submissions. However, I consider that it is of some interest because it suggests that some types of additional work, whilst falling within the scope of the project, can nevertheless constitute a change. It follows from this that when considering what type of additional work constitutes a change one must distinguish between the "scope of the Services or Deliverables" (clause 2.5) being increased, on the one hand, and the "scope of the Project" (clause 3.2) being increased, on the other.

201. Clause 5:

"5.2 The parties acknowledge that not all Changes requested by Customer or recommended by the Supplier shall automatically be chargeable or imply an increase or reduction in the Price and any financial implications resulting from a Change shall be assessed and agreed as part of the Change Control Procedure…

5.3 The Supplier shall not be entitled to charge for Changes required to incorporate any services, functions and responsibilities not specifically described in or detailed in the Schedules but which are reasonably required for the proper performance and provision of the Services described therein.

5.4 The Customer may request the Supplier (and the Supplier may recommend) to supply Additional Services from time to time. Such Additional Services shall be classed as a "Change" for the purposes of this Agreement and, subject to the Customer and the Supplier signing a change control note ("CCN"), the Supplier will provide the Additional Services to the Customer from the effective date of the CCN. Unless otherwise agreed in writing, the agreed Additional Services will become part of the Services.

5.8 The Supplier shall not be entitled to charge for Changes required to incorporate any services, functions and responsibilities not specifically described in or detailed in the Schedules but which are reasonably required for the proper performance and provision of the Services described here in.

5.8 The parties shall bear their own costs in connection with the preparation of all documentation and negotiation of Changes.

5.9 Where the Supplier reasonably believes there is a justifiable reason to increase the Prices as a result of a Change it will supply to the Customer the following information with the Change Request to justify the basis of the increase:

5.9.1 an initial analysis of the reasons why the Supplier believes its cost will be materially impacted by the Change and any applicable supporting documentation, including an analysis of any alternative solutions utilising existing Supplier resources;

5.9.2 details of proposed one-off charges and/or changes to the Price based on the above; and

5.9.3 any other relevant information, including information justifying any proposed one-off charges or changes to the Price and any base data and charging assumptions reasonably required by the Customer to verify such proposed changes.

5.10 Following consideration of the Change Request, together with the information set out in 5.9.1-5.9.3 submitted by the Supplier, if the Customer agrees that there is a justifiable reason to increase the price, the parties shall agree a fair and proportionate increase to the Price. In the event the parties cannot reach agreement on such fair and proportionate increase, the provisions of clause 27 (Dispute Resolution) shall apply."

Additional Services were defined as meaning "additional services to be provided by the Supplier as agreed between the parties pursuant to the Change Control Procedure". I will discuss these provisions in more detail when considering the Change Requests.

202. Clause 6, which concerned DB's obligations, required DB to:

"6.1.2 promptly provide the supplier with accurate and complete information concerning its operations and activities relevant to the Project and answers to queries, decisions and approvals required by the Supplier in connection with the Project as the Supplier may reasonably require.

6.1.3 provide the [Customer hardware identified in (the Architecture Blueprint)]" (words in brackets are incorporated by reference to Clause 1.1 and Schedule 6).

6.1.7 provide the Supplier with appropriate access to the Legacy System and Data of the Customer in order to enable the Supplier to perform its obligations under this Agreement.

6.1.9 ensure that the staff it assigns to the project have appropriate skills and experience for the tasks to which they are assigned. The Supplier's Personnel shall have a right of access to the Customer's staff at all reasonable times throughout the duration of this Agreement as is necessary solely for the purposes of the Project.

. . .

6.2 The Supplier will notify the Customer as soon as practicable if it becomes aware that the Customer is not complying with its obligations under this Agreement including the Customer Inputs. If any such failure is likely to impact on a Key Milestone Date the Supplier shall notify the Project Steering Committee as soon as practicable. Provided the Supplier duly notifies in accordance with this clause 6.2, if any Key Milestone is not achieved on or before the relevant Key Milestone Date as a result of such failure by the Customer, the Key Milestone Date shall be varied in accordance with the Change Control Procedure."

203. Clause 7.2:

"7.1 If the Supplier fails to meet any milestone or other date specified in Schedule 9 as being a date that if missed could give rise to an LD Credit (an "LD Trigger Date") (as the same may be extended under the other provisions of this Agreement) (a "Delay") then, to the extent that such Delay results from reasons directly connected to or arising from the Supplier's acts or omissions and its provision of the Services and Deliverables under this Agreement, the Supplier shall pay late delivery credits to the Customer in the amounts set out in part 3 of Schedule 9 ("LD Credits").

7.2 To the extent that a Delay is caused by any act or omission of the Customer then, without prejudice to the Supplier's obligation to endeavour to meet the original LD Trigger Date and otherwise mitigate the effect of such Customer acts or omissions, the LD Trigger Date shall be adjusted accordingly and the LD Credits shall only become payable if such adjusted LD Trigger Date is not met."

204. Clause 12:

"12.1 In consideration for the satisfactory performance of the Services, the Price shall be payable to the Supplier in the amounts and at the times set out in Schedule 9, such times reflecting the Key Milestones identified in Schedule 9…

12.4 Undisputed invoices shall be payable by the Customer within 30 days of receipt of each invoice. If the Customer reasonably considers that any portion of an invoice submitted by the Supplier is not due and payable in accordance with the terms of this Agreement the Customer shall be entitled to withhold payment of the disputed portion of the invoice without prejudice to any other rights or remedies it may have, pending resolution of the dispute in accordance with the Dispute Resolution Procedure.

12.5 Without prejudice to the Supplier's any other right or remedy, any amount which is paid to the Supplier later than the date on which such sum first became due and payable under this Agreement (for the purposes of this clause, the 'Due Date') shall be paid together with interest at HSBC plc base rate, from time to time plus 2%, calculated from and including the Due Date up to but excluding the actual payment date and the supplier reserves the right, without liability to suspend the performance of the Services and the delivery of the Deliverables under this Agreement until such time the due amounts are paid to the Supplier.

12.6 The Customer may set-off any amount due and payable by the Supplier to the Customer under this Agreement against any amount due and payable by the Customer to the Supplier provided that the Customer has given the Supplier three (3) Business Days notice of such set-off and a reasonable opportunity to discuss the same."

205. Clause 23:

"23.1 Nothing in this Agreement shall exclude or limit any person's liability for (a) fraudulent misrepresentation, willful [sic] misconduct or deliberate default…

23.3 Except as provided in Sub-clauses 23.1 and 23.2 above, each party's total aggregate liability to the other…under this Agreement including (but not limited to) liability for breach of contract, misrepresentation (whether tortious or statutory), tort (including but not limited to negligence) or breach of statutory duty, shall not exceed the greater of 150% of the Price or £3,893,547.

23.4 Subject to clause 23.1, neither party shall be held liable for loss of profits (save that this shall not exclude the Customer's obligation to pay the Price due for Services provided hereunder), goodwill, revenue, production, real or anticipated savings, business, use or contracts, nor for any indirect, consequential or incidental damages, arising out of its failure to meet its obligations under this Agreement even if the party has been advised of the possibility of such loss or damages and whether or not such loss or damages are foreseeable."

206. I can deal with the point that arises under this clause quite shortly, because I have formed a clear view as to what the clause means. The question is what is meant by "deliberate default". The way in which clause 23.1 is drafted would suggest that "fraudulent misrepresentation", "wilful misconduct" and "deliberate default" are listed in descending order of culpability, as Mr Croall submits. This appears to me to be the case. Fraudulent misrepresentation obviously involves dishonesty. Wilful misconduct refers to conduct by a person who knows that he is committing, and intends to commit a breach of duty, or is reckless in the sense of not caring whether or not he commits a breach of duty (see Romer J Re City Equitable Fire Insurance Company Ltd [1925] 1 Ch 407). Deliberate default means, in my view, a default that is deliberate, in the sense that the person committing the relevant act knew that it was a default (i.e. in this case a breach of contract). I consider that it does not extend to recklessness and is therefore narrower than wilful misconduct (although the latter will embrace deliberate default).
207. I therefore reject Mr Croall's submission to the effect that the expression deliberate default embraces any deliberate conduct (as opposed to something done accidentally or inadvertently) that happens to result in a default, whether or not that was intended. Although I have no difficulty with this as a concept, I find it quite hard to envisage such conduct in the context of a contract such as this one. I therefore prefer the submissions of Mr Lewis on this point. I consider that the inclusion of deliberate default, whilst having a sensible meaning, was probably the result of drafting caution.
208. I will deal with the application of this clause to the facts later on in this judgment.
209. Clause 31.2:

"No relaxation, delay, forbearance or indulgence of either the Customer and the Supplier in exercising or enforcing nor any failure by either the Customer and the Supplier to exercise or enforce any right conferred upon it by this Agreement shall be deemed a waiver of any such right or operate so as to bar the exercise or enforcement thereof at any time or times thereafter."

210. Schedule 1:

"2.3 Each project phase as described in the Project Plan will include the provision of the following Services:

(a) detailed analysis;

(b) low level design;

(c) code and unit test; and

(d) system integration and user acceptance ("UAT") testing.

3.2.1 The Supplier shall work closely with the Customer's business user representatives to refine and further detailed [sic] the requirements set out in the Specifications (Schedule 2) during the Detailed Analysis phase.

3.2.2 The Supplier shall further analyse and capture details of requirements including business rules, algorithms and logical data model identified in the Specification.

3.2.3 The Supplier shall analyse and document additional non-functional requirements and the logical specification of external integration of the Commissioned System…

3.2.5 The Supplier shall deliver as a Deliverable an elaborated requirements definition document that has been reviewed, finalised and agreed with the Customer."

211. Schedule 2:

"The Commission System will be delivered in accordance with the Specifications set out in the documents referred to in Section 1 below as the same may be enhanced or clarified by the Detailed Design.

1. REQUIREMENTS, DESIGN GOVERNANCE AND TEST STRATEGY DOCUMENTS (THE SPECIFICATIONS)

AN-RQ001 Tolerance Engine Requirements

. . .

DS-SY003 Aggregation and EAI Architecture Blueprint (the "Architecture Blueprint")

I pause to comment here that the words in the opening paragraph above "as the same may be enhanced or clarified" accord with the reference in section 3.2.1 above which requires Atos to "refine and further detail the requirements set out in the Specifications". There is a dispute between the parties as to what this schedule means. Mr Croall pointed out that there are no version numbers given in this list, which is consistent with the fact that they are "living" documents in that sense that they would be developed as the project progressed. The importance of this is that, on DB's case, the obligation on Atos is to develop whatever system is required to support the requirements as reflected by the final versions of each of these documents: the versions that existed at the time when the contract was made are, in effect, irrelevant.

212. In my judgment, the documents referred to in Schedule 2 must be the ones that existed at the time when the contract was made, otherwise the phrase "as the same may be enhanced or clarified" would make no sense. Atos is therefore right to submit that whether or not a new process or step in a process is to be regarded as a change must be considered against the state of these requirements documents at the time when the contract was made. However, the words "as the same may be enhanced or clarified" indicate that the ultimate requirements were not frozen in the version in which they existed when the contract was made and would very likely be different.
213. Schedule 12:

"2.1 The Customer will work with the Supplier to identify any dependencies that the Project has on other projects or work being carried out by the Customer or on behalf of the Customer. The Customer will use reasonable endeavours to ensure that these dependencies are managed and scheduled in a way that the timescales in the Project Plan not delayed."

2.2 Those Customer Personnel assigned to the project will be empowered to make decisions in a timely manner according to the agreed project timeline."

2.3 The Customer will provide fully functioning test platforms which will include the AS400 and legacy systems required for the purposes of testing EAI. The Customer will prepare and populate the legacy systems with required test data that resemble the data on the production systems. The parties shall agree the level to which such data will be desensitised. The Customer provisioned legacy testing environment(s) will be available in accordance with the baseline Project Plan set out in Schedule 7."

2.6 The Customer will ensure regular access, as reasonably requested by the Supplier, to its development and business analyst resources throughout preparation time for required test cases."

2.16 The Customer will provide all hardware and peripherals to be integrated with the Commissioned System and required for testing in accordance with the baseline Project Plan set out in Schedule 7."

2.18 The Customer will make available key Customer staff throughout the project lifecycle, including business user representatives, technical specialists and subject matter experts, as reasonably requested by the Supplier."

2.19 The Customer will provide access to Customer legacy systems (excluding pre-production and production but including legacy systems applicable to Botswana, UK, Namibia and South Africa) and data to the Supplier project team throughout the development and testing cycles."

2.21 The Customer will provide technical documentation and such other information and artefacts reasonably required by the Supplier for the purpose of interpretation on all Legacy Systems in accordance with the baseline Project Plan set out in Schedule 7."

214. By way of comment only, I should add that the parties in this case rely only on the terms of the Contract. There are no claims in misrepresentation or for rectification.

The law relating to repudiation

215. One of the classic statements of the law in this area is found in the opinion of Lord Wilberforce in Federal Commerce v Melina Alpha (The "Nanfri ") [1979] AC 757, at 778, where he said:

"I shall not set out at any length the numerous authorities on anticipatory breach: this is one of the more perspicuous branches of the law of contract and the modern position is clear. The fault of the critical question may differ slightly as it is put in relation to the varying situations:

". . . an intimation of an intention to abandon and altogether to refuse performance of the contract. . ." or "evince an intention no longer to be bound by the contract . . . " (Freeth v Burr (1874) LR 9 CP 208, 230, per Lord Coleridge CJ) .

"I do not say that it is necessary to show that the party alleged to have repudiated should have an actual intention not to fulfil the contract. He may intend in fact to fulfil it, but may be determined to do so only in a manner substantially inconsistent with his obligations, and not in any other way" (Ross T Smyth & Co Ltd v T D Bailey, Son & Co [1940] 3 All ER 60, 72, per Lord Wright) such as to deprive "the charterers of substantially the whole benefit which it was the intention of the parties . . . that the charterers should obtain from the further performance of their own contractual undertakings" (Hong Kong Fir Shipping Ltd v Kawasaki Kisen Kaisha Ltd [1962] 2 QB 26, 72, per Diplock LJ).

"To constitute repudiation, the threatened breach must be such as to deprive the injured party of a substantial part of the benefit to which he is entitled under the contract . . . Will the consequences of the breach be such that it would be unfair to the injured party to hold him to the contract and leave him to his remedy in damages . . .?" (Decro-Wall International SA v Practitioners in Marketing Ltd [1971] 1 WLR 361, 380, per Buckley LJ).

The difference in expression between these two last formulations does not, in my opinion, reflect a diversion of principle, but arises from and is related to the particular contract under consideration: they represent, in other words, applications to different contract, of the common principle that, to amount to repudiation a breach must go to the root of the contract."

216. In my judgment, one does not have to look any further than this for authority. However, a recent decision of the Court of Appeal is of relevance to the facts of this case because it deals expressly with the relevance of the contemporaneous subjective views of the parties to the contract. It is Eminence Property Developments Ltd v Heaney [2010] EWCA Civ 1168. Etherton LJ, with whose judgment Sullivan and Mummery LJJ agreed, summarised the effect of the leading authorities in the following terms:

"61. I would make the following general observations on all those cases. First, in this area of the law, as many others, there is a danger in attempts to clarify the application of a legal principle by a series of propositions derived from cases decided on the particular facts. Instead of concentrating on the application of the principle to the facts of the case in hand, argument tends to revolve around the application of those propositions, which, if stated by the court in an attempt to assist in future cases, often become regarded as prescriptive. So far as concerns repudiatory conduct, the legal test is simply stated, or, as Lord Wilberforce put it, " perspicuous". It is whether, looking at all the circumstances objectively, that is from the perspective of a reasonable person in the position of the innocent party, the contract breaker has clearly shown an intention to abandon and altogether refuse to perform the contract.

62. Secondly, whether or not there has been a repudiatory breach is highly fact sensitive. That is why comparison with other cases is of limited value. The innocent and obvious mistake of Mr Jones in the present case has no comparison whatever with, for example, the cynical and manipulative conduct of the ship owners in The Nanfri.

63. Thirdly, all the circumstances must be taken into account in so far as they bear on an objective assessment of the intention of the contract breaker. This means that motive, while irrelevant if relied upon solely to show the subjective intention of the contract breaker, may be relevant if it is something or it reflects something of which the innocent party was, or a reasonable person in his or her position would have been, aware and throws light on the way the alleged repudiatory act would be viewed by such a reasonable person. So, Lord Wilberforce in Woodar (at p. 281D) expressed himself in qualified terms on motive, not by saying it will always be irrelevant, but that it is not, of itself, decisive."

The alleged repudiatory breach by DB

217. Atos relies on the following grounds as constituting a repudiatory breach or, taken together, repudiatory breaches of the contract by DB:

(1) The catalogue of breaches pleaded in Appendix 1 to the Defence and Counterclaim;

(2) DB's breach of clause 12 of the Contract by failing to make payment in respect of Key Milestone 4;

(3) DB evincing an intention that it would not abide by, or DB's failure to abide by, Atos's contractual right to extensions to the Key Milestone Dates and increased sums under or for breach of the Contract; and/or its evincing an intention that it would not comply with the Change Control Procedure so as to grant Atos extensions to the Key Milestone Dates and increased sums under or for breach of the Contract; and/or

(4) Mr Newell's conduct on the afternoon of 6 June 2008 in requiring the return of all identification and access cards held by Atos's staff.

218. The first ground, the catalogue of breaches pleaded in Appendix 1, begs further analysis because the matters set out in the Appendix are a combination of acts that are said to constitute breaches of contract and acts that are said to give rise to entitlement under the contract. Paragraphs (1)-(3), (19), (21)-(27) of the Appendix concern entitlement under the contract. Paragraphs (28)-(31) set out further consequences of the breaches or entitlements set out in the preceding paragraphs. In relation to paragraphs (7)-(15) and (17), the amounts claimed are either nil or, in two cases, less than £20,000. These, whether taken by themselves or with others, are not a promising springboard for an allegation of repudiatory breach of contract. Accordingly, I consider that all these paragraphs can be ignored for the purpose of analysing the effect of the alleged breaches of contract by DB.
219. As to the remaining allegations, I consider that, whether taken individually or collectively, they fall far short of conduct amounting to a repudiatory breach. I say that for three principal reasons, without having to analyse them in any detail.
220. First, at no stage prior to the letter of 21 May 2008 did Atos put any complaint in writing about breaches of contract by DB, let alone under clause 25 which deals with termination and material breach. The most that Atos put forward by way of protest in relation to potential breaches of contract by DB, was the occasional mention at meetings of the Steering Group of the unavailability of DB key personnel. The documents suggest that this was raised more as a point of irritation, rather than as a serious breach of contract.
221. Second, the overwhelming message from Atos conveyed by the contemporaneous documents from November 2007 onwards was that the detailed process requirements were proving to be far more extensive and complicated than Atos had envisaged at the outset. That was not a claim of breach of contract, rather it was directed at laying the ground for claims under the contract in respect of changes to the scope of the work. It cannot be dressed up as a claim that DB wrongfully refused to agree change requests, because relatively few change requests were put forward until much later on in the life of the Contract.
222. Third, the March/April re-plan effectively gave Atos an extension of time, if not money. The implicit acceptance by DB that Atos had valid claims for an extension of time is in my view inconsistent with conduct on its part that could be said to be repudiatory.
223. However, in case I am wrong about this, I will consider the remaining claims for breach of contract very briefly:

(5) Paragraph (5). This concerns allegations that DB failed to manage properly various aspects of the project such as, for example, the EDS. The sum claimed is about £59,000. These are all fairly technical points and, even if established, would come nowhere near amounting to a repudiatory breach of contract.

(6) Paragraph (6). This concerns allegations that DB did not meet its obligations in respect of the core SCMS until January 2008 when the Fast Track Requirements Gathering workshops began, and that it failed to provide the business requirements for the finance department until April 2008, both of which resulted in a number of consequences set out under the paragraph. The sum claimed is a little under £300,000. The first allegation relates mainly to delay, but Atos was compensated for that delay by DB's agreement to the March/April re-plan. I accept that the delay in resolving the requirements for the finance department was a breach of contract by DB, but it was a minor matter in the context of the project as a whole. In my view, the conduct that is the subject of these allegations falls way short of conduct amounting to a repudiatory breach.

(7) Paragraph (16). The allegation here is that a number of key DB resources were severely time constrained or unavailable. The sum claimed is about £110,000. I have already found that some aspects of this claim have been seriously overstated. I consider that it comes nowhere near being conduct that is repudiatory.

(8) Paragraph (18). This is a claim for delay in respect of the provision of technical documentation in respect of the Legacy Systems and testing. The sum claimed is about £23,000. There is nothing here that amounts to repudiatory conduct.

(9) Paragraph (20). This is an allegation that DB provided Atos with business processes which were incomplete or lack sufficient detail for Atos to be able to carry out its detailed analysis, low-level design and subsequent stages of work. It appears to relate primarily to the level 5 process maps that were provided to Atos during the IAP, and this is confirmed by the witness statement of Mr Adelman. I do not see how this can constitute a breach of contract when the events relied on took place well before the contract was entered into.

(10) Paragraph (22). Since I have ruled out the claim under paragraph (20), this relates entirely to the consequences of alleged changes in scope, not to breaches of contract.

224. Even if these claims are taken together, I consider that the conduct that is alleged to have given rise to them, even if proved, falls well short of constituting a fundamental breach of contract amounting to a repudiation of it. Further, there is no evidence that at any stage DB was evincing an intention not to be bound by the contract. For the most part it believed that the matters complained of were the responsibility of Atos, and not of DB. In that it may have been mistaken, but that does not make its conduct repudiatory.
225. I turn now to the next breach, the failure to pay the interim payment due in respect of Key Milestone 4. In my view, whilst this was a clear breach of contract, it was not a repudiatory breach. In withholding this money for the reasons that it did, I do not consider that DB was evincing a general intention not to be bound by the terms of the contract. It is also relevant, but by no means conclusive, that by clause 12.5 of the contract Atos was given the specific right to suspend work in the event of any failure by DB to pay a sum that was due under the contract. However, the non-payment of this amount probably constituted a material breach within the meaning of clause 25.2, so that Atos could have terminated the contract if the breach persisted for 30 days after Atos had served a notice requiring DB to remedy the breach and pay the money. Atos never served such a notice.
226. In relation to the third breach, I have to confess that I am not entirely clear what Atos means by its allegation that DB evinced an intention that it would not abide by Atos's contractual right to extensions to the Key Milestone Dates and increased sums under or for breach of the Contract and/or that it evinced an intention that it would not comply with the Change Control Procedure. As already pointed out, DB did in fact extend the date for delivery when it agreed the March/April re-plan. Whilst it is true that DB generally took the line that Atos was not entitled to the majority of the change requests that it made, it did accept some of them and its rejection of the others was, as DB saw it, a position that it was entitled to take under the terms of the contract. I consider that there is no evidence to support the allegation that DB was not prepared to comply with the Change Control Procedure: to the extent that it took a different view to Atos as to how this procedure should be operated, that did not evince an intention not to be bound by the terms of the contract - on the contrary, it was purporting to rely on those terms (even if wrongly). I can find nothing in these allegations that supports the claim that DB was in repudiatory breach of contract in respect of this ground.
227. Finally, Atos relies on Mr Newell's conduct on the afternoon of 6 June 2008 in requiring the return of all identification and access cards held by Atos's staff. I regard this point as hopeless. By that afternoon it was quite clear that there had not been and were not going to be commercial discussions of the type that Atos had said were to have taken place by 5 pm that day. Atos had made it abundantly clear that, failing such discussions, its staff would be withdrawn from the project that evening. Mr Newell's decision to withdraw their passes in those circumstances was no more than an acceptance of the inevitable and a sensible precaution. It must be remembered that DB was an organisation dealing in very high value items and for whom security was a very high priority.
228. Accordingly, for all these reasons I reject Atos's claim that DB repudiated the contract.

The alleged repudiatory breach by Atos

229. It is quite clear to my mind from the terms of the correspondence that I have already set out that at no stage was Atos purporting to exercise its right under clause 12.5 to suspend work until payment of the invoice. The message that came across loud and clear in the communications from Atos between 21 May and 6 June 2008 was that the work would be suspended unless DB agreed to enter into an appropriate commercial agreement with Atos by 5 pm on 31 May, subsequently extended to 6 June 2008. In my view this is abundantly clear from the terms of the letters of 21 May and 4 June 2008. In particular, the final paragraph of the latter was in the following unambiguous terms:

"Accordingly, unless we are able to come to a commercial resolution of the issues Atos Origin will suspend all work on the Project with effect from 5 pm on June the 6^th 2008."

230. In my judgment, the demands made by Atos, particularly in the e-mail of 2 June 2008, did not reflect its contractual entitlement and, in putting them forward, it was not undertaking to continue to perform the Contract. For a start, what Atos was willing to do was "to complete the project on a time and materials basis at our own internal standard rates". That is an expression of an intention to complete the work on different terms, not upon the terms originally agreed. Second, this offer was itself subject, amongst other things, to DB's agreement to waive any claim that it may have against Atos in relation to Atos's delivery to date. That also was something upon which Atos had no right to insist.
231. The fact that Atos repeatedly asserted its willingness and wish to complete the project is neither here nor there. There is a very significant difference between being willing to complete a project, and being willing to fulfil a contract. Atos may have been genuinely prepared to do the former, on its own terms, but that was itself inconsistent with a willingness to do the latter. Even if, contrary to this finding, Atos was in fact privately prepared to continue to perform the contract, that intention was never communicated to DB; nor would a reasonable person in DB's position have understood that to be the case.
232. However, at paragraphs 196 and 197 of his Closing Submissions, Mr Lewis made the following submission:

"196. . . . Alternatively, if [Atos] was, on the facts of the case, contractually entitled to do something short of what it did, then DB must show that the difference between what [Atos] did and what it was contractually entitled to do deprived it of substantially the whole benefit of the Contract.

197. If [Atos] was entitled to suspend pursuant to clause 12.5 of the Contract, then it was entitled to suspend "until such time the due amounts are paid" to it. When, on the facts of this case, would that have been? The clear answer . . . is that DB had no intention of paying any further sums to [Atos] until it demonstrated that it was delivering to plan (and to quality) and (on the facts of the case) that was not going to happen. It was not going to happen in relation to the March/April re-plan because (in the reported words of Mr Newell, that would have taken a miracle) and it was not going to happen in relation to any other re-plan because DB showed no intention of agreeing to any such re-plan (or even making a counter-proposal to [Atos])."

233. In my judgment, the principal defect in this ingenious submission is that it is based on speculation. I consider that the best evidence of DB's intentions in relation to making any further payment to Atos is reflected in what Mr Newell said to Mr Bray on 16 May 2008 - as summarised in Mr Bray's e-mail of that date, the relevant terms of which I have set out at paragraph 146 above. I have little doubt that if Atos had threatened to suspend work until the outstanding invoice was paid, DB would have paid it without further argument. Even if DB had decided to call Atos's bluff, and wait until it actually suspended work before making the payment, I consider that it would have made the payment immediately the suspension of work took place.
234. I have reached this conclusion partly because, as a matter of commercial reality, I very much doubt whether DB's management would have been prepared to play for such high stakes and risk losing the contract, and partly because, having seen and heard him, I did not consider Mr Newell to be the sort of man who would take the very serious step of continuing to withhold payment of the invoice in those circumstances. He would have appreciated exactly what was at stake.
235. Further, I have doubts as to whether Atos would have been prepared to suspend work simply because an outstanding invoice had not been paid. The evidence from the Atos witnesses showed that if work was suspended for any longer than one week it would become very difficult to put the project back into motion. By suspending work for anything more than a few days Atos might well have put itself in a position where it could not resume work on the project without incurring further delay and significant cost. Whilst the outstanding payment was not insubstantial, being some £350,000, to a company of Atos's size the possible benefit of achieving immediate payment might well not have been worth the risk that any protracted suspension of work would carry. I find it difficult to believe that Atos and its lawyers did not consider the option of exercising the right under clause 12.5 to suspend work until the outstanding invoice was paid. I am sure that they did consider this option, but I suspect that Atos did not pursue it for the reasons that I have given.
236. For these reasons I am left in no doubt whatever that, by its conduct between 21 May and 6 June 2008, Atos evinced a clear intention not to be bound by the contract any further and thereby repudiated it. That repudiation was accepted by DB in its letter of 9 June 2008.

The test for assessing a valid Change Request

237. This was a strongly contested issue. In his first report Dr Martyn Thomas dealt with the question of increases in scope in the following terms:

"53. There are two types of change that may increase the scope of work in a project.

54. The first type are changes that introduce functionality that was clearly outside the scope of the project when it was planned, and which may even have been explicitly stated to be out of scope.

55. The second type are changes that add scale or complexity to the work that was legitimately envisaged on the basis of the stated requirement, but that do not extend the required functionality into wholly new areas. These changes are often contentious because the customer may have understood the complexity from the start of the project and assumed that the supplier did too and based any estimates and plans on this understanding, whereas the supplier may legitimately have understood the requirement to be something far simpler than it subsequently transpires that the business actually needs.

56. . . .

57. One test for this second type of scope increase could be to ask "is there a reasonable solution that meets the stated high level requirement, and at a significantly lower cost or effort than the minimum solution that would meet the business requirements as revealed by a detailed analysis?". If the answer is "yes", then the additional complexity is a scope change of the second type, described above at paragraph 55, and if it is material it should be the subject of formal change management."

238. Both experts agreed that Dr Thomas's paragraphs 53-55 correctly represented the position. These two different types of scope increase are sometimes referred to as changes in breadth and changes in depth, respectively. Changes in breadth are, effectively by definition, true changes in scope. The difficulty in this case is that it is accepted that many of the changes are changes in depth, and not changes in breadth: where there were clear changes in breadth, such as in relation to Splitting, DB has accepted that Atos is entitled to claim additional cost under the terms of the contract. Changes in depth are sometimes referred to as "scope creep".
239. I can understand how Dr Thomas's test might work if it is applied to a business model that is fairly well understood, such as time recording and billing in a firm of, say, solicitors or accountants, where there might be a "minimum solution" that could meet high level requirements that involved relatively straightforward processes but which would not meet a more elaborate set of requirements.
240. The difficulty here, as more than one Atos witness accepted, is that DB's operations are unique. It seems to me, therefore, that Atos (or any other supplier) was not in a position to form a legitimate view as to what DB would require or what might constitute a reasonable minimum solution. For these reasons I cannot accept, in the context of this case at least, that Dr Thomas's test is likely to prove an appropriate one for anything other than the most straightforward changes.
241. It seems to me that the only test must be one that is case specific to this particular transaction. If a business process that DB says it requires can fairly be said to fall within the activity described in one of the documents (the "RDDs", which include the Architecture Blueprint) listed on the first page of Schedule 2 then, in my judgment, it is likely to be within the scope of the RDDs. For example, the process of Splitting (by which aggregated diamonds are split up into a number of boxes) obviously did not fall within the activities described in any of the RDDs, which is why it became the subject of an agreed Change Request.

The individual claims in relation to changes

242. I will address Atos's various claims more or less in the order in which they are set out in Appendix 1 to the Defence and Counterclaim (but ignoring those for which no sum is claimed). The numbers in the headings which follow reflect the paragraph numbers in Appendix 1.

The differences between South African countries (SACs) (1)

243. Paragraph 1.1 of Schedule 12 provided that there would only be "minor configurations and customisation" to address the requirements of DTC International, DTC London, DTC Botswana, DTC South Africa and DTC Namibia.
244. I mention below various PRs in which there are references to differences in documentation and practices of the various SACs, not only between each other but also between themselves and London and DB International.
245. In relation to the differences between the SACs, Mr Adelman said the following in his first witness statement:

"15. The perception following the trip to Botswana that there were no significant differences between the country's requirements was reflected in the assumption set out in the agreement between DTC and Atos (the "Contract"), i.e. that only a minor configuration and customisation was needed to address DTC International, DTC London, DTC Botswana, DTC South Africa and DTC Namibia requirements.

16. In practice, there were extensive and significant differences between the practices and processes of the SACD users, which resulted in additional work to capture these requirements.

17. The customisation required for the SACs impacted across the entire project. It was certainly not just a case of there being a difference in the format of documentation that was required. In some instances, particular aspect of the process were not required for a particular country, for an example the Prepare Packets and Packaging Goods requirements did not apply to Botswana.

18. In other cases, the process was the same, but the way in which the task was carried out was different, for example in Botswana goods were not packed in Trunks Liners and Packets, instead they were to be moved in pots and tins."

246. Mr Adelman said that at some stage in early 2008 he was asked by the Project Manager to record the differences between the SACs that had become apparent during the fast-track requirement workshops and he set these out on a spreadsheet. Mr Adelman estimated that he spent 15-16 days in dealing with the differences between the SACs. In cross-examination Mr Adelman's evidence on this issue was not shaken and I accept it.
247. I consider that, taking the evidence as a whole, there was a breach of the assumption in relation to the differences between the SACs. Atos claims that almost 450 man days was a spent dealing with the differences between the SACs. I strongly suspect that these hours include time spent dealing with all differences between the SACs, and not just the differences that are outside the scope of the contractual assumption. I regard it as virtually impossible to arrive at the calculated figure to reflect the value of Atos's claim under this head, but I am confident that the claim has been significantly overstated.
248. Doing the best I can in the light of all the evidence that has been given, I consider that a figure of about 200 man days would be more appropriate. I include within this figure all claims by Atos in respect of the differences between the SACs, even if they have been made in a different place in the Defence and Counterclaim. In terms of value, I assess this claim at somewhere between £125,000 and £150,000.

The assumption in relation to network bandwidth (2)

249. I consider that this was an item of expenditure that Atos would have incurred in any event, for one reason or another. On 13 September 2007 there was an internal Atos meeting attended by, amongst others, Mr Connor, the Technical Architect, in which he explained:

". . . that key decisions over how much the A and EAI architecture (modules) resides down south and how much in the UK, is dependent on the outcome of a visit by Atos to the Microsoft facility in Reading, scheduled for the 11^th Oct, when Atos will [be] carrying out network tests, which will identify the required bandwidth."

250. When Mr Cotter was asked about this in cross examination, all he could say was that Mr Connor must have got it wrong and was very overoptimistic to think that such tests could be carried out at that stage of the development of the software. I do not find this a very satisfactory explanation.
251. The claim is in respect of tests that were carried out in a performance laboratory in February 2008. About these tests, Mr Roberts said (at Day 10, 98/22 - 99/2):

"A. Now, what I am saying here is that if the architecture was going to change with a reasonably fundamental change to having a workflow engine rather than a piece of code, then really we should go back and revalidate that the performance was acceptable and it didn't necessarily slow down the users access."

252. In the light of this material, I consider that Atos's claim under this head is unsustainable.

The introduction of the EDS (3)

253. The Enterprise Data Store was introduced by DB in December 2007. At paragraph 60 of his first witness statement Mr Aythora said this:

"In order to assist [Atos] and to make it easier for [Atos] to interface with other parts of the Legacy Systems and reduce the integration complexity of the Project, in December 2007 [DB] decided to create a central repository known as the Enterprise Data Store ("EDS"). One of the benefits of EDS was that, rather than having to build interfaces to lots of existing components, [Atos] would only have to create one data interface. Another benefit was that the data formats could be standardised. The creation of this "data warehouse" was a substantial piece of work involving consolidating and translating data from a variety of sources. The development of EDS by [DB] was to take place over a number of months. The first set of deliverables was addressed by January 2008 and work on EDS was generally done in a collaborative and timely fashion between [DB] and [Atos]."

254. Mr McKendrick's evidence was to similar effect. He said, in his first witness statement, at paragraph 165:

"At around this time [December 2007], [DB] and [Atos] were working together to define the EDS data model and to ensure that the reference data was sufficient for the purposes of [Atos's] system testing. [Atos] had to inform [DB] what was required in order that their requirements could be incorporated into EDS."

Neither Mr Aythora nor Mr McKendrick was cross-examined about either of these paragraphs. This was, perhaps, not surprising, because Dr Thomas has concluded that the introduction of EDS was not a breach of DB's obligations (1^st report, paragraph 353).

255. On 3 January 2008 a Mr Dmitri Gryzlov, of Atos, sent an internal e-mail to announce the coming into operation of the EDS and explaining how it would work. A reply from Atos India the following day thanked him for the information and noted that the main challenge would be to simulate the environment for the EDS in India in exactly the same way as it was configured in the UK, so that code written by Atos India during the development phase would work seamlessly in the testing environment during the testing phases without unnecessary code changes.
256. In support of this claim Atos has not identified any contemporaneous document in which there was any complaint by Atos to the introduction or operation of the EDS. However, in his oral evidence Mr Cotter said that he thought that the introduction of the EDS was a tactical ploy by Mr Aythora to enable certain functionality to be delivered more quickly, and that it was an expedient step which would ultimately have increased Atos's effort whilst producing a very clumsy system (Day 10, 40/10-14 and 41/1-4).
257. Mr Cotter was then shown an e-mail dated 16 May 2008 from Mr Gryzlov to a large number of addressees, including Mr Cotter himself, in which he wrote:

"Dear all,

After numerous discussions between [DB) and [Atos] architects, it has been finally decided that EDS reference tables from now on will be residing inside the SCMS database.

I have already created the EDS table structures inside SCMS - please use them in your new stored procedures henceforth . . .

. . .

Please let me know, if you have any concerns or queries regarding this change."

258. In a short reply on 20 May 2008 Mr Cotter wrote:

"A small clarification.

Copies of the EDS tables will reside in SCMS.

EDS is still owned by [DB] and are responsible for mastering the data."

259. Faced with this, Mr Cotter was eventually driven to say that he remembered going to speak to Mr Gryzlov, who sat just across the room from him, and explaining to him the ramifications of the change. I do not accept this evidence. It may be, as it turned out, that the EDS was more of a hindrance than a help, but whether or not that was the case (which I do not need to decide), I am quite satisfied that it was introduced with the knowledge and agreement of Atos (or, at least, not in the face of any objection) and that DB's purpose in setting it up was that given by Mr Aythora.
260. Accordingly, I find that the introduction of the EDS was not a breach of contract and does not give rise to any claim by Atos.

The changes in relation to finance requirements (4) and (6)

261. I have already mentioned that the issue of DB's finance requirements was a running sore throughout most of the project. DB's finance department either did not know or would not make up its mind as to what it wanted.
262. At paragraph 221 of his first witness statement Mr McKendrick said:

"On 11 February 2008 Liz Allan sent a meeting invitation to discuss the finance requirements, and, in particular, how statements of account were to be recorded. After all of my previous discussions and now, having "missed" the deadline for 8 February 2008, it was clear that the finance requirements would be a change request and, most likely, chargeable."

A little later, at paragraph 237, he said, referring to late February 2008:

"By this time I was concerned about the approach taken by the finance team. It seemed to me that they were assisting in trying to make the SCMS system accommodate changes which were not part of the original scope and, even though we had given [Atos] clear instructions that they should proceed on the basis of the contract, this issue did not seem to be closed. I was worried that [Atos's] focus was being diverted from more urgent work."

263. In fact, the requirements of the finance department were not signed off until 9 April 2008 and, possibly, not even then. I do not think that it was really in issue that the conduct of DB's finance department in insisting in having certain finance requirements included in the SCMS and in taking so long to finalise them was a breach of contract, in particular a breach of clause 6.1.2. The sum claimed under this head is about £17,000. This is in addition to the claim under CR 013.

The failure by DB in relation to the management of the dependency on the EDS and other matters (5)

264. There were originally three elements to this claim. The second of these, in relation to Box Creation, is now no longer pursued. Unfortunately, this makes any assessment of the value of this claim difficult because the amount of time spent on Box Creation is not separately identified in Mr Culshaw's quantum schedule SWC 2 although one can isolate 8 man days spent by Mr Figoni.
265. It is also unclear to me how much of the time claimed in item 5 of the quantum schedule is attributable to the introduction of EDS, rather than just the management of the dependency on EDS.
266. For reasons which will become clear, I do not consider that it is necessary to embark on the exercise of carrying out a detailed valuation of this claim (if, indeed, such is possible on the material available) because it is sufficient to note that there is a disputed claim under this head, the true value of which is probably in the region of £25,000-£30,000.

DB's failure to meet its obligations with regard to core SCMS (6)

267. In spite of its title, this is the claim in respect of the unavailability of the DB staff (as Mr Culshaw explained in paragraph 69 of his 1^st witness statement). I have already dealt with this claim in so far as it relates to the period up to the end of 2007. However, in relation to 2008 I consider that it is very difficult to make a sensible valuation of this claim because it is impossible to disentangle the additional time spent because of further elaboration of the requirements (being changes in depth which I do not consider to be increases in the scope of the work for which DB is liable under the contract) and the additional time spent on matters for which DB may be liable.
268. Of the total number of hours claimed for item 6 in Mr Culshaw's quantum schedule, which is 433 man/days in total, I consider that 205 man/days is attributable to 2008 (328-161+38 - see paragraphs 102-104 above). This is a little under 50% of the claim under this head with a corresponding claimed value of the order of £150,000.
269. I do not consider that I have sufficient information to form a view as to what proportion of this £150,000 represents recoverable claims by Atos, but in the light of matters considered in this judgment I consider that this head of claim could properly have had a value attributed to it of between £50,000 and £100,000.

The failure to provide regular access to its development and BA resources (9)

270. This claim is for 20 man days spent during March 2008 and by four BAs: 5 man days apiece by Mr Adelman and Mr Figoni, and a further 10 days by two other BAs.
271. In a document prepared by Atos at the end of February 2008 entitled "DTC Positioning Document", Atos prepared a summary of potential claims that it considered could be made against DB. The first issue which was considered directly attributable to DB was described as "Target operating model not sufficiently defined". This was broken down into the following subheadings:

(1) Delays to decision-making.

(2) Volatility in decision making.

(3) Scope creep (65 original process requirements identified in October 2007. By January this had grown to over 100).

(4) Constraints on input from key DTC resources

(5) Operating model differences between territories greater than initially represented

(6) Delays in provision of vital information

(7) Unilateral and un-communicated changes to architectural elements causing AO rework.

272. The final section of the document was headed "Issues not directly attributable to DTC (but which have impacted AO delivery/costs/effort). The one item shown here was that the volume of business analysis was greater than forecast, in that whilst 2 BAs were planned, 10 were required. In evidence, Mr Cyril said that this entry in the document had been prepared by Mr Adelman, as had other entries in the document which had Mr Cyril's initials, FC, against them.
273. One such entry was under the heading "Scope creep", where Mr Adelman had written:

"Other than those which are already the subject of a CR, I do not see any of these being as a result of scope creep. They were just not included as a result of inadequate time spent on planning and estimating."

This comment accords very closely with the view that I have already reached in relation to the claim for changes in process requirements. In addition, it appears to be the basis for Mr Adelman's conclusion that the significant increase in the number of BAs was a cost that Atos should bear itself.

274. I consider that Atos does not have a claim for the cost of the additional eight BA's that were brought into the project. In my judgment, the need for nearly all of those additional BAs arose because Atos had significantly underestimated the complexity of DB's processes and the responsibility for that underestimate is one that, very broadly, must be borne by Atos (save for those cases where there was a genuine increase in scope). If Atos had appreciated the complexity of DB's processes from the outset, I consider that it would have substantially increased its planned resource of BAs - if not up to a total of 10, probably by a further 4 or 5. If these extra BAs had been introduced from the outset, then I doubt if a further 7 or 8 BAs would have been required in January 2008.
275. I consider that Atos probably has a claim under this head, because it was put to extra cost by the lack of ready access, but I would not assess it as being worth more than £20,000. This head of claim is closely connected with that under (16), and I have borne this fact in mind.

The failure to provide a list and specification of devices and peripherals (15)

276. This is a claim for some 26 man days in the sum of about £20,000. 50% of the time claimed is for BAs, and 50% for designers. The comments that I have made in relation to the previous claim largely apply to this claim also.
277. I consider that Atos probably does have a claim under this head, because I am satisfied that there were delays by DB in providing the relevant information, although if Atos had had additional BAs on the project from the outset, a substantial part of the amount claimed under this head would have been part of the project cost. The claim is again for just under £20,000, and I assess it is having a value of about £10,000.

The failure to provide access and make available key DB resources (16)

278. This is a claim for a total of 130 man days wasted between January and June 2008. The sum claimed is just over £110,000. I have considerable reservations about the manner in which this claim has been assessed for the reasons that I have already given in relation to the claim for time wasted between September and December 2007.
279. It is again very difficult to separate out time which has really been wasted from time that is really attributable to the increased complexity of the requirements. In these circumstances the court can only make an informed assessment of the probable value of this claim, and my assessment is that it probably had a true value of between £25,000 and £50,000.

The failure to provide access to the Legacy Systems (17)

280. This claim is closely tied up with the following claim, claim 18, and it is convenient to deal with them together. The sum claimed for both claims is a little under £30,000.
281. There is relatively little evidence on this claim and, given its relatively modest value, I do not consider that it justifies exploration in depth. I consider that the parties would probably have attributed a value of between £15,000 and £20,000 to these two claims.

The failure to provide technical documentation in respect of the Legacy Systems (18)

282. I have dealt with this under the heading of the previous claim.

The failure to provide business processes that were complete or contained sufficient detail (20)

283. This claim is in respect of the level 5 process maps that were inaccurate or incomplete. I reject this claim in its entirety, because the inadequacy of the level 5 process maps became apparent during the IAP and I cannot see how Atos can found a claim on the basis of matters that were known to it at the time when it entered into the Contract.
284. It seems to me that this is a clear example of a lack of liaison between the Atos employees who were responsible for carrying out the IAP and the commercial side who were responsible for arriving at the estimate for the contract price. In short, it was a failure of internal management for which Atos has no one but itself to blame.

Changes to Process Requirements - PR 12(21)

285. The RDDs set out in Schedule 2 to the Contract each contained one or more Process Requirements ("PRs"), which in turn contain a succession of steps. Each step represented either an action by the operator (usually interacting with the computer system in some way) or something done by the system itself. The PRs sometimes included alternative scenarios to deal with situations that either did not occur often or might be unexpected.
286. PR 12 is part of the RDD known as Rolling Management Requirements. I take it separately from the other PRs because it was explored in some depth in the course of the evidence and is therefore a good PR to take by way of example. In version 1.0 of this document, which was approved on 10 October 2007, the Rolling Management was divided into four PRs: PR 11, PR 12, PR 13 and PR 14. PR 12 was "Prepare and Layout Goods for Rolling". In version 1.0 PR 12 consisted of 16 steps, each one described in a few lines of text. Steps 3 to 6 concerned re-pricing.
287. Following the fast track requirements gathering workshops in January and February 2008, version 2.0 was issued on 5 February 2008. In this version PR 12 was reduced to 12 steps: steps 3 to 6 of version 1.0 had been removed and were replaced by a new step 3 - "Establish Output Valuation IDs". However, the description against each step had been expanded enormously in version 2.0. As an example, Dr Thomas has pointed out that step 2 went from four lines in version 1.0 to almost four pages in version 2.0. Dr Thomas described version 2.0 as "substantially more complex than version 1.0 despite having the same number of steps". In fact, it did not have the same number of steps: as noted above, there were 12 steps in version 2.0, not 16. Dr Thomas said also that the activities in PR 12 differed significantly between different DTC entities in version 2.0, but not in version 1.0.
288. I do not wholly follow the last point made by Dr Thomas, because the only references that I can find in version 2.0 to differences between different countries are in the Assumptions. Assumption 2 to the module as a whole reads as follows:

"Through the login (see Assumption 1) the system can:

detect if rolling is therefore being done at a specific Entity (i.e.: specific LSO or at DTC-I level) and hence there is no need for the user to enter/select DTC-I or LSO as part of the rolling process

ensure that only Documents relevant to the specific LSO or DTC-I are available through RMS ie: if rolling is being done at South Africa then they are only selecting/rolling Documents, and hence goods, that relate to South Africa and are not picking up ones for Namibia for example. This is NFR 3.1.3."

Assumption 2 to PR 12 reads as follows:

"Within PR 12 the system cannot select the default FRG Table as these are different for DTC-I/LSOs (currently there is a FRG Table for DTC-I, one for LSO-South Africa, one for LSO-London for Canada and one for the rest of the LSOs).

Note: This RDD describes the FRG Table/Levels and Groups as they currently exist as it is understood that this will be retained in the new system."

289. It seems to me that what these are saying is that the system will detect whether the rolling is being done and will therefore ensure that only Documents relevant to that place are available through the system, whereas the user will have to select the FRG Table that is appropriate, rather than being able to rely on the system to select the appropriate table (because there is no similar match between the appropriate FRG Table and the different countries). However, the point was made more clearly by Mr Adelman in his first witness statement. He explained that a significant issue that had to be addressed was the different way in which the rolling and weighing processes were carried out in the different DB entities. The question of the extent to which there were different practices in the South African Countries is an issue with which I deal elsewhere in this judgment.
290. The other point raised by Mr Adelman that is relevant to PR 12 was in relation to re-pricing. At a meeting on 21 November 2007 Mr Adelman and Mr Figoni discussed this topic with representatives from DB. The Discussion Record contains the following entry:

2) Changing Prices

Prices may change at any point in the cycle. When this occurs a new generation of the price book will be created and the selected price book for the current cycle will be changed. Geoff suggested that changing the price book, should result in automatic revaluation of all of the stock. This was agreed to be more appropriate than any need for specific pipeline milestone revaluations. As a consequence, the re-pricing requirement within rolling management can be removed. We discussed the prospective problem that goods may be allocated to a process at a time that the price book is changed. Ralph stated that the stock recorded from the outcome of the processes to which there were allocations would automatically be valued using the new price book. We considered ways to ensure that this was not an issue but this will need to be addressed in more detail."

291. The effect of this, according to Mr Adelman, was described at paragraph 76 of his first witness statement as follows:

"This significantly extended the analysis period as Atos had to remove relevant steps in the processes and change the price maintenance and valuation requirements. This impacted not only on the Valuation processes but also Rolling Management and Prepare and Hold Sight which previously had re-pricing process steps."

292. However, the Requirement Notes for version 1.0 of PR 12 contained the following entry against the subject of Financial Impact: "There is still a need to capture the impact and required processing when goods are repriced. Credit/Debit notes may be required and the BV of stocks amended accordingly". This referred to steps 3 to 6 of version 1.0 of PR 12 which were subsequently removed. It is not at all obvious, and I decline to infer, that the elaborated requirements for those steps would have been any less complicated than those that were substituted in the later versions of PR 12. Leaving aside the question of whether or not this change amounted to a change in scope, to which I turn in the following paragraphs, I am not satisfied that this change actually increased the overall work involved. It may have done, but there is no evidence of it.
293. The next question is whether the removal of steps 3 to 6 in version 1.0 and their replacement by step 3 in version 2.0 constitutes a change in the scope of the work required under the contract. Before dealing with this, I should say by way of introduction that PR 12, version 2.0, provides a good example of the complexity of DB's operations and the skills required of the BA (in this case Jayne Koslow, apparently a highly regarded BA at Atos) who has to identify and analyse (or capture) the relevant business processes.
294. It illustrates also the practical difficulty of applying Dr Thomas's test in this case. No objectively reasonable solution that would meet the high level requirement set out in version 1.0 has been identified (and, I suspect, is not capable of being identified) that Atos could legitimately have thought would meet the RDD for Rolling Management as it stood in PR 12, version 1.0, at November 2007.
295. I am therefore unable to understand how Dr Thomas has applied his own test to this PR, as he says he has done (see paragraph 443 of his first report: "Applying the test in paragraph 57 above . . ."). So far as I can tell, he has simply compared version 2.0 with version 1.0 and concluded, probably correctly, that the level of detail in version 2.0 shows that the PR was very much more complex than was ever envisaged. However, I do not think that this reasoning (if that is what it was) stands up to analysis. Version 1.0 was known to be at a very high level of generality because Atos had been unable to achieve more than this in the time available during the IAP. The fact that it was in headline form only in itself provides no clue to the actual level of detail that will be found to be contained within the identified steps when fully analysed. Unless there is some identifiable reasonable minimum solution that a supplier could legitimately assume would meet DB's requirements, as set out in version 1.0, then the detailed requirements as eventually captured will be what they are, no more and no less. If, in those circumstances, Atos contracts to provide a system that will support those detailed requirements, whatever they turn out to involve, then - absent any contractual safeguards - it seems to me that it takes the risk that they will turn out to be more, rather than less, complex than it had anticipated at the outset.
296. In the case of PR 12, I consider that version 2.0 represents an elaboration of the requirements that had been identified in headline form, in version 1.0, at the time when the Contract was made and consequently that they do not represent a change in scope.

Changes to Process Requirements - other PRs (excluding SAC related PRs) (21)

297. The time available at the trial did not permit examination of the PRs except on a sample basis. I have dealt with PR 12 in some detail because that was a PR that was explored at some length during the trial.
298. In relation to PRs 2, 4, 5, 6, 14, 15, 17, 18, 23, 26, 31, 36, 37, 42, 53, 60 and 61, Dr Thomas has in each case carried out a comparison between the complexity of the final version of the PR as against the version that was current when the contract was entered into and, if the later version was found to be significantly more complex than the version that existed at the time when the contract was entered into, Dr Thomas has concluded that the changes represented a change in scope. Although he says in each case that he has applied the test set out in paragraph 57 of his report, as was the case with PR 12, he has not identified any lesser solution that would have met the high-level RDD that existed at the time when the contract was made.
299. I am therefore left to conclude that what in truth Dr Thomas has done is no more than an analysis of relative complexity as reflected in the detail of the various steps between the version of the PR in force at the time when the contract was made and the final version. For the reasons that I have given in relation to PR 12, I consider that this of itself does not indicate that there was necessarily a change in scope. I am therefore not satisfied that, even applying the test proposed by Dr Thomas for a change in scope, any of these PRs would have met it.
300. In respect of PRs 31 and 42, Dr Thomas has noted that there was added functionality during the course of the work. In the case of PR 31, there is a brief Discussion Record dated 5 February 2008 in which it was confirmed that the credit note should contain the same details as the invoice and that it would be produced by the Buy Back process. It was noted that a further meeting would be required with the relevant parties in order to discuss the data captured in the invoices, with a view to standardising this as much as possible. In his first witness statement, at paragraph 121.1, Mr Adelman said that the requirements in respect of PRs 23, 25, 26, 27 and 31 "changed significantly" as a consequence of a number of issues, which he lists. The only issue in the list that appears to be relevant to PR 31 is: "Invoice and credit note printing and timing options" and he cited by way of example the Discussion Record that I have mentioned. On the basis of this evidence and the Discussion Record, I am unable to conclude that what emerged on detailed analysis of this PR amounted to a change in scope.
301. In relation to PR 42, Dr Thomas noted that the "Main Success Scenario" (which contains the steps) increased from 9 to 19 steps between version 1.0 and version 1.5. In the Version Control Summary it was recorded that version 1.4 was produced on 22 November 2007 "following walkthrough". This was the second walk-through for that PR, the first having been held in September 2007. There is no reference to any Discussion Record. Mr Adelman, at paragraph 123.1 of his first witness statement, said that PR 42 was affected by the complexity of the SKU Selection Criteria for the newly created fixed price model, as recorded in a Discussion Record dated 9 November 2007. The latter document does make the requirement more elaborate, but it seems to me that the detailed complexity that may have emerged in version 1.5 was probably the result also of the walk-through in November 2007. This seems to me to be part of ordinary design development, and I can find nothing in the material that I have seen that indicates that there was any change in scope, even if there was added functionality in respect of the SKU selection as Dr Thomas says.
302. In relation to PRs 3, 20, 21, 25, 27, 59, 62 and 63, Dr Thomas has concluded that there was no increase in scope and accordingly I do not consider these PRs any further.
303. In relation to the PRs for Framework and for Export for Aggregation, Dr Thomas failed to identify any relevant background for supporting information and was therefore unable to reach any opinion as to whether the work claimed should be properly considered to be a change. This was an entirely proper approach for an expert to take and I, like Dr Thomas, can reach no conclusion on this PR.

The introduction of new Process Requirements (19)

304. In relation to PR 68, although it was first created after the contract was entered into (and therefore not included in Schedule 2), Dr Thomas said that "the need for a way to maintain year, cycle and price book data was reasonably foreseeable but this PR is more complex than would reasonably have been expected at the time of Contract signature" (paragraph 407). It seems to me that if this process was foreseeable from the outset, then the fact that it proved more complex than envisaged is irrelevant. Dr Thomas has not said that there was any simpler way in which this process could have been carried out and so the alleged change does not satisfy his own test. I find that it was not a change. The same reasons and conclusion apply also to PRs 80, 126 and 127.
305. In relation to PR 72, Size Band Maintenance, Dr Thomas said in his first report that this was not reasonably foreseeable at the time when the contract was signed (at paragraph 411). However, in cross examination he said that it clearly fell within an area that was covered by one of the RDD's and "therefore is, I would say, a depth change rather than a breadth change" (Day 13, 105/16-20). He then agreed that it was a paradigm example of one of the consequences of the failure to identify DB's requirements in sufficient detail at the outset. In the light of this evidence, I do not consider that this PR met Dr Thomas's own test for a change in scope. In my view, it fell within the scope of the initial requirements.
306. PR 75 was part of the Audit Requirements. Dr Thomas considered that the May 2008 version of PR 75 was not significantly different from the audit requirement described in AN-RQ006 in August 2007 version, but he said that the latter showed substantially more complexity than would reasonably have been expected from the Architecture Blueprint. Again, it seems to me that if this process was foreseeable from the outset, then the fact that it proved more complex than envisaged is irrelevant. Dr Thomas has not said that there was any simpler way in which this process could have been carried out and so the alleged change does not satisfy his own test. I find that it was not a change.
307. PRs 82-93 and 95 were part of the Enquiries Requirements. This document was first created in January 2008, well after the contract was entered into. These requirements were therefore not included in Schedule 2. Dr Thomas says that the Architecture Blueprint would have indicated that some ability to make enquiries was required, but that the specification at the time when the contract was made would have allowed a significantly simpler implementation than that defined in these PRs. Although Dr Thomas has not specified of exactly what the original scope would have consisted, it seems to me that he has followed the approach of his own test. His view is that about one third of the cost claimed would have been incurred by Atos in any event in order to meet the scope that they could legitimately have expected.
308. Since these PRs clearly did not form part of the RDDs set out in Schedule 2, in the circumstances I consider that they do constitute a prima facie change in scope. However, for the reasons given by Dr Thomas, I accept that some provision should have been made in relation to enquiries. I have no reason to conclude that Dr Thomas's estimate of the quantum - about 65 man days - is not a reasonable one and so I accept it. Since this is development work, applying Dr Thomas's rate of £270 produces a value of about £17,500.
309. There are several PRs where the need for elaboration or change arose as a result of processing differences between the SACs that emerged on more detailed analysis. I have dealt with these PRs separately (they are PRs 70, 71 and 74). In addition, Dr Thomas did not consider PRs 69, 73 and 78 to be changes and so I do not consider those further.
310. Of the three remaining claims in this category, the claim in respect of FWK (Framework) is, in the opinion of Dr Thomas, partly - to the extent of about one half - in respect of work that would have been required in any event. Since the other half is justified on the basis of Dr Thomas's conclusions in relation to the other PRs, I cannot say that there is any significant element of it that would survive the findings that I have set out above. I therefore attribute no value to this claim. The same goes for the claim described as being in respect of "St Supp". As to the claim described as being in respect of "CM", Dr Thomas was unable to identify the basis for this claim and, accordingly, neither am I.

The Architectural and Code Review (23)

311. This claim is for a little under £100,000 for time spent during April 2008 in preparing a formal response to DB's Architectural and Code Review. In fact, no formal response was ever submitted to DB. I note with some interest that it includes 10 man days by Mr David Cunningham during April 2008, which is before he had even been called in to investigate the state of the architecture.
312. I reject this claim in its entirety. Although I do not condone the manner in which DB sprang this review of the technical architecture and coding upon Atos (about which I accept the evidence given on behalf of Atos), there is no doubt in my mind that, as at the beginning of April 2008, the state of the development of the architecture and of the coding was unsatisfactory, as Mr Cunningham's investigation in May 2008 clearly showed.
313. As to the claim for the time spent on workflow assessment, I have already considered the problem of the workflow engine elsewhere in this judgment. I have already concluded that the need to change to a workflow engine was the result of the initial failure by Atos to appreciate the complexity of DB's processes. The assessment that had to be carried out in April 2008 was the direct result of this initial lack of understanding of the project. For reasons that I have given elsewhere in this judgment, I consider that the contractual risk for that rested with Atos.

Change Requests - Appendix 1, claim (24)

314. In this section of the judgment I will consider the 46 Change Requests ("CRs") in respect of which Atos have made claims against DB.
315. In respect of CR 011, CR 016, CR 021, CR 022, CR 023 and CR 033, DB accepted that these were, in principle, chargeable, although no figure was agreed. DB submits that the figures claimed by Atos in this regard would not have been the agreed figures: they say, correctly, that they would have undergone a process of negotiation as envisaged by clause 5. However, had DB behaved properly - as one hopes they would have done, I consider that these CRs would have been valued and agreed in approximately the amounts at which I have arrived in the table below.
316. I accept that an appropriate method of considering how much the CRs would have been worth (once negotiated) might be to correlate - so far as one can - those particular CRs with how much ThoughtWorks was charging for providing the same functionality (obviously save in those cases where what is being claimed is not the developed functionality itself but rather detailed analysis).
317. It emerged from the cross examination of Dr Thomas that in some cases this comparison suggested much higher figures were being claimed by Atos then ThoughtWorks ascribed to the same work. I bear this in mind when assessing the value of the CRs.
318. Before turning to the individual CRs, I will, for convenience, set out the relevant provisions of clause 5 again:

"5.4 The Customer may request the Supplier (and the Supplier may recommend) to supply Additional Services from time to time. Such Additional Services shall be classed as a "Change" for the purposes of this Agreement and, subject to the Customer and the Supplier signing a change control note ("CCN"), the Supplier will provide the Additional Services to the Customer from the effective date of the CCN. Unless otherwise agreed in writing, the agreed Additional Services will become part of the Services.

. . .

5.8 The parties shall bear their own costs in connection the preparation of all documentation and negotiation of Changes."

Additional Services were defined as meaning "additional services to be provided by the Supplier as agreed between the parties pursuant to the Change Control Procedure".

319. It seems to me that the application of these provisions may depend on which party initiates the CR. In the ordinary course of events I consider that clause 5.8 must apply in every case to the initial costs of the party which has initiated the Change. However, it does not follow that it must also apply to the Supplier's costs in every case where the Supplier is asked to investigate the implications of a potential Change or to prepare an Impact Assessment.
320. Schedule 10 to the Contract provided that the parties were to follow the Change Control Process described in the document "Change Control Process Version: 1.0 Baseline" dated 24 September 2007. This document is not easy to understand, but under the heading "Initial acceptance and prioritisation" it says:

"The Change Request should contain sufficient information to allow the Change Control Board to assess the importance, relevance and potential impact of the Change.

However, most changes will require detailed investigation before the Change Control Board can make a decision. If the Change Control Board decides to authorise the investigation, it determines its priority and records its decision on the Change Request together with any change in preferred Release, where appropriate ..."

321. Under the heading "Management of Impact under the direction of Change Control Board", the document says:

"The Change Control Board will manage the impact analysis and outcome proposals of Change Requests.

. . .

The Configurations Librarian (PNO) will assist in determining the items that require changing. However the Change Manager should ensure that no stone is left unturned in identifying items that may be impacted."

322. In his witness statement, Mr Cyril said that he revised the change control process in conjunction with DB, in the form shown in a flowchart contained in the bundle, and that the change control process had the following stages:

• Initial Evaluation: this would be referred to the Change Control Board to evaluate whether it was a change or not and, if so, whether it was something that should be investigated further by way of an Impact Assessment.

• Impact Assessment: at this stage Atos was to carry out a preliminary review of the Change in order to give a firm estimate for the Detailed Assessment stage and then indicative estimate in respect of the Design, Development and System Testing Stage.

• The Detailed Assessment/Detailed analysis: this was the detailed assessment of the proposed Change to be carried out by Atos.

323. It seems to me that the three stages of the process set out above, save possibly for the first, do not fall within clause 5.8 of the Contract. I consider that the costs that are referred to in that clause are the costs of putting together the initial Change Request and the time spent in negotiating the value of the change.
324. However, if the CR is not initiated by Atos, then it will only incur costs in relation to the CR if it is specifically requested to carry out work on a possible CR by DB. Such a request would, in my judgment, be a request to supply Additional Services under clause 5.4.
325. If, for example, DB asked Atos to carry out an impact assessment of the effect of a change that DB was considering, then Atos would be entitled to be paid for the work carried out in preparing that impact assessment.
326. I now propose to consider each of the CRs, apart from the two that are agreed (CRs 003 and 008), bearing these principles in mind and the respective submissions of the parties (in particular the very helpful table that is appended to Atos's closing submissions), and I summarise my conclusions in the following table.

CR No	Observations	Valuation
CR 001	This CR was initiated by DB. It was subsequently overtaken by CR 003 and therefore closed. Since DB requested the Impact Assessment, it should pay for the work carried out at its request which was subsequently rendered abortive. I accept that 5 days work prior to termination is reasonable. I accept Atos's figure. There may have been some work after termination (possibly 8 days).	4,722
CR 002	This CR was initiated by DB. It is confined to half a day's work for investigation only. I consider that this is reasonable and I accept Atos's figure.	472
CR 004	This CR was raised by Atos. The final claim is for half a day's work for investigation only. I value it at nil.	0
CR 005	I consider that this was probably a legitimate change. Whilst there would have been a need for periodic re-calibration of scales, the need to do it each morning and each afternoon might not reasonably have been foreseen. In an e-mail dated 6 April 2008 Mr McKendrick appeared to accept this. I accept Atos's figure (which is only marginally higher than the figure suggested by DB). There may have been some work after termination.	17,287
CR 006	As for CR 004.	0
CR 007	As for CR 004.	0
CR 009	This has been valued by Atos at nil.	0
CR 010	DB agreed that this IA needed to be carried out. Accordingly I consider that DB should pay for the work that was done before the CR was closed. I accept Atos's figure. There would have been some work after termination (possibly 15 days).	5,666
CR 011	It was agreed that in principle this CR reflected a change in scope subject to value - which was not admitted. The IA was carried out and assessed the impact as 65 man days and 10 weeks delay. The IA is not a long document but went through three versions. Dr Thomas says that no work was completed after the IA, yet the claim is for 1½ days for the IA and 65 days thereafter. I can do no better than to accept the value suggested by DB of £14,400. There may have been some work after termination.	14,400
CR 012	The 1 day's work on this CR appears to have been requested by DB. I accept Dr Thomas's figure.	472
CR 013	This is the CR for Finance Requirements. DB disputes liability on the ground that it is excluded by cl 5.8. I reject this (for the reasons given above). I accept the estimate of Dr Thomas. There would have been some work after termination (possibly 44 days).	30,382
CR 014	This CR is for Invoice Tracking. DB submits that nothing is due because it was closed. However, the CR was requested by DB and a substantial amount of work was evidently carried out before it was decided to close it. In the draft IA dated 31 March 2008, the impact was assessed at 45 man days to capture the requirements and a further 250 man days development and testing. This implies that these were estimates of future resources. The IA was closed on 2 April 2008, by which time it is self-evident that a further 45 days work (as claimed by Atos) could not have been carried out. I do not accept the claim of 45 days but I consider that the preparation of this I must have taken more than the 3 days shown as "IA Days". I assess it at 15 days, or one third of the amount claimed.	15,110
CR 015	This CR seems to have been initiated by Atos. It is for half a day's investigation only. I therefore reject it for the reasons given above.	0
CR 016	It is accepted that this is chargeable. In the absence of a credible figure from DB (Dr Gifkins suggests about £5,000 - which is too low), I accept the revised figure put forward by Dr Thomas. There may have been some work after termination.	15,074
CR 017	Nil claimed.	0
CR 018	Nil claimed.	0
CR 019	DB has admitted a figure of £19,675, but Atos does not accept that this is a fair figure. Atos says that 25 days was agreed (at £19,675), but that it spent a further 26 days (Mr Ghalib). It is clear from the documents that substantial work was done and, since Dr Thomas has accepted a figure of 45 days all told, I accept that figure.	42,498
CR 020	Atos was asked to proceed with an IA to ensure that there was no impact. The 1½ days claimed is reasonable.	1,417
CR 021	DB asked Atos to fast track this CR, but it was then put back to bundle 3. I accept Atos's figures. There may have been a little work after termination.	1,802
CR 022	This CR is accepted by DB in principle, although no figure has been agreed. DB has put forward no case as to the value of this CR, and I accept the reduced figure put forward in Atos's closing submissions. There would also have been substantial work after termination (which I assess at 125 days).	20,057
CR 023	This CR is accepted by DB in principle, although no figure has been agreed. Again, DB has put forward no case as to the value of this CR, and I accept the reduced figure put forward in Atos's closing submissions. There would also have been significant work after termination (which I assess at 35 days).	20,768
CR 024	Although this CR has been classed as an ER, the Change Control Board did ask for an IA on 14 March before the CR was closed on 2 April 2008. I accept that there was 1 day's work.	944
CR 025	Nil claimed.	0
CR 026	Nil claimed.	0
CR 027	This CR is related to the audit requirements for Splitting, so it is therefore outside the original scope and I accept the reduced figure put forward by Atos. There would also have been substantial work after termination (50-60 days)	44,890
CR 028	Nil claimed.	0
CR 029	The documents show that DB strongly objected to Atos's estimate of the development time required for this CR, but did not challenge that it was a change. The claim includes 19 days that would have been post-termination work. I assess this on the basis of the 13 days pre-termination work estimated by Dr Thomas. There may have been work post termination.	12,277
CR 030	I can find no evidence that this work was requested by DB. I therefore value it at nil.	0
CR 031	This CR was classified as an ER. Mr Culshaw accepted in evidence (Day 8, 114/3-25) that it was agreed that the time that the designation "ER" indicated work that was not a change in scope, but an elaboration of the existing scope. In accordance with that agreement, I value this CR at nil.	0
CR 032	Although 1 day's work is claimed for this CR, I can find no evidence that this work was requested by DB. I therefore value it at nil.	0
CR 033	This CR is accepted by DB in principle, although no figure has been agreed. DB has put forward no case as to the value of this CR, and I accept the claim for 1 day's work.	944
CR 034	As for CR 031 above.	0
CR 035	As for CR 031 above.	0
CR 036	I accept Mr McKendrick's evidence in his second witness statement that this was not a change. I therefore value it at nil.	0
CR 037	This CR is related to Splitting and I accept that it is a change. I accept the reduced figure put forward by Atos. There would also have been substantial work post termination of about 90 days.	48,454
CR 038	The claim by Atos includes substantial work that was to be carried out after termination. I have therefore taken the value of the work carried out before termination, as assessed by Dr Thomas. There would also have been substantial work post termination of about 120 days.	20,305
CR 039	As for CR 031 above.	0
CR 040	As for CR 031 above.	0
CR 041	This CR was raised by DB. I accept that Atos should be paid for half a day's work.	472
CR 042	As for CR 041 above	472
CR 043	I accept that this was a change for the reasons given by Atos in its closing submissions (at paragraphs 308-313, 314). I accept the figure given by Dr Thomas. There would also have been work after termination (25 days)	11,932
CR 044	I accept that this was a change for the reasons given by Atos in its closing submissions (at paragraphs 308-313). I accept the figure given by Dr Thomas. .There would also have been work after termination (30 days)	13,583
CR 045	As for CR 031 above.	0
CR 046	As for CR 031 above.	0
	TOTAL:	344,400

327. As I have noted above, in the case of several CRs there would have been work, in some cases substantial work, during the unperformed period of the contract. It is not possible to make a precise estimate, but doing the best I can and allowing for some duplication I assess that further work as being in the region of 500 man days or, adopting a crude composite rate, having a value of about £250,000. In other words, this is the additional cost that would have been incurred by DB if the Contract had not been terminated.

DB's loss

328. DB's claim, as pleaded, is made up of the following components:

The costs associated with the work which it carried out in modifying its Legacy systems		454,459
DB's IT staff costs related to the ongoing support of the modified Legacy system during the period of development, and the cost of participating in the building of a replacement system		1,100,399 (423,522 + 676,877)
The costs associated with a replacement system (i.e. instead of that which would have been delivered under the Contract had it not come to an end), as follows:
The cost of building the replacement system, based on a quotation from a third-party supplier (ThoughtWorks)		3,946,425
DB's IT management costs in respect of the building of the replacement system		195,147
DB's business staff costs relating to the building of the replacement system		1,268,556
Travel and accommodation for DB overseas staff visiting London		78,855
Travel and accommodation for DB London staff visiting overseas DB operations		166,599
Loss of savings: DB claims that it has been deprived of savings and process efficiencies which it would have enjoyed using the SCMS functions which would have been present on the contracted software which AO should have provided		20,000
Additional interest charges arising from the need to purchase intakes 2 days early (based on a 10% rate of interest)		1,459,314

The claim for the upgrade of the legacy system

329. Following the termination of the contract on 6 June 2008 DB took prompt steps to upgrade its existing legacy system so that it would be able to support the move to Botswana. By that stage the financial crisis had not occurred and DB's concern was to achieve the movement of the aggregation process to Botswana as soon as possible after the end of December 2008. It was clearly not going to be possible to procure a replacement system from an alternative supplier within such a short time and so I accept that the reasonable course for DB to adopt was to upgrade its legacy system so that it could operate on those until it could put in place the replacement system.
330. The modification to the legacy system took place between July 2008 and at the end of January 2009 and the modified system was delivered at the beginning of February 2009. I find that in taking this course DB acted reasonably to mitigate its loss. At the time when the relevant decisions were taken the financial crisis had not broken and, by the time it did, the upgrade of the legacy system was well underway. As I understood the position, Atos did not challenge DB's right to recover the costs of upgrading the legacy system, subject of course to deducting the costs which it would have incurred in any event if the contract had not been terminated by Atos.
331. In addition to the cost of upgrading the legacy system, DB claims also the cost of supporting the legacy system during the period of development of the replacement system. The sum claimed under this head is £423,522, which is shown as a sub-component of item (2) in the summary of the claim set out above. DB accepts that this figure should be revised downwards to £417,153. I am not persuaded that this claim should be reduced further, as Atos contends, simply because DB's claim for the cost of the staff working on the replacement system was overstated. This was not a new project with an external consultant, as the replacement system would have been, and so the considerations are not the same. I therefore accept the amount of the claim as currently put forward by DB.
332. Atos's second argument against the recovery of these costs was that GB would have incurred costs in supporting the new replacement system instead. However, since, for the reasons given below, I have not awarded DB any damages for its own costs of supporting the new system, this argument falls away.
333. DB's claim for the costs of supporting the legacy system is a claim for costs that were actually incurred. They were a natural consequence of the breach and were, in my view, reasonably incurred. Accordingly, I find that they are recoverable.

The claims for the replacement system and the cost of supporting it

334. By the time of the trial DB had not entered into a contract for a replacement system, and, as I have already mentioned, the evidence established that DB had no present budget for this and had made no arrangements for any preliminary steps that it would need to take before procuring a replacement system. The reason for this was not the financial crisis, the effects of which were no longer preventing the move of the aggregation process to Botswana (Mr Page said that this ceased to be a factor by mid 2009: Day 6, 106/17-21), but the undisclosed "blank" issue to which I have already referred.
335. I asked Mr Page whether the "blank" issue was capable of resolution as at May 2010, and he said "Well, I still don't think it's incapable of resolution, but it has become more intractable as time has passed" (Day 6, 111/15-16). However, at the conclusion of his evidence Mr Page told me that, based on many years of experience of dealing with the GRB, he believed that the matter would be resolved next year when the renegotiations for the renewal of the sales contract were due to take place, but that in the meantime DB was in no position to make plans to resurrect the move of the aggregation project until this issue had been resolved (Day 6, 123/15 - 124/8).
336. Understandably, Mr Lewis protested at the course which the evidence had taken in relation to the "blank" issue and submitted that it put Atos in an impossible position because, not knowing what the issue was, Mr Lewis was quite unable either to explore or to mount a proper challenge to the evidence that had been given by Mr Page. I have considerable sympathy with this submission.
337. It is for DB to prove its case, on damages just as much as liability. If it is DB's case, as it is, that the move of the aggregation project to Botswana will take place in the foreseeable future and that DB will procure a replacement system to support the SCMS project, then it is for DB to establish on the balance of probabilities that this will happen. There is no room for any presumption to this effect, and Atos is under no burden to rebut this part of DB's case.
338. Put shortly, I find that the evidence establishes the following:

(1) That since mid-2009 the reason why the aggregation project has not been moved to Botswana is the "blank" issue.

(2) DB currently has no budget for the move of the aggregation project to Botswana, and has made no plans at all in contemplation that this will happen.

(3) The "blank" issue has been an intractable problem for several years and continues to be so. Unless and until it is resolved there can be no question of the aggregation process moving to Botswana.

(4) The only evidence that the "blank" issue may be resolved next year, and that the move of the aggregation project will be resumed, comes from a very brief answer (to a question from the court) at the end of the oral evidence of Mr Page. It is not supported by a single document.

339. Given the history of Mr Page's evidence on this topic, in particular the thoroughly misleading evidence contained in his witness statement, I do not feel able to place any confidence on Mr Page's evidence that the "blank" issue will be resolved next year. For this reason alone, I find that DB has not discharged the burden of proving that the move of the aggregation project will go ahead and that it will purchase a replacement software system to support the SCMS. I must make it clear that this is not a finding that neither of these things will happen - they may or may not - but simply a finding that it has not been proved that they probably will happen.
340. In any event I consider that it would be most unfair to Atos to draw any inferences from the evidence adverse to Atos since Atos is in no position, through no fault of its own, to investigate the facts relating to the "blank" issue. DB has chosen, for what are no doubt perfectly good commercial and/or political reasons, to withhold the information about the "blank" issue. In those circumstances I do not think that it would be either right or fair to draw inferences favourable to DB on this aspect of the case against the interests of Atos.
341. I should add, for the avoidance of doubt and in case it affects any other aspect of the case, that the finding that I have just made does not imply a reverse finding, namely that the aggregation project will probably not go ahead. On the state of the evidence I simply cannot make a finding either way, unsatisfactory though that is.
342. DB is claiming the cost of procuring a replacement system from ThoughtWorks. In the light of my finding that it has not been established that it will probably do so, the question is whether it can nevertheless recover damages represented by the cost of procuring that system. If the answer to that question is yes, then further questions arise in relation to the potential recovery of some of the associated costs, such as, for example, DB's own management and support costs in respect of the building of the replacement system.
343. I now turn to these questions. In Ruxley Electronics v Forsyth [1996] 1 AC 344 - the case about the swimming pool that was shallower than contracted for, but still perfectly usable - Lord Jauncey said, at 358D:

"What constitutes the aggrieved party's loss is in every case a question of fact and degree. Where the contract breaker has entirely failed to achieve the contractual objective it may not be difficult to conclude that the loss is the necessary cost of achieving that objective. Thus if a building is constructed so defectively that it is of no use for its designed purpose the owner may have little difficulty in establishing that his loss is the necessary cost of reconstructing. Furthermore in taking reasonableness into account in determining the extent of loss it is reasonableness in relation to the particular contract and not at large. Accordingly if I contracted for the erection of a folly in my garden which shortly thereafter suffered a total collapse it would be irrelevant to the determination of my loss to argue that the erection of such a folly which contributed nothing to the value of my house was a crazy thing to do. As Oliver J said in Radford v. De Froberville [1977] 1 WLR 1262, 1270:

"If he contracts for the supply of that which he thinks serves his interests - be they commercial, aesthetic or merely eccentric - then if that which is contracted for is not supplied by the other contracting party I do not see why, in principle, he should not be compensated by being provided with the cost of supplying it through someone else or in a different way, subject to the proviso, of course, that he is seeking compensation for a genuine loss and not merely using a technical breach to secure an uncovenanted profit."

However where the contractual objective has been achieved to a substantial extent the position may be very different."

344. That seminal statement of principle by Oliver J in Radford v. De Froberville has been approved by Lord Goff and Lord Millett in Alfred McAlpine v Panatown [2001] 1 AC 518. In relation to the latter case Stadlen J commented, after an extensive review of the authorities in Van de Garde BV v Force India Formula One Team (formerly Spyker F1 Team) [2010] EWHC 2373 (QB), at 484, that it

"is not authority for the proposition that it is a precondition of recovering damages for failure to supply services to the claimant in breach of contract that the claimant must have purchased, or at least expressed an intention to purchase, elsewhere the services wrongly withheld."

345. Unlike the situation in Panatown, this is not a case where the claimant contracted for the provision of services to a third party. In this case, DB was buying the services for itself. If there is substantial non-delivery of those services, as there was in this case at the date of termination, then DB is entitled to recover the cost of purchasing elsewhere the services not provided, unless it would be unreasonable of it to do so. Provided that it would be reasonable for a person in the position of DB to purchase those services elsewhere, it does not matter whether or not DB has an actual intention of doing so or has not made up its mind whether or not to do so.
346. I have no doubt whatever that it would have been and would be reasonable for DB to purchase elsewhere the services that were not, but should have been, provided by Atos. It had, and still has, a genuine need for those services.
347. However, in my view different considerations apply to the costs that DB would have incurred by way of payments to its own employees during the development and implementation of the replacement system if it is not shown that it will ever purchase a replacement system. I think that there are two aspects to this.
348. First, these are costs of a type that DB would have incurred in any event. Had the contract been performed by Atos, DB would have maintained its own team to service the Contract in just the same way that it would have had to maintain a team to service the replacement contract if it had procured a replacement system from another supplier. So, on a broad approach, this appears to be a head of loss that does not in truth arise.
349. Second, however, it may be argued, and it could be argued on the facts of this case, that the length of time for which DB would have had to service a replacement contract would be longer than the balance of the period of the Atos Contract.
350. But even on this basis, I regard DB's own costs of servicing a replacement contract as being qualitatively different to the costs paid in respect of Atos's services because they do not form part of the services that Atos agreed to provide. As the authorities considered above show, the innocent party is entitled to recover from the party who has repudiated the contract the difference in value between what the services in fact provided and the services contracted for, and that is usually measured by the cost of procuring the unperformed services from another supplier provided that it would have been reasonable to do so. The services that DB provided to itself, by means of the time spent by its own employees on the project, are not services that Atos contracted to provide.
351. Whilst the need for additional services of DB's own employees to support the replacement contract is a foreseeable result of Atos's breach of contract (subject, of course, to deduction of any costs that it would have incurred in any event), it represents a potential loss that in my judgment is only recoverable if it is actually incurred or if it is proved that it will, on the balance of probability, be incurred. This is for the simple reason that I have already given, namely that the services of DB's own employees were never services that Atos contracted to supply: the primary measure of damages against Atos for non-delivery or non-supply is essentially represented by the value of the services that were not supplied. That is the measure of damages recoverable in a case of supply, together with such other reasonably foreseeable losses as DB actually sustained (or has proved that it will sustain) as a result of the breach. (I use the expression "reasonably foreseeable" in this context as shorthand for the various heads of loss that are properly recoverable in this type of claim breach of contract.)
352. But there was also a refinement of this point. Mr Lewis submitted that DB should give credit for the costs which it would itself have had to incur had the Contract continued to completion. In my view, this point is based on a fallacy, namely the assumption that such costs were not incurred. DB's own resources that would have been devoted to the project, had it continued, were its own employees, whom it continued to employ after the termination. In the case of some employees, such as Mr Aythora and Mr McKendrick, they were made redundant in April and June 2009, respectively, the latter date being three months after bundle 3 should have been delivered. I have no doubt that they were made redundant because there was nothing left for them to do following the termination and DB would, of course, have to pay them redundancy pay in addition to their salaries up to the date when they were made redundant. I am not satisfied that there is any saving here for which DB must give credit.
353. In relation to the loss of savings and additional interest charges set out in items (4) and (5) in the summary above, DB adduced no evidence to support either of these items. They were pleaded in the Particulars of Claim, which was supported by the required statement of truth - in this case signed by Mr Page. These heads of loss were not dealt with in the evidence of any of DB's witnesses. In its closing submissions DB submitted that these heads of loss were "supported by a statement of truth (and are therefore in evidence) signed by Mr Page and he was not cross examined on these matters" (paragraph 285).
354. The short answer to this was given by Mr Lewis in his final submissions. It is as follows. CPR 32.6(2) provides that

"At hearings other than the trial, a party may rely on the matters set out in

(a) his statement of case; or

(b) his application, notice if the statement of case or application notice is verified by a statement of truth."

Unfortunately, the punctuation in this rule has gone awry and the comma should clearly be after "notice" and not after "application". In addition, it is clear that the words "if the statement of case or application notice . . ." are intended to qualify both (a) and (b). The general rule is that any fact which needs to be proved by the evidence of witnesses is to be proved at trial by their oral evidence given in public: CPR 32.2 (1). This is subject to any order of the court (which may be given under CPR 32.1).

355. In this case no order was made that would displace the general rule and accordingly DB has failed to support these heads of claim with any evidence. It is clear that both heads of loss are ones that would have to be proved by the evidence of witnesses in the absence of agreement to the contrary or any admission. However, I consider that the claim for savings would have failed in any event because it is based on the assumption that DB would prove that the move of the aggregation process to Botswana would have occurred but for the termination. That is not the position.
356. Conclusions:

(1) DB is in principle entitled to recover the cost of building the replacement system. I shall consider in the next part of this judgment what those costs should be.

(2) DB is not entitled to recover the costs set out in items (3)(b)-(e) in the summary set out in paragraph 328 above.

(3) DB is not entitled to recover the savings or costs set out in items (4) and (5) of the above summary.

The ThoughtWorks quotation

357. DB admits that it cannot recover the full amount claimed in respect of the ThoughtWorks quotation. DB accepts that the ThoughtWorks quotation should be reduced by £357,808 because it included two items, Invoice Tracking and Intelligent Hand Held devices, which were not within the scope of the Atos contract.
358. However, there was a dispute as to the amount of this deduction. I do not propose to lengthen this judgment by going into details of that dispute. It is sufficient to say that, for the reasons given in paragraphs 266 and 267 of DB's Closing Submissions, the percentage deduction (before allowing for overheads) should be 11.9%. This produces a reduction of £447,261. As both sides accept, there should then be a further reduction from that figure to reflect the fact that overheads would not reduce proportionally.
359. Dr Thomas contended that 13.5% was the appropriate reduction to reflect overheads. DB contends that it should be 20%, on the grounds that Atos claimed 25% by way of overheads. This is a matter of broad brush assessment. Doing the best I can, I would adopt DB's approach and reduce the figure by 20%, so that the amount to be deducted from the ThoughtWorks quotation is £357,808.
360. Atos submits also that the ThoughtWorks quotation should be reduced by a further amount to reflect the fact that it was not a quotation submitted as a competitive bid. I reject this submission because DB, in order to mitigate its loss, took steps to obtain a quotation from an alternative supplier as soon as possible in order to reduce the impact on the delay in delivery of the replacement system. ThoughtWorks was familiar with DB's processes, because it had been involved in developing the software for certain discrete aspects of DB's business, and was in a position to respond quickly. Had DB put the contract for the replacement system out to tender, it would have taken much longer to obtain competitive quotations from other potential suppliers. In my judgment DB acted reasonably in obtaining the quotation from ThoughtWorks.
361. Accordingly, I consider that DB is entitled to recover the amount of the original ThoughtWorks quotation less £357,808, namely £3,588,617.

DB's damages - summary

362. For the reasons that I have now given, I consider that DB is entitled to recover the following sums before giving credit for costs that it would have incurred if Atos had not terminated the contract:

The costs associated with the work which it carried out in modifying its Legacy systems (as amended by JSN1)		406,061 (453,779 - 47,718)
DB's IT staff costs related to the ongoing support of the modified Legacy system during the period of development		417,153
The costs associated with a replacement system (i.e. instead of that which would have been delivered under the Contract had it not come to an end), as follows:
The cost of building the replacement system, based on a quotation from a third-party supplier (ThoughtWorks)		3,588,617
DB's IT management costs in respect of the building of the replacement system		Nil
DB's business staff costs relating to the building of the replacement system		Nil
Travel and accommodation for DB overseas staff visiting London		Nil
Travel and accommodation for DB London staff visiting overseas DB operations		Nil
Loss of savings: DB claims that it has been deprived of savings and process efficiencies which it would have enjoyed using the SCMS functions which would have been present on the contracted software which AO should have provided		Nil
Additional interest charges arising from the need to purchase intakes 2 days early (based on a 10% rate of interest)		Nil
TOTAL		4,411,831

363. There is no dispute that DB's damages must take account of sums which it would have had to pay if the Contract had been performed in full.
364. On any view, these include the following:

(1) The remaining Key Milestone payments (Key Milestones 4-8), totalling £1,622,311.

(2) The valuations of the two CRs in respect of which DB and Atos agreed the figure, namely CR 003 (£415,000) and CR 008 (£11,805). In relation to CR 019, DB admitted that £19,675 was payable, but Atos claims it is entitled to more (I have considered this CR above). The two agreed amounts total £426,805.

365. In addition, account must also be taken of the amount in which Atos's other unresolved or disputed claims would have been either valued or compromised. To answer this question it is not be necessary to make a detailed and precise valuation of each such claim because the aggregate of such valuations would not necessarily represent the amount at which the parties might have agreed to settle all the claims in order to reach a compromise. It might have been more or less according to the commercial interests of and pressures on each of the parties at the time. I will consider the range of values and then reach a conclusion as to the amount of the likely compromise.
366. I have already concluded that neither party would probably have had a claim against the other in respect of the delays to completion. I would expect the parties to have arrived at a similar conclusion, assuming that no untoward problems occurred and that bundle 2 was delivered in about mid December 2008, and bundle 3 in about mid March 2009, in accordance with the programme submitted on 29 May 2008. Accordingly, I need not consider this aspect any further.

The credit to be given for Atos's accrued and future claims under the Contract

367. In this section I will collect together the values that I have ascribed to Atos's various heads of claim:

Head of claim	Paragraph	Minimum value	Maximum value
SACs	248	125,000	150,000
Finance Requirements	263	17,000	17,000
EDS	266	25,000	30,000
Lack of access to DB personnel (Core SCMS)	269	50,000	100,000
Lack of access to development resources	275	20,000	20,000
List of peripherals etc	277	10,000	10,000
Lack of key DB resources	279	25,000	50,000
Legacy Systems	281	15,000	20,000
New PRs	308	17,500	17,500
CRs	326	338,969	344,400
	TOTALS:	643,469	758,900

368. The figures in this table represent, of course, an assessment of Atos's accrued and future claims as at the date of termination. If the above claims stood on their own I consider that the parties would probably have agreed a value of about £700,000.
369. In addition, there is the further work on CRs post termination, which would have been done if the Contract had continued, which I have assessed as having a value of about £250,000. Added to the figure in the previous paragraph produces a total of £950,000.
370. I have considered whether there should be added to these figures any further uplift to reflect additional claims that might have accrued and been agreed between the date of termination and the end of the project, but I consider that this would be too speculative. Accordingly, the above figure of £950,000 represents my best estimate of the cost that DB would have incurred in order to settle Atos's claims, both accrued and post termination.
371. Thus the position in relation to the credits that must be given by DB is as follows:

(1)	The remaining payments under the Contract	£1,622,311.
(4)	The valuations of the two agreed CRs	£426,805.
(3)	The compromise of all other claims by Atos	£950,000
		_________
		£2,999,116

372. Accordingly, DB's claim in respect of upgrading the legacy systems and the ThoughtWorks system that I have assessed at £4,411,831 must be reduced by £2,999,116, leaving a net claim for £1,412,715. From this sum must be subtracted some notional interest to reflect the fact that all the sums that I have found due to Atos should have been paid some time ago.
373. In particular: the non payment of the sum in respect of Key Milestone 4 should attract interest from 3 April 2008; the other payments under the Contract should attract interest from the dates when they would probably have fallen due; and the £950,000 settlement figure with Atos should attract interest from the date by which it was likely to have been agreed. I estimate this as 1 July 2009.
374. By contrast, DB is entitled to actual interest on those sums that it has paid or incurred from the dates when they were paid or incurred.
375. I will hear the parties on any questions of interest that cannot be agreed.

The application of clause 23.1

376. Since I have reached the conclusion that the amount of damages for which Atos is liable is very much less than the limit imposed by clause 23.3 of the Contract, the application of the limit imposed by that clause is academic.
377. However, I have reached a clear view of how the clause would apply if it fell to be considered, so I shall state it briefly. It is evident from its own internal documents, in particular Mr Bray's e-mail of 16 May 2008, that Atos was considering termination of the contract, not just a suspension of work. In that e-mail Mr Bray referred to his conversation with Mr Newell earlier that day and then said:

"• He was extremely perturbed by Nikki's call and sounded really shocked we would consider termination. I also think he doesn't know what to expect now because Nikki didn't talk about timescales under which we might terminate (as we had agreed). He has really taken this personally and said "the prospect of being let down seriously by Atos only for us to then terminate is unbelievable". The man is clearly concerned about his job and his credibility;"

378. As I have already mentioned, I regard it as significant that Mr Bray used the word "terminate" not only when recording what Mr Newell had said but also in the context of what Atos was planning. It is clear to me that by this stage Atos was intent on terminating the Contract if it could not negotiate a variation of its terms that was acceptable to Atos. By this time Atos had been taking legal advice for some time and it is most unlikely, as I have already found, that Atos did not consider the less dramatic step of suspending work under clause 12.5 until the outstanding invoice had been paid. I consider that Atos must have concluded that this would not achieve what it wanted and that the only alternative was to threaten termination, even though it could not have believed that it had any legitimate grounds for doing so. If, for example, Atos thought at the time when the letter of 21 May 2008 was being drafted that it was entitled to accept a repudiatory breach of contract by DB, then I have no doubt that the letter would have been written in very different terms.
379. I find that during the period from 21 May to 6 June 2008 Atos knew that the course upon which it had embarked would amount to a breach of contract. It committed that breach of contract deliberately and that amounted to both wilful and deliberate default.

Afternote

380. It will be observed by those who are familiar with the details of this case that the amount of damages (subject to adjustment for notional interest) that are to be awarded to DB may well be less than the additional costs that Atos would have incurred if it had continued to perform the Contract to completion.
381. On the face of it, this is not a satisfactory result. However, this comes about because I felt unable to conclude that, as a matter of probability, DB will procure a replacement system. This finding was really made inevitable by the very unsatisfactory nature of the evidence about the true position in relation to the reasons why the Aggregation Project had not moved to Botswana.
382. At the conclusion of Mr Page's evidence I made it clear that DB's refusal to disclose the true impediment to the move of the Aggregation Project to Botswana could well prejudice its claim, because the court would be left in a state of almost complete ignorance of the true facts and therefore might well not be in a position to make the necessary assessment of future probabilities. Unfortunately, that is the conclusion that I was ultimately compelled to reach.

GLOSSARY OF TERMS AND ABBREVIATIONS

AO	Atos Origin (Atos)
BA	Business Analyst
BAFO	Best and final offer
CAB	Change Control/Approval Board
CCP	Change Control Process
CR	Change Request
CUT	Code and unit test
DA	Detailed Analysis (in particular in the context of change requests)
EAI	Enterprise Application Integration Project
EDS	Enterprise Data Store
ER	Elaboration Request
FPM	Fixed Price Model(ling)
FRG	Flexible Reporting Group
IAP	Initiation & Analysis Phase
IA	Impact Assessment (in particular in the context of change requests)
LSO	Local sorting (or sales) office
MDL	Master Data Library
NFR	Non-functional requirement
PHS	Prepare & Hold Sight
PID	Project initiation document
PR	Process Requirement
RAG	RED AMBER GREEN
RDD	Requirements Definition Document
RoMgt	Rolling Management
SACs	The South African countries: Botswana, Namibia & South Africa.
SAN	Storage Area Network
SCMS	Supply Chain Management System
SKU	Stock Holding Unit
SME	Subject Matter Expert
SOA	Service Oriented Architecture
UAT	User Acceptance Testing
UI	User interface
WAN	Wide Area Network
Agile development	An approach to software development that features a less formal description of the client's requirements at the outset, with the software being developed through a high level of interaction between the supplier and customer.
Iterative development	An approach to software development that involves the documenting of some requirements at the start of the project with development taking place through an "iterative" process of production of developing software and feedback from the client in ongoing cycles.
Waterfall	The classical software development method: an approach where all requirements are expected to be ascertained to a low level of detail before any development effort takes place.