SUBS0000016
SUBS0000016
IN THE MATTER OF THE POST OFFICE HORIZON IT INQUIRY
‘PHASE END’ CLOSING SUBMISSIONS:
PHASE 2
On behalf of POST OFFICE LIMITED
INTRODUCTION!
1. These submissions are made on behalf of Post Office Limited (‘POL’)? in accordance with the
Chair’s directions of 16 November 2022. They are necessarily brief, in accordance with those
directions, and are made for the purpose of highlighting two key themes arising from the
evidence heard in Phase 2, rather than seeking to address each of the issues in the Completed
List of Issues considered in Phase 2 in turn.>
2. These themes are:
2.1. POL’s knowledge of issues identified during the piloting and testing of the Horizon IT
System; and
2.2, Assurances given as to the resolution of such issues prior to roll-out, and steps taken to
resolve them during the course of roll-out.
PRELIMINARY POINT
3. The Inquiry has heard a considerable amount of evidence relating to events which took place
many years ago. To the extent that such evidence is not corroborated by contemporaneous
documentary evidence, care obviously needs to be taken. Many of the witnesses understandably
caveated their evidence with a warning that their recollection had dimmed over time. However,
1 References to transcripts in this document are given in the form T day/month/year [page:line — page:line].
2 The Inquiry has heard evidence that Post Office Ltd was previously known as Post Office Counters Ltd; and similarly that
Fujitsu Services Ltd was previously known as ICL Ltd and had a number of associated entities including ICL Pathway Ltd.
Such distinctions are not particularly relevant for present purposes and so for convenience, throughout these submissions,
the respective companies will be referred to by their current names, abbreviated as “POL” and “Fujitsu”
5 The Chair's directions were made in response to the application of Mr Stein KC on 13 October 2022, in which he sought
permission to make brief closing submissions at the conclusion of the hearings of each phase of the Inquiry, “rather than just
in final closing submissions” (T 13.10.22 [59/12 - 60/15]). POL therefore understands the ‘phase end’ submissions for Phase 2
to be in addition to, rather than in any way in substitution for, full written closing submissions anticipated to be provided
by Core Participants after the completion of all oral hearings.
11/78003245_1 1
SUBS0000016
SUBS0000016
the inevitable vagueness of actual recollection was sometimes not immediately obvious during
oral testimony: perhaps in large part due to a desire on witnesses’ part to assist as far as possible,
and a willingness to try to imagine what they now consider they (or someone else) would have
done or thought, rather than what they in fact did or thought at the time. The Inquiry will be
astute to these dangers (which, of course, are likely to arise in respect of all witnesses, including
from POL,
in Phases 2 to 5 inclusive in particular).
4. The issue of the assessment of evidence based on recollection was considered at some length by
Leggatt J (now Lord Leggatt, Justice of the Supreme Court) in Gestmin SGPS SA v Credit Suisse
(UK) Ltd [2013] EWHC 3560 (Comm):*
“Evidence based on recollection
15.
16.
17.
18.
An obvious difficulty which affects allegations and oral evidence based on recollection
of events which occurred several years ago is the unreliability of human memory.
While everyone knows that memory is fallible, I do not believe that the legal system has
sufficiently absorbed the lessons of a century of psychological research into the nature
of memory and the unreliability of eyewitness testimony. One of the most important
lessons of such research is that in everyday life we are not aware of the extent to which
our own and other people’s memories are unreliable and believe our memories to be more
faithful than they are. Two common (and related) errors are to suppose: (1) that the
stronger and more vivid is our feeling or experience of recollection, the more likely the
recollection is to be accurate; and (2) that the more confident another person is in their
recollection, the more likely their recollection is to be accurate.
Underlying both these errors is a faulty model of memory as a mental record which is
fixed at the time of experience of an event and then fades (more or less slowly) over time.
In fact, psychological research has demonstrated that memories are fluid and malleable,
being constantly rewritten whenever they are retrieved
External information can intrude into a witness's memory, as can his or her own
thoughts and beliefs, and both can cause dramatic changes in recollection. Events can
come to be recalled as memories which did not happen at all or which happened to
someone else (referred to in the literature as a failure of source memory).
Memory is especially unreliable when it comes to recalling past beliefs. Our memories
of past beliefs are revised to make them more consistent with our present beliefs. Studies
have also shown that memory is particularly vulnerable to interference and alteration
4 See too Leggatt J’s judgment in Blue v Ashley [2017] EWHC 1928 at §§66-70.
11/78003245_1
19.
20.
21.
22.
11/78003245_1
when a person is presented with new information or suggestions about an event in
circumstances where his or her memory of it is already weak due to the passage of time.
The process of civil litigation itself subjects the memories of witnesses to powerful biases.
The nature of litigation is such that witnesses often have a stake in a particular version
of events.
A desire to assist, or at least not to prejudice, the party who has called the witness or
that party's lawyers, as well as a natural desire to give a good impression in a public
forum, can be significant motivating forces.
Considerable interference with memory is also introduced in civil litigation by the
procedure of preparing for trial. A witness is asked to make a statement, often (as in the
present case) when a long time has already elapsed since the relevant events. The
statement is usually drafted for the witness by a lawyer who is inevitably conscious of
the significance for the issues in the case of what the witness does nor does not say. The
statement is made after the witness’s memory has been “refreshed” by reading
documents.
It is not uncommon (and the present case was no exception) for witnesses to be asked in
cross-examination if they understand the difference between recollection and
reconstruction or whether their evidence is a genuine recollection or a reconstruction of
events. Such questions are misguided in at least two ways. First, they erroneously
presuppose that there is a clear distinction between recollection and reconstruction,
when all remembering of distant events involves reconstructive processes. Second, such
questions disregard the fact that such processes are largely unconscious and that the
strength, vividness and apparent authenticity of memories is not a reliable measure of
their truth.
In the light of these considerations, the best approach for a judge to adopt in the trial of
a commercial case is, in my view, to place little if any reliance at all on witnesses’
recollections of what was said in meetings and conversations, and to base factual
findings on inferences drawn from the documentary evidence and known or probable
facts. This does not mean that oral testimony serves no useful purpose — though its
utility is often disproportionate to its length. But its value lies largely, as I see it, in the
opportunity which cross-examination affords to subject the documentary record to
critical scrutiny and to gauge the personality, motivations and working practices of a
witness, rather than in testimony of what the witness recalls of particular conversations
and events. Above all, it is important to avoid the fallacy of supposing that, because a
witness has confidence in his or her recollection and is honest, evidence based on that
recollection provides any reliable guide to the truth.”
SUBS0000016
SUBS0000016
SUBS0000016
SUBS0000016
(1) POL’S KNOWLEDGE OF ISSUES IDENTIFIED DURING THE PILOTING AND TESTING OF THE
SYSTEM
(a) Routes by which POL could have obtained knowledge of issues from Fujitsu
5. Aconcerted effort was made in many of the Fujitsu witness statements to suggest that POL had
the same level of understanding of the technical challenges and problems as Fujitsu did, or at
least a significant level of understanding of such. If Fujitsu had been open with POL and, for
example, given POL full access to Fujitsu’s design documentation and provided it with copies
of all of Fujitsu’s progress reports and internal reviews (which were central to Mr Charles
Cipione’s evidence), there might have been some basis for that suggestion.
6. The clear evidence, however, is that there was no such sharing on Fujitsu’s part.
7. Following the contract being awarded to Fujitsu, POL carried out assurance of the Horizon IT
System by carrying out testing and providing feedback to Fujitsu. In his witness statement, Mr
Jeremy Folkes explained that POL’s role in assurance was to try to monitor the development of
the service to gain increasing confidence in the emerging solution and to assure its
performance/security, whilst also trying to support Fujitsu by providing access to resources in
the Benefits Agency (‘BA’) or POL. POL had meetings with Fujitsu and set up a “Technical
Assurance Forum’”.5
8. Mr Folkes described Fujitsu’s general policy of secrecy towards POL, particularly in relation to
the detailed design information which POL required in order to carry out its assurance
activities. POL achieved some success through initiatives such as the Technical Assurance
Forum, but Mr Folkes’ memory was that these initiatives were sometimes rather short lived®
and in general Fujitsu was reluctant to share design documentation with POL and relied on the
fact that the original PFI structure meant that POL was not entitled to such information.”
9. Having seen the evidence now made available, an obvious inference is that part at least of
Fujitsu’s reluctance was due to the fact that such design documentation did not exist and it is
clear that much of the material as was eventually produced was reverse-engineered. Mr
Cipione’s evidence was that this is hopeless from a design point of view: the design should
inform the detailed implementation, not the other way round.*
5 Folkes ws/ WITN05970100, § 71 to 74.
* Folkes ws/ WITN05970100, § 81.
7 Folkes ws/ WITN05970100, §77.
®T 17/11/22 [151:20-152:14].
11/78003245_1 4
SUBS0000016
SUBS0000016
10. Mr Folkes explained that Fujitsu’s refusal to provide adequate documentation for assurance
purposes was the subject of repeated complaints from POL.’ Mr John Meagher confirmed that
Fujitsu’s attitude undermined POL’s ability to do its job."°
11. As late as November 1999, Mr David Miller considered that POL’s “people on the ground
perceive[d] ... a reversion to the old ways of working with the shutters being brought down” — a
reference to the fact that Fujitsu had kept the BA and POL from getting close to its solution
during the PFI stage." Mr Miller said “we were not being allowed in so we could satisfy ourselves
what was happening” 2 According to Mr Folkes, the PFI model had involved a kind of "trust me,
I'm a doctor” model with which he was uncomfortable," or as a “black box”.'* Whenever they
tried to get documents, Fujitsu would play the “PFI card” 1° This meant that they were “actively
preventing access” .1°
12. Mr Meagher also stated in his witness statement that Fujitsu denied the POL assurance team
access to application design documents citing an inability to do so under the PFI..7 Mr Andrew
Simpkins also agreed with this saying that Mr Folkes’ evidence rightly placed a lot of emphasis
on how the POL team did not have access to the technical documentation because of Fujitsu’s
position that the PFI allowed them to deny that access.'* Mr Simpkins stated that people on the
POL team who were responsible for assurance were saying that they could not really do their
job.” Mr Alan D’Alvarez also confirmed that POL had no formal reviewing rights to the
technical design documentation.”
13. By the time the PFI structure fell away, Mr Folkes’ view was that the damage had already been
done: but in any event, according to Mr Meagher, Fujitsu’s approach did not change.”
° T 2/11/22 [154:20-15!
1 T 15/11/22 (89:25: I.
™ T 28/10/22 [92:21-93:14]; referring to POL00028550 §12 - a briefing note prepared by Keith Baines of POL for a meeting
between POL and Fujitsu on 22/11/99.
1 T 28/10/22 [93:10-14].
18 T 3/11/22 [28:17-24].
MT 2/11/22 [73:8-14; 73:24-74:1; 150:6-24]
18 T 2/11/22 [74:13-22].
16 T 2/11/22 [78:22].
7 Meagher ws/ WITN04150100, § 14.
18 T 3/11/22 [91:12-17].
1 T 3/11/22 [92:8-10].
20 T 8/11/22 [43:4-5].
2. 2/11/22 [71:11-23].
* T 15/11/22 [93:20-25].
11/78003245_1 5
SUBS0000016
SUBS0000016
14. There are references in some evidence to documents and reports being stored in a library* —
but Mr Folkes explained that this was an internal Fujitsu library to which POL did not have
access.*4
15. Mr Robert Booth, Solutions Architect for POL (who remains a POL employee), confirmed that
it was always difficult to get documents out of Fujitsu and that Fujitsu’s approach was ad hoc
so that he was not always convinced they knew what they were saying.” He explained that
while Fujitsu did share some technical material with POL, it only shared high level designs
against the requirements; low level designs and code were never shared or made available for
review.7°
16. Fujitsu’s suggestion that POL gained knowledge and understanding simply by sharing
workspaces with Fujitsu was rejected by Mr Booth. He explained that Fujitsu’s offices in
Feltham were divided into separate areas with POL staff kept separate from Fujitsu and
‘Chinese Wall’ arrangements for the respective teams of testers: the Fujitsu testers found it
useful to have access to POL employees’ understanding of POL’s systems but the set-up he
described did not amount to a general sharing of information.””
17. As such, except in areas where POL had an explicit contractual right to a document, POL only
had limited or partial visibility of the emerging Horizon IT System or its design and
development approach. According to Mr Folkes, one particular gap was any access to software
quality information or metrics, such as the number of bugs found in testing or the amount of
rework being done.** Ultimately Mr Folkes considered that POL had very limited oversight of
the application design of the Horizon IT System. POL obtained “bitty” information, for example
through “corridor discussions” had when visiting Fujitsu’s offices or through information
obtained by team members involved in “joint working” at Fujitsu’s offices.”
18. Mr Folkes confirmed that POL did not have access to PinICLs or Helpdesk records as such in
mid-1999. PinICLs were related to an internal Fujitsu tool to which POL employees did not
have access. Neither he nor anyone else at POL had access to records of PinICLs in mid-1999.1
Nor did anyone at POL in mid-1999 have access to Helpdesk records.** They had access to a
kind of extract of Helpdesk records including 14 entries, which Mr Folkes did not consider
23 See eg POL00029165.
24 T 2/11/22 [160:25-161:7].
2 T 15/11/22 [17:10-22].
28 Folkes ws/ WITN05970100, § 84 to 85.
» Folkes ws/ WITN05970100, § 89 to 90.
8° T 03/11/22 [5:23-6:8].
1 T 03/11/22 [5:17-22].
% T 03/11/22 [6:12-15].
11/78003245_1 6
19.
20.
SUBS0000016
SUBS0000016
credible or accurate.** His evidence was that POL did receive more complete helpdesk records
“at some point after that”, but perhaps not soon enough as he never personally laid eyes on them
so this quite possibly post-dated acceptance.
Mr Cipione found the Monthly Progress Reports prepared by Fujitsu to be a useful source for
identifying many of the issues which arose on the project at the time but had seen no evidence
that the reports were provided to POL at any time.*
Despite Fujitsu’s insinuations as to POL’s knowledge, when Fujitsu’s witnesses were
questioned, it quickly became clear that they had gone too far in their witness statements, or
had no proper factual basis for the allegations they had made. Set out below are some examples
of how Fujitsu’s evidence in its witness statements contrasted to what was said during
questioning:
20.1. Anthony Oppenheim (Commercial and Finance Director, Fujitsu):
20.1.1. Witness statement:
“My understanding is that POCL had access to our PinICL system and test data”.
(§160)
20.1.2. Oral evidence:
“Q. Are you referring there to what I have described as a theoretical right, a contractual
right on demand, “Can we please see what is on a PinICL”, or are you referring to an
understanding that, as a matter of fact, the Post Office had direct physical access to
PinICLs, just as a matter of course?
A. I think not, as a matter of course. So, in hindsight, I probably would have worded
this slightly differently. The point here was specific to the Als and those PinICLs that
related to the Als, I believe, were shared. That's different, I can see that, from having a
contractual right to just go through any and all PinICLs. I don’t know, to be honest,
whether they did have access, or some members of their team had access. I genuinely
don’t know that.
Q. Are you aware of any policy or procedure, or protocol concerning the issue of access
by the Post Office to PinICLs and test data?
A. I don’t, no.
Q. So, although this is written in an unqualified way, ie it isn’t restricted to those
PinICLs that were associated with Als, albeit you are discussing Als at the time, you
8° T 03/11/22 [6:12-7:18].
47 3/11/22 [7:4-5].
38-7 17/11/22 [20:17-21:1].
11/78003245_1 7
SUBS0000016
SUBS0000016
don’t have any evidential basis for saying that Post Office had, as a matter of course,
direct access to all and any PinICLs; is that right?
A. That is correct, yes.”°°
20.2. Alan D’Alvarez (Programme Executive, Fujitsu):
20.2.1. Witness statement:
“[POL] had two people responsible for overseeing security testing ... they were
accountable for reviewing all defects and agreeing the business priority of those defects
... and they audited test results and PinICL content for accuracy” (§37(b))
20.2.2. Oral evidence:
“Where I say “inspect the PinICL”, we would discuss the detail of each of the PinICLs,
so they understood from a business perspective whether or not -- how to classify those
and whether they would become Acceptance Incidents or not.
Q. When you say audited the PinICL content, again that's the -- is that PinICLs that
you provided to them?
A. I think it’s reviewed, as opposed to audited.”*7
“Q. So when you say you were discussing defects with them and seeking their views
on business priority, etc, those were PinICLs that you put — or information that you
put forward to him -
A. Yes, we would often do a review of an Excel — we would dump to Excel or print to
Excel outstanding or open defects, which would have high level descriptions. It
wouldn't have the detail of the analysis”**
20.3. Mark Ascott (Lead Test Practitioner, Fujitsu):
20.3.1. Witness statement:
“My recollection is that High Level Test Plans and Test Reports included Post Office
staff as recipients and reviewers of draft and approved documents” (§32)
20.3.2. Oral evidence:
“Q. In respect of Legacy Horizon, would that — that statement have held true?
A. I'm not sure on that... I didn’t have direct involvement in the production or
necessarily the reviewing of those documents.
Q. Does the same apply for design and development documents as well?
5° T 26/10/22 [27:19-28:19].
37 T 8/11/22 [51:2-9].
38 T 8/11/22 [47:25-48:7].
11/78003245_1 8
SUBS0000016
SUBS0000016
A. I would say the design documents around the security solution that I would have
been involved in didn’t generally include Post Office recipients.”
20.4. John Simpkins (Team Leader of Software Support, Fujitsu):
20.4.1.
20.4.2.
Witness statement:
“To the extent that there were any known defects when these releases were rolled out,
my understanding is that this would have been communicated to Post Office, either by
the Service Management team (as noted at paragraph 7 above) or by other ICL Pathway
teams.” (§25)
Oral evidence:
“Q. What's the basis for that belief?
A. [have been involved in some projects.
Q. I'm talking about this one. (pause) ... I’m asking you for the basis for that belief,
please?
A. Just because projects reported back. Sorry, I've got nothing more than that.
Q. You haven't got any actual knowledge of whether that did happen?
A. I’ve got no actual knowledge.”
20.5. David McDonnell (Development Manager, Fujitsu):
20.5.1.
20.5.2.
3° T 9/11/22 [118: 7-20].
4° T 9/11/22 [10:17-11:10].
“1 FUJ00067416.
©” T 16/11/22 [96: 3-11].
11/78003245_1
Witness statement:
“POCL and ICL Pathway met almost daily ... I understand that the POCL rep Barbara
Longley was in attendance ... POCL knew that there were problems with EPOSS and
particularly around the cash account ... they did know the Cash Account didn’t work
as evidenced by the PinICL document”! (§52)
Oral evidence:
“When I refer to the fact that they definitely knew that cash account was broken, I’m
talking about the PinICL ... where it has a full audit trail of everybody who read,
touched and commented on that particular cash error account error, and there are at
least one POCL person — I think that was Barbara Longley — whose desk that PinICL
did cross, and she has commented on it at some point.”
SUBS0000016
SUBS0000016
“Q. So it’s Barbara Longley’s user identification on this peak that causes you to say
that POCL knew that there were problems with the EPOSS system?
Yes.”43
20.5.3. Barbara Longley was in fact a Fujitsu employee.
(b) POL’s knowledge of issues identified in relation to the EPOS system
21. Mr Cipione noted that Horizon was designed to provide two functional services:
21.1. Electronic Point of Sale (‘EPOS’ or EPOS system (‘EPOSS’)). This function was to record,
via electronic rather than paper means, (i) purchases of Post Office products made by
customers at a branch; (ii) transactions carried out by customers in the branch for the
purchase of products or use of services provided by the clients of the post office (e.g.
banks, National Lottery, DWP, DVLA etc).
21.2. Management accounting: This function provided Sub-Postmasters and POL with
accounts which summarised the cash and stock positions and payments and receipts
activity within a branch.
22. The EPOS system was a central part of the software being provided by Fujitsu and it was crucial
that Sub-Postmasters were provided with a functioning and stable EPOS system.
23. It is plain that Fujitsu had serious concerns about its development of the EPOSS software. When
Mr McDonnell was appointed, it was specifically on the basis that there were “deep concerns”
about the quality of the EPOSS team and the code being produced; and Mr Michael Coombs,
Fujitsu’s Programme Director at the relevant time (around 1998), although unable to remember
much detail, confirmed that he recalled that there were discussions about whether it was
preferable to redevelop EPOSS or simply to try to improve it.
24. An EPOSS PinICL Task Force was created in August 1998 whose purpose was “to reduce to
manageable levels the EPOSS PinICLs outstanding at that time”.° The report records that there
were “significant deficiencies in the EPOSS product, its code and design”,‘” and that before the Task
Force was established, the team was “immersed in a seemingly impossible task of dealing with
PinICLs that were being raised faster than they could be cleared”.** It was also said that “[I]ack of code
® T 16/11/22 (98:8-11].
McDonnell ws/ WITN00620100, §6.
“5 Coombs ws/ WITN03870100, §55.
4° See Fujitsu’s Report on EPOSS PinICL Task Force FUJ00080690.
*” FUJ00080690/ §1.
+8 FUJ00080690/ §3.
11/78003245_1 10
SUBS0000016
SUBS0000016
reviews in the development and fix process has resulted in poor workmanship and bad code”. Senior
members of the task force were extremely concerned about the quality of the code in the EPOSS
product.»
25. Mr Cipione agreed that the evidence of the PinICL Task Force suggested that there was no
design at least for the EPOSS section of Horizon and that in the absence of a good design, there
is no realistic prospect of the software working properly.*! He was taken to the examples of
code which are recorded in the EPOSS Task Force report: his view on one of the examples was
that it was so bad that it amounted to “a joke”.
26. The Fujitsu witness statements make some passing reference to the EPOSS Task Force and its
report but the scale of the problems which Fujitsu knew about at the time is not caught by any
of those statements (with the exception of Mr McDonnell’s). The scale and seriousness of the
problems did not become apparent until those witnesses were questioned by CTI. For example,
Mr Jan Holmes, Fujitsu’s Audit Manager, referred to the EPOSS Task Force and the report
which he and Mr McDonnell had prepared, but his written statement lacked any
acknowledgement of the seriousness of the situation — despite the fact that he readily admitted
to this when questioned.* He also accepted, having heard the evidence, that his written
evidence to the effect that matters had been adequately dealt with at the time, was not in fact
correct.#
27. POL was unaware that the EPOSS Task Force had been formed or that a report on its work had
been produced. Mr Miller, then the Horizon Programme Director for POL, considered the
report “very significant” but only became aware of it during the evidence before the Inquiry.*
Mr Folkes was clear that he had not been told of the work or the conclusions of the Task Force
at the time it was undertaking its work. He expressed “annoyance and frustration” that he had
not been shown the report at the time and considered that this was a “missed opportunity”: his
view was that if POL had known about these matters at the time, this would have tipped the
balance in favour of abandoning the project altogether.” Mr Meagher said that if he had been
aware of either the Task Force or the recommendations to rewrite the EPOSS application, then
he would probably have raised a high-level Acceptance Incident which he thought would have
given POL more evidence upon which to press for a change of approach from Fujitsu.**
*° FUJ00080690/ §3.
50 FUJO0080690.
* T17/11/22/ [150:9-151:9].
% TT 17/11/22/ [154:4-25].
88 T 16/11/22/ [113:17-114:7; 123:7-17].
57 16/11/22/ [123:18-124:5]
88 T 28/11/22 [32:13-33:5].
56 T 2/11/22 [139:3-10].
97 T 2/11/22 [140:23-141:21].
58 T 15/11/22 [92:15-22].
11/78003245_1 11
SUBS0000016
SUBS0000016
28. MrMcDonnell was of the view that the Cash Account function of EPOSS needed to be rewritten.
His evidence was that his insistence on this was not well received by his superiors® and that he
was side-lined as a result. He was taken to a document dated 12 March 1999 entitled “EPOSS
Product Improvement Options”. This was a summary of discussions of workshops held in
about February 1999 which essentially sought to rank the risks and benefits of 13 “candidate
protect improvement measures”, including the rewriting of the Cash Account. It ranked the
benefit of rewriting the Cash Account as having the lowest benefit (12 compared to the highest
ranking of ‘error messages’). Mr McDonnell’s evidence was that the table should be inverted
i.e. that it was fundamentally wrong and the true position was the very opposite of that set out
in the discussion paper*!. It is submitted that the weight of the evidence suggests that Mr
McDonnell’s view was correct and that the discussion paper is anomalous. Mr Coombs,
Fujitsu’s Horizon Programme Director, agreed that Fujitsu’s internal views on the EPOSS
situation ought to have been brought to POL’s attention. Mr Peter Jeram, at the time Fujitsu’s
Release Project Manager, later Programme Director, agreed.
29. Drawing these various strands together it is submitted that the following conclusions can be
drawn:
29.1. Fujitsu was secretive towards POL during the Design and Assurance process and
refused POL access to key design documentation. As a result, POL had insufficient
visibility of Fujitsu’s approach and progress and was unable to reach its own
conclusions about the quality of the Fujitsu product;
29.2. The oral evidence is broadly consistent with POL witnesses who spoke to a significant
lack of information sharing, and goes some way to explaining POL’s acceptance of
Horizon in 1999;
29.3. POL of course had some visibility of some aspects of the challenges being faced by the
development team but the issues of which POL became aware were, in the main, not
ones which would reasonably have given rise to serious concerns about the reliability
of the Horizon IT System. An important exception to this is AI 376 which is dealt with
separately below;
29.4. By contrast, Fujitsu was aware, at all levels of its management, that the Horizon project
was facing very serious problems. In particular, it was known that the EPOSS system,
*° McDonnell ws/ WITN00620100, §26.
60 FUJ00121099.
*' T 16/11/22 [77:23-78:3].
© T 1/11/22 [60:3-9].
8 T 10/11/22 [104:23-105:1].
11/78003245_1 12
SUBS0000016
SUBS0000016
which is central to the Horizon IT System and in effect the part of the System which Sub-
Postmasters used and relied on most heavily, had serious flaws: the team responsible
for producing it was weak; much of the code was poorly written; and there was a serious
lack of proper design documentation. A Task Force had been created to address these
issues although by its own account it had not eliminated them. At least some senior
people recognised that parts of the EPOSS system, in particular the Cash Account,
needed to be rewritten from scratch;
29.5. Fujitsu did not inform POL of these serious issues. This must have been a deliberate
decision. Assertions made by a number of Fujitsu’s witnesses in their written witness
statements - that POL had full or significant access to Fujitsu information and therefore
awareness of these issues - was not borne out by in their oral evidence;
29.6. There was great uncertainty about the overall project in the period leading up to the BA
dropping out, and in the months following that event. There were some well-informed
and senior people, such as Mr Meagher, whose view, even based on the limited
information made available to them, was that the Project should be abandoned
(although he explained that he considered that Fujitsu would get the project over the
line eventually, it was a question of when and at what cost). If POL had been made
fully aware of the state of things in Fujitsu’s development of EPOSS, there is a real
possibility that this would have tipped the balance in favour of abandonment: as an
alternative POL might not have accepted the System and insisted on proof that the
various issues had been properly addressed.
30. As a general observation it is clear that there was limited understanding of IT issues within POL,
particularly within senior management. There was much less general understanding of IT
systems in the mid-1990s and POL was not a technologically advanced company at the time. That
said, it is also clear that POL should have listened carefully to those within the organisation — such
as Mr Folkes — who did have relevant expertise and who were flagging pertinent concerns. In
particular, Mr Folkes’ paper (“A reflection on the past five years. Lessons, issues and key points”
dated February 2000) contained astute observations about the limitations of Fujitsu’s work.
There is currently no evidence before the Inquiry that it prompted further investigations on POL’s
part.
(2) ASSURANCES AND RESOLUTION OF ISSUES PRIOR TO AND DURING ROLL-OUT
(a) Contractual acceptance criteria
4 T 15/11/22 [96:19-25)
{WITNO5970123 I
11/78003245_1 13
SUBS0000016
SUBS0000016
31. When Fujitsu originally contracted with POL and the DSS, the procedures for acceptance of the
Horizon IT System were set out in Schedule A07 of the Authorities Agreement dated 15 May
1999. Under Schedule A07, during acceptance trials and testing DSS and POL were to raise
any Acceptance Incidents (‘Als’) and Fujitsu were to categorise them as high, medium or low
severity and seek to resolve them. An acceptance test would result in ‘failed acceptance’ where
one or more high severity or medium severity deficiencies remained unresolved at the end of
the relevant acceptance period. Fujitsu would then be obliged to submit a plan for the correction
of unresolved Als and a date for a further acceptance test. POL and the Department of Social
Security (‘DSS’ — the parent department of BA) had a right to terminate the agreement for ‘failed
acceptance’ only if there was: (a) one or more high severity deficiencies or (b) 10 or more
medium severity deficiencies which remained uncorrected at the end of the CRS Operational
Trial Review Period.
32. Following the cancellation of the benefits payments card, an operational live trial of the Horizon
System began in late May 1999. POL and Fujitsu entered into a Codified Agreement on 28 July
1999. Schedule A11 of the Codified Agreement defined the new conditions for acceptance of
the Core Systems Release (‘CSR’).*’ Under Schedule A11:
32.1. Acceptance would occur once: (i) the CSR acceptance tests had been carried out
successfully; (ii) the CSR core observation period and the CSR operational trial review
period had expired; (iii) the thresholds for acceptance had been met as at the end of the
CSR core observation period; and (iv) a timetable had been agreed between the parties
to resolve all outstanding ‘category B’ or medium severity faults.
32.2. The thresholds for acceptance would not be met if there was (i) one or more “category
A” or high severity faults; (ii) more than 20 “category B” or medium severity faults; or
more than 10 “category B” faults in respect of any one CSR acceptance specification.
33. This amounted to a lowering of the threshold for contractual acceptance albeit there was now
a requirement for an agreed timetable for the resolution of all outstanding medium severity
faults.
34. If acceptance was not achieved at the end of the CSR Operational Trial Review Period, Fujitsu
was entitled to a period of three months in which to remedy the defaults, following which the
CSR would be re-submitted for acceptance testing. If at the end of the second acceptance test,
acceptance was not achieved then POL would have the right to terminate the Codified
Agreement.
6 POL00028163.
*7 POL00028208.
11/78003245_1 14
SUBS0000016
SUBS0000016
35. During acceptance, Mr Folkes recalled that Fujitsu seemed more interested in talking down the
severity of Als rather than actually trying to engage in resolving issues in what Mr Folkes
described as a “war of attrition”. Given that any “category A” or high severity Als were a
“potential showstopper” (whereas Fujitsu was allowed 20 “category Bs”), Mr Folkes believed that
Fujitsu had a “massive incentive” to avoid there being any “category A” Als.”
36. In any event, by August 1999 there were three Als which POL considered to be high severity:
AI 376; AI 298; and AI 218 (these Als are further referred to below). As a result, acceptance of
the CSR was not achieved at the conclusion of the CSR Operational Trial Review Period on 16
August 1999.
37. POL and Fujitsu then agreed in an amendment to the Codified Agreement dated 20 August
1999 (the “First Supplemental Agreement”) to seek to facilitate the obtaining of CSR
acceptance by setting up and conducting a programme of joint workshops for the purpose of
agreeing resolution plans for the outstanding high and medium Als. These workshops were
chaired by Mr Oppenheim of Fujitsu and Mr Keith Baines of POL.
38. Following the workshops, POL agreed to accept the Horizon IT System in late September 1999
notwithstanding that a number of Als (including Als 376, 298 and 218) had not been fully
resolved. CSR acceptance was deemed to have been achieved on 24 September 1999 subject to
a further amendment to the Codified Agreement of that date (the “Second Supplemental
Agreement”).”!
39. Under the Second Supplemental Agreement, acceptance was achieved subject to Fujitsu using
“reasonable endeavours” to resolve Als including AI 376, AI 218 and AI 298 in accordance with
specified success criteria and rectification plans.” If success criteria in relation to AI 298 and AI
376 (and AI 408), which were listed in Parts A to D of Schedule 4, had not been achieved by
certain target dates of 24 November 1999 (Parts A to C) or 14 January 2000 (Part D), POL could
postpone the resumption of rollout from 24 January 2000 in accordance with clause 6.1.
40. POL did suspend the rollout in late November 1999 in part due to ongoing concerns in relation
to AI 376. However, at a Special Delivery Meeting held on 14 January 2000,”? POL confirmed
that there was now an agreed way forward and robust checks had been put in place to address
the original concerns. Subject to final checks on integrity control and finalising a further
°8 Folkes ws/ WITN05970100, § 149.
© T 03/11/22 [9:24-10:5]
70 FUJ00000485.
71 POL00028509.
POL00090428, clauses 2.1, 3.1.
11/78003245_1 15
SUBS0000016
SUBS0000016
amendment to the Codified Agreement, it was agreed that there was no need for a further
meeting.
41. The further amendment was agreed on 19 January 2000 (the “Third Supplemental Agreement”)
under which POL and Fujitsu, among other things, agreed to continue to work together in the
joint work programmes initiated in respect of the development of operational procedures and
improvements. Volume rollout re-commenced on 24 January 2000.
42. In his evidence, Mr Andrew Simpkins referred to the minutes of a Management Resolution
Meeting on 13 August 1999, where there were a number of Als which Fujitsu categorised as
lower severity than POL.” Mr Andrew Simpkins considered that at this meeting POL were
“really trying to hold the line” that some of the Als were high severity incidents that POL would
not agree to downgrade unless there were demonstrable improvements from Fujitsu.7>
(b)__A1I 376, AI 218 and AI 298
AI 376
43. AI 376 was first observed on 19 July 1999.” It was identified by Mr Peter Jones and Mr Dave
Parnell of POL’s Interim TIP project team.” In a document signed by Mr John Dicks of Fujitsu
on 9 August 1999, 7 the problem was described as a data integrity issue associated with
imbalances in cash accounts. The document says: “A subpostmaster may be asked to bring to account
an error, but the error was produced by system failure rather than human failure”. POL had categorised
the severity” as high. Pathway said it “[w]ould argue about the severity” and questioned whether
it would “genuinely effect [sic] the accounting integrity”, ultimately categorising the severity as
medium.
44. In circumstances which remain unexplained, a version of this document with an alternative
second page signed by Mr John Pope of Fujitsu and dated 11 August 1999 categorises the
severity as low.*’ A fax authored by Mr Baines on 13 August 1999 confirms that POL maintained
that the severity was high.*! Mr Oppenheim conceded in oral evidence that there was no doubt
7 POL.00028332.
75 T 03/11/22 [81:19-25].
7 POL.00083922, 4; POL00043691, 57.
7 Reid ws/ WITN05210100, § 88.
78 POL.00083922, 4-5.
7 Based on a high level description only: see the evidence of Mr D‘ Alvarez at paragraph 22.2.2 above.
80 POL00043691, 57-58.
® POL00083922, 1
11/78003245_1 16
SUBS0000016
SUBS0000016
about the fact this was a “show stopper”, and that any categorisation other than high severity
was indefensible.
45. On 16 August 1999, AI 376 was one of three disputed high severity or category A faults
remaining at the conclusion of the CSR Operational Trial Review Period, which prevented
acceptance on that target date (which was specified in the Codified Agreement).* The other
two disputed high severity incidents were AI 218 and AI 298.°°
46. As noted above, the First Supplemental Agreement provided for a series of joint workshops, to
be held between 20 August 1999 and 17 September 1999, for the purposes of agreeing upon
resolution plans for faults of agreed and disputed severity.*
47. Seven workshops went ahead. Minutes*’ produced after the seventh and final workshop on 17
September 1999 (a week before the revised target date for Acceptance under the First
Supplemental Agreement) recorded that POL insisted that “rollout should not commence until
data integrity can be assured”. Fujitsu suggested that national rollout could resume if, by the time
of a review in November, there had been four consecutive weeks of operation with an error rate
of equal to or less than 1.5%. Mr Baines and Ms Ruth Holleran (now Ruth Reid - who
championed the resolution of AI 376)* insisted, and Mr Oppenheim essentially conceded, that
the rectification plan for AI 376 should be 0.6% for six consecutive weeks (in addition to six
other success criteria). Fujitsu would also put an integrity control in place by 31 December
1999.8
48. The rectification plan for AI 376 can be found at Schedule 2 section 8 of the Second
Supplemental Agreement (to be read alongside document CR/ACD/376).” Notably, clause 8.3
of Schedule 2 stated: “When the TIP Integrity Checking Period ends, POCL will close AIN 376”.
49. The TIP Integrity Checking Period was defined as “the period from the date of this Agreement until
the expiry of a period of four consecutive weeks after the Accounting Integrity Control Release Date in
which the TIP Integrity Checking Process shall have identified no Cash Account Discrepancies not also
identified by the Accounting Integrity Control Release”.?' The “Accounting Integrity Control Release”
was a software release which would “provide a simple validation, that the transactions and data
© T 26/10/22 [70:23-25, 71:12].
8 T 26/10/22 [74:15-17].
“ WITN06650100, Fujitsu Corporate Statement, [§ 123-124].
*® WITN06650100, Fujitsu Corporate Statement, [§ 124(b)].
86 FUJ00000485, clause 2.1.
*” FUJ00079176, 9.
88 Reid ws/ WITN05210100, § 12, § 87.
* POL00083907, 4.
% Commencing at page 126 of POL00090428, dated 23 September 1999.
* POL00090428, clause 1.4.
11/78003245_1 17
SUBS0000016
SUBS0000016
recorded at the counter, matched the data in the POCL back end systems”? The underlying premise
was that it should generally be possible to identify each instance of error and to determine the
correction to be applied to each one.” It would not necessarily address the root cause of issues
especially if they occurred in-branch: these would be addressed with the assistance of the
Helpdesk and second and third line support.”! The Accounting Integrity Control Release Date was
apparently in December and certainly by the end of 1999 — by virtue of its actual deployment
at approximately that time and the operation of clause 1.4 of the Second Supplemental
Agreement.” “TIP Integrity Checking Process” and “Cash Account Discrepancies” were defined by
way of clause 7.1 of the Second Supplemental Agreement, which, essentially set up a process
by which POL would on a weekly basis create a cash account based on the information it
teceived across the TIP interface against an electronic cash account produced by Fujitsu and
report any discrepancies to Fujitsu.
50. Insummary, the contractual position was that AI 376 would be closed when POL had identified
no discrepancies which had not already been flagged by the Accounting Integrity Control
Release, for a period of four consecutive weeks.
51. A Fujitsu Monthly Progress Report for January 2000 addressed “Acceptance Loose Ends”.°* The
document states that Als including AI 376 and AI 218 are “Closed / incapable of further update”,
that POL would agree if “pressed”, and that the “formal measurements for Als 376, 408 and 298
continued until the end of CAP42 (12/1) and are now completed”. It stated that “the outturn on AI
376 was 0.06% Cash Account Discrepancies, exactly an order of magnitude better than the target.”** As
such the success criteria in schedules 4 Parts B(i) and D(i) of the Second Supplemental
Agreement relating to at most a 0.6% error rate had been achieved and could not in and of
themselves stall rollout on 24 January 2000.
52. Accordingly, POL agreed that it would not suspend rollout, in clause 2.1 of the Third
Supplemental Agreement signed on 19 January 2000.” However there is no evidence that POL
agreed that AI 376 was closed at this stage. This would only occur at the end of the TIP Integrity
Checking Period, per Schedule B section 8.3 of the Second Supplemental Agreement.
53. On 20 March 2000, Mr Baines wrote to Mr Oppenheim, stating that:
“The Second Supplemental Agreement (in clause 7.1) provided for a TIP Integrity Checking
Period, during which POCL would reconcile transaction and cash account data received in TIP
* POL00090428, clause 1.4 read with T 26/11/22 [124:16-19]. See also T 10/11/22 [110:4-9].
°* Oppenheim ws/ WITN03770100, § 124(4).
T 26/10/22 128:21-133:13.
°%® See Reid ws/ WITN05210100, § 118; T 10/11/22 [100:3]
%6 FUJ00058189.
°*” FUJ00058189, 25.
°8 FUJ00058189, 26.
% FUJ00118186.
11/78003245_1 18
SUBS0000016
SUBS0000016
from ICL Pathway. This period was to continue until four consecutive weeks without discovery
of any Cash Account Discrepancies not found by the Accounting Integrity Control Release.
Tam pleased to be able to confirm that this condition has now been satisfied, with satisfactory
explanations having been received by POCL from ICL Pathway for the small number of
apparent discrepancies that were found.”
54. The reference to satisfactory explanations may relate to an obligation imposed on Fujitsu by
clause 5.3 of the Third Supplemental Agreement. This required Fujitsu to provide, upon
request, an explanation of the root causes of Cash Account Discrepancies and the measures it
took to prevent the recurrence of Cash Account Discrepancies which would not have been
detected by the Accounting Integrity Control Release, until the end of the TIP Integrity
Checking Period.
55. It seems reasonably clear from Mr Baines’ letter, read against Schedule 2 section 8.3 of the
Second Supplemental Agreement, that POL considered AI 376 closed as of 20 March 2000.
What, if any, measures were taken by Fujitsu or POL in relation to problems that would have
been associated with AI 376 (if it were not closed) beyond 20 March 2000 is unclear. Evidently
problems with cash imbalances did continue into the year 2000, although it is unclear whether
these could be related back to AI 376 or some other problem connected to the instability of the
EPOSS product.' This was demonstrated by a Fujitsu PinICL record from 16 May 2000 to 14
September 2000,'"' considered in evidence by Terence Austin," which culminated with the
statement “hope for the best with the C14 code which should make this type of incident very rare”.
AIL 298
56. AI 298 related to system instability as the counter system was subject to system freezes or
“lockups” which manifested in the system “hanging” or presenting a blank blue screen. It was
raised in July 1999 following a number of incidents raised with the Horizon IT System
Helpdesk. A document prepared by POL in relation to AI 298 dated 15 August 1999 recorded
that the business impact of AI 298 was that every incident resulted in a system freeze followed
by rebooting the system. This meant that the counter could not be used for approximately 40
minutes which impacted on customer waiting times and also had a financial impact on POL."
57. In August 1999, POL rated the severity of AI 298 as high on the basis that it clearly amounted
to a “Failure to meet an Acceptance Criterion which would have a substantive impact on the
100 T 27/10/22 [47:19-22].
101 FUJ00067416.
12 T 27/10/22 [47:25-54:17].
13 POL00028337.
11/78003245_1 19
58.
59.
60.
SUBS0000016
SUBS0000016
service received by the customer”. Fujitsu rated the severity of AI 298 as low, but POL believed
this was because the statistics on which Fujitsu based this rating were incorrect.'*
By 15 August 1999 POL recorded that Fujitsu had not yet provided POL with an analysis of the
causes of the system freezes and lock-ups. Fujitsu had presented statistics which suggested that
the incidences of occurrence were reducing and were therefore preparing to take a passive
approach based on ongoing analysis followed by a formal review after three months. POL
considered this proposed approach to be unacceptable for a number of reasons, including that
it could result in the System being rolled out with all the current problems remaining
unresolved. POL’s document on AI 298 stated “Unfortunately the majority of the activity by
Pathway to date has been attempting to deny that a substantial problem exists rather than solving the
problem’ 1°
AI 298 was discussed at a number of the acceptance workshops that took place between 20
August to 17 September 1999. In a letter from Mr Miller to Mr Stuart Sweetman dated 8
September 1999, Mr Miller explained that AI 298 was still a problem and was being actively
worked on. At the seventh acceptance workshop on 17 September 1999, Fujitsu tabled an
updated resolution plan. Mr Meagher reported general satisfaction with progress and the
resolution plan was agreed subject to final review by Mr Folkes and Mr Booth and inclusion of
incident workarounds. It was agreed that the long term target should be an average of one
incident per four months. However, there was some disagreement on the metrics used to assess
incidents and this issue was to be escalated to Mr Miller and Mr Richard Christou.!” Mr Peter
Copping, who attended the meeting between Mr Miller and Mr Christou following the seventh
workshop, recalls that the parties failed to find a solution at this meeting."
Schedule 4 Part A of the Second Supplemental Agreement set out the rectification criterion for
AI 298 which was that by 24 November 1999 the total number of units reported to the Helpdesk
in relation to the relevant outlets in which rollout had occurred was not to exceed the aggregate
number of counter positions in those outlets multiplied by the fraction 4/13. Fujitsu’s Monthly
Progress Report for September 1999 recorded that following the Second Supplemental
Agreement, performance measures relating to Al 298 would be monitored during October and
the first half of November 1999 and reviewed to see if the criteria had been achieved by 24
November 1999.1
104 POL00028337.
105 POL00028337.
106 POL00028465.
197 FUJ00079176.
18 Copping ws/ WITN03970100, § 47.
10° FUJ00058186.
11/78003245_1 20
SUBS0000016
SUBS0000016
61. Ina POL document regarding a decision on roll-out dated 17 November 1999, POL stated that
in anticipation of the relevant criteria not being met by the agreed date of 24 November 1999,
POL was proposing that existing monitoring activities should continue and be strengthened. In
relation to AI 298, POL suggested that Fujitsu at its own expense develop a codified and
structured fault recording system and that the monitoring ongoing at that time should continue
for a further four weeks with the same target.'"” However, Fujitsu’s progress summary for a
delivery meeting on 15 December 1999 stated that AI 298 monitoring had officially ceased
although monitoring was continuing at a less formal level. The weekly incidents since the end
of the official monitoring period had remained below the target and Fujitsu was seeking closure
of AI 298.""! Fujitsu’s Monthly Progress Report for December referred to the “clearance” of AI
298, but closure still continued to be sought.'”? Fujitsu’s progress summary for input to a
delivery meeting on 12 January 2000 confirmed that by this date AI 298 had been closed."
There does not appear to be any evidence before the Inquiry setting out the basis for closure.
Al218
62. AI 218 was an incident which POL raised in May 1999 in relation to the effectiveness of Fujitsu’s
training for Horizon users. POL considered the Managers Training Course to be inadequate
due to deficiencies in the accounting modules. POL considered that the training given did not
equip users to perform the completion of office cash accounts, which was a basic function that
was central to running and accounting for the POL network.! POL rated this AI as high
severity and Fujitsu rated it as medium severity.!'5
63. POL wrote to Fujitsu on 10 August 1999 enclosing an evaluation of the business impact of AI
218 and confirming that POL was not prepared to reduce the severity rating of AI 218 from
high. The evaluation stated that the Office Managers’ ability to undertake daily balancing and
produce a cash account was adversely impacted resulting in a failure to support accurate POL
accounting. The amount of time taken to produce the cash accounts was excessive. The number
of cash account related incidents being reported was also considerably greater than expected."
64. Fujitsu responded on 11 August 1999 stating that Fujitsu was convinced that it had done
everything it could to improve the training and prepare users for Horizon, and that the essence
of the remaining issues related to POL’s own management of change. Fujitsu believed AI 218
should be closed and did not accept that any further revisions to the training courses were
4° POL00028557.
111 FUJO0118202.
42 FUJ00058188.
115 FUJ00079142.
46 POL00028365.
11/78003245_1 21
SUBS0000016
SUBS0000016
required.” Fujitsu prepared an acceptance proposal for AI 218 dated 23 August 1999 which set
out why Fujitsu proposed that AI 218 could be categorised as closed.
65. Ina letter from Mr Miller to Mr Sweetman dated 8 September 1999, Mr Miller stated that Mr
Bruce McNiven and Ms Holleran had done excellent work squeezing a better training deal out
of Fujitsu. The incident remained high because of the need to support training with a better
Helpdesk facility. However, this would in all likelihood be downgraded to a medium incident
with an agreed rectification plan and therefore would not be an obstruction to acceptance."*
Fujitsu’s Monthly Progress Report for August 1999 reported that AI 218 was reduced to
medium severity on 9 September 1999.
66. AI 218 was discussed at a number of the acceptance workshops that took place between 20
August to 17 September 1999." A rectification plan was developed. However, as at the seventh
acceptance workshop on 17 September 1999, re-drafting of the resolution plan was still
required’? and AI 218 was included in the list of outstanding Als in the Second Supplemental
Agreement.
67. Fujitsu’s Monthly Progress Report for September 1999 recorded that progress continued to be
made on the resolution plan for AI 218. The main element of the resolution plan was the pre-
entry event, which would demystify computers, introduce standard balance terminology,
explain the ‘manual to automated’ change and give the user hands-on experience.!”! This had
been fully specified and a dry run had been performed for POL and approved by them. The AI
218 resolution plan remained on track to complete within the allocated time scale.!” A Fujitsu
progress summary for input into a delivery meeting on 27 October 1999 stated that the pre-
entry event actions were complete. POL had made amendments to its contribution and the
event was to be signed off on 28 October 1999. Progress against the resolution plan continued
to be on schedule.’
68. Fujitsu’s progress summary for input to a delivery meeting on 10 November 1999 recorded that
Fujitsu had completed the vast majority of its actions on the rectification plan, although some
POL actions were outstanding.'* A further progress summary for a delivery meeting on 24
November 1999 recorded that all Fujitsu actions on the AI 218 rectification plan were complete
although there were still some actions that required POL to complete which would fully close
47 FUJ00079159.
48 POL00028465.
118 FUJ00058185.
20 FUJ00079176.
121 FUJ00079169.
'UJ00058186.
FUJ00079184.
11/78003245_1 22
SUBS0000016
SUBS0000016
AI 218.15 Fujitsu’s Monthly Progress Report for December stated that implementation of all
actions from AI 218 had been completed, and POL had accepted the work was complete and
had closed the incident.!7°
(c)__ Overall View on Acceptance
69. Mr Folkes’ view at the time of acceptance was that POL followed due process on dealing with
Als and rectifications and had dealt satisfactorily with each of the issues which had been found.
Mr Folkes considered that POL performed as effective a scrutiny as it could given the nature of
the contracts with Fujitsu and Fujitsu’s behaviour and attitude towards POL and assurance in
particular.!”7 However the overall stability of the System and integrity in the full live operation
was still to be proven. While Mr Folkes had concerns about the lack of assurance, he thought
that going cautiously to the next stage was not unreasonable.'5
70. Mr Andrew Simpkins felt that as at January 2000 there were surprisingly few outstanding Als
and that it had been reduced to a manageable number of medium and low priority problems.”
He did not believe the situation could be characterised as one where the Horizon IT System was
rolled out with lots of known serious bugs. While there were a number of continuing problems,
there were no high priority incidents outstanding at final acceptance.'*°
71. Mr Meagher also considered that POL scrutinised the technical reliability and robustness of
Horizon to the maximum extent possible, given the constraints placed on the assurance process
by the PFI contract."
72. Mr Copping stated that most organisations would have been severely tested by the Horizon
proposal from Fujitsu. POL had no real experience or capability in complex systems
implementation or branch network automation. POL’s ability to recruit the technical people to
work on the project was severely limited and the uncertainty created by the absence of any
agreement with Government on POL business strategy meant POL was often unable to respond
with certainty on many technical and operational issues as the programme proceeded. Given
these constraints, Mr Copping believed the Post Office did its best to effectively scrutinise the
technical integrity and robustness of Horizon, pre-acceptance.!?
225 FUJ00118181.
26 FUJ00058188.
27 Folkes ws/ WITN05970100, § 191.
128 Folkes ws/ WITN05970100, § 151, 183 and 185.
29 T 03/11/22 [87:8-24].
15° Simpkins ws/ WITN06090100, § 22.
15! Meagher ws/ WITN04150100, § 27.
1 Copping ws/ WITN03970100, § 53.
11/78003245_1 23
SUBS0000016
SUBS0000016
73. Mr Meagher confirmed that no external pressure was ever applied to him to prevent
cancellation of the Horizon IT System.'* Mr Paul Rich also stated that he would find it really
hard to believe that anyone in POL at the time would have compromised quality knowingly, in
order to be expedient or to suit strategic or financial matters.'
74. Mr Austin’s evidence was that he was not aware of any political pressure for the roll out to
occur when it did, rather this was determined by the readiness and robustness of the System."°5
Mr Jonathan Evans also confirmed that he did not feel any political pressure.’ Mr D’Alvarez
stated that although there was always pressure, if he or his team said that they were not ready
to go with their products then he would be supported by his management (Mr Coombs and Mr
Austin).17
75. As far as the POL Board is concerned, Mr John Roberts gave evidence that in July 1999 the Board
was aware that there were still issues with Horizon which needed to be solved, but the
understanding was that this should not hold POL up from accepting the product. The Board
knew that the system would not be perfect, but that work would continue after it had been
accepted.'* In September 1999, it was reported in Board minutes that serious doubts over the
reliability of the software remained and there were still three high priority Als outstanding.'°
However, Mr Roberts felt that considering where POL had come from, getting it down to that
was pretty good. The impression Mr Roberts had was that the faults were rectifiable.“”
76. Mr Evans did not believe that any information was deliberately withheld from the Board, but
it may have been that the problems with Horizon were not seen to have the degree of
significance and seriousness that in hindsight they should have been. It was a large organisation
and messages could get crowded out.!*!
77. Overall the sense from both POL and Fujitsu witnesses was that, while imperfect at the point
of acceptance, the System was at a stage where it could reasonably be rolled out so that it could
be trialled in more offices.
7 December 2022
153 Meagher ws/ WITN04150100, § 29.
14 T 21/10/22 [89:2-5].
+5 Austin ws/ WITN04190100, § 36.
136 T 4/11/22 [39:22].
157 T 08/11/22 [68:10-15]; T 08/11/22 [69:9-11]
188 T 20/10/22 [88:18-89:22].
:13-93:19).
M1 T 04/11/22 [103:10-12]; T 04/11/22 [104:25-105:2]; T 04/11/22 [104:11-14].
11/78003245_1 24