WITN05290100
WITN05290100
Witness Name: David Smith
Statement No.: WITNO529_01
Exhibits: WITN0529_01/1 —
WITNO529_01/11
Dated: 30/08/2022
POST OFFICE HORIZON IT INQUIRY
FIRST WITNESS STATEMENT OF DAVID SMITH
1, DAVID SMITH, will say as follows...
INTRODUCTION
4. This statement is in response to the Rule 9 request dated 21% July 2022. It
is in relation to Phase 2 of the Post Office Horizon IT Inquiry and in
particular to the development, testing and acceptance of the Horizon IT
System.
BACKGROUND
2. I was asked to set out a brief professional background.
The first part of my career was spent at BEA and British Airways where I
worked as an auditor and route division accountant before eventually
becoming Financial Controller and Company Secretary of British Airways
Helicopters. Having successfully supported the disposal of the Helicopter
Page 1 of 26
WITN05290100
WITNO5290100
operation by BA and after a period of working under the new ownership I
took voluntary redundancy from BA joining the Post Office in July 1987.
. The first part of my career in the Post Office was in Finance. As Chief
Financial Accountant I was responsible, inter alia, for back-end accounting
for offices. As POCL reorganised my role in Finance changed to Financial
Controller and then to Head of Finance Executive. I was appointed Director
Central Services Group in July 1996 with a brief to break up this directorate
and redistribute it across other organisational units. During this period I
retained my responsibilities as Head of The Finance Executive. In April
1997 I was prevailed upon to become Head of Automation Transformation
commencing an association with the Horizon system that was to last until I
left the Post Office at the end of March 2010.
. I was asked to describe my role in relation to the Pathway Project/the
Horizon IT system.
Prior to my appointment as Head of Automation Transformation I had little
direct involvement with the Pathway project.
After a procurement exercise French Thornton were appointed to establish
Programme Management within POCL. Their proposal was for the
Programme team to be formed by French Thornton personnel but to then
assist the business identify a suitable individual to be trained in the
Programme Manager role. They would support this individual whilst he or
she identified individuals to fill other roles in the team phasing out French
Thornton staff once these POCL replacements were up to speed. Initially
my colleague lan Gibbard was appointed but he asked to be relieved of the
Page 2 of 26
WITN05290100
WITN05290100
I was approached to replace him and after some
persuasion assumed the role in April 1997.
. This role involved co-ordinating all the projects and business as usual
activities necessary to deliver the business benefits of automating the
counter.
This involved identifying the touch points between activities, managing
interdependencies and points of friction with activities outside the
Programme, maintaining and supporting governance structures, maintaining
a programme plan incorporating the dependencies and touch points,
managing programme issues and risks and providing assurance of project
activities.
. What this role did not involve was the line management of projects. My
authority over the projects was derived through the Automation
Transformation Steering Group whose membership was made up of the
Directors of the business (some of whom were project sponsors)
supplemented by the Group CIO, business Head of IS and Paul Thornton of
French Thornton.
. On the creation of Post Office Network I became Automation Director
assuming line management of Horizon and all other IT based projects that
fell within the business unit control. I retained Programme Management.
This meant I had direct contro! of Horizon through the final throes of
acceptance, the roll out and the delivery of Core System Release plus (the
system was delivered in two phases). The second phase was delivered to
Page 3 of 26
WITN05290100
WITN05290100
those branches that had migrated to Horizon, c 10,000, via telephone and
the remainder of the roll out was executed with the updated software.
8. Tensions between business units, in part surfaced through programme
management, caused Stuart Sweetman to bring most of the former POCL
back together as POL. I became Programme Integration Director in effect
the same role that I had as Head of Automation Transformation. In January
2003 I became IT Delivery Director once again assuming line management
control of projects including Horizon in addition to programme management.
9. In June 2004 I became Acting IT Director on the departure of Alan Barrie
back to Royal Mail. I was, therefore, in charge of developing the proposition
that became variously known as HNG X or Horizon Online. The Delivery
Director role remained my responsibility. It was decided to create the role of
Operations Director to replace that of IT Director. Property, Security, Cash
Management, Service Management and Commercial were to join IT in
reporting to this new role. On the arrival of Ric Francis, as Operations
Director, in February 2005 I became General Manager IT. A later business
reorganisation was to expand my role to include the management of all
business change across the business (within directorate change excluded).
My title became Head of Change &IS. For a 3 month period in 2009 I was
acting Operations Director covering the period between Ric Francis’
departure and Mike Young’s arrival. I left the Post Office at the end of March
2010.
10.An early organisational decision separated the project management of IT
from the day to day management of IT systems (including problem
Page 4 of 26
WITN05290100
WITN05290100
management). My involvement in day to day system problems was
restricted to major system outages where my team would usually assume
control.
PROCUREMENT
11.1 was asked to describe the nature of my role in the procurement of the
Horizon IT system. I had no direct role in the procurement of the Horizon IT
system i.e. I was not part of the POCL team carrying out this task. During
the procurement period I was Head of Finance Executive and as such I was
asked by those working on the procurement, according to POL00031276
[WITN0529_01/1], POLO00031277 [WITN0529_01/2] and POL00031278
[WITN0529_01/3] to review how outlets were accounted for. I have
absolutely no recollection of this.
12. Re-engineering the end to end cash accounting process, including branch
accounting, client settlement and head office accounting, would have
required an in depth study. Significant change to back-end systems, quite
possibly complete replacement, was almost certainly necessary for re-
engineering. The business had not carried out this analysis and thus when
the invitation to join with the Benefits Agency came along it was ill prepared.
Any business benefit that might have flowed from end-to-end process re-
engineering was thus foregone. In my opinion, however, the major benefits
from automation were to flow from the automation of products.
13.1 was asked how office balancing and cash accounting operated prior to the
implementation of Horizon. As I was responsible for the Head Office
Page 5 of 26
WITN05290100
WITN05290100
accounting for branches, I spent considerable time at the beginning of my
employment with POCL familiarising myself with the Head Office processes.
There was a lot of detail much of which escapes me now and it is possible
that the following description excludes some key points.
14.Cash Accounting was an end-to-end process of which office balancing and
cash account production were a part. When a new product was process
designed the counter was never designed in isolation but always as part of
an end-to end process.
15. The cash account was a summary of the business transacted in a branch in
that cash account week. There were separate lines for each product/product
group, for value stock and cash holdings.
16. Starting from the previous weeks cash balance the value of transactions,
the net movement in stock (as ascertained by physical stock check), the
adjustment necessary for payment by cheques and adjustment for
remittances in and out of branch would be brought together to calculate the
closing cash balance. This would then be compared to the physical cash in
the branch. If the cash figures i.e. book and physical agreed then the cash
account could be signed of and sent to Chesterfield.
17.\f book and physical values disagreed the branch would have to investigate
the difference. Branches would either find the source of the difference and
adjust the cash account accordingly, declare the discrepancy or defer the
discrepancy to be resolved later. There was a suspense line on the cash
account but I’m afraid my memory fails me on its use both intended and
unintended.
Page 6 of 26
WITN05290100
WITN05290100
18. The numbers on the cash account were the basis of settlement with clients.
As such it was important that they were accurate. To ensure accuracy there
was a significant checking exercise carried out in Chesterfield. The cash
account group in Chesterfield was over 200 strong. A separate unit just to
deal with Pensions and Allowances was even larger in size and a third
group processing Postal Orders about 80 strong. There was also a unit in
Edinburgh mirroring the Chesterfield operation dealing with Scottish
branches.
19. Supporting documents consisted of transaction tokens and summary
dockets/batch headers. Transactions would be checked to summary
dockets and summery dockets to the cash account. Whilst most of this
checking was carried out at Chesterfield and Edinburgh the document
streams for National Savings and those for Girobank were checked by those
businesses.
20. Over five thousand errors per week were detected. Many of these would
result in the issue of an error notice. This would be sent to branch who
would be required to include the adjustment on their next cash account. This
would clear any discrepancy arising from the error in the office balance.
21.This was a vast paper industry. Pensions and Allowances vouchers alone
had a dedicated weekly freight train to deliver them to Chesterfield. A full-
time post room of around 20 postmen used to sort the pouches in the
mailsacks and distribute them to the appropriate regional based team. Such
was the volume of these vouchers that offices were checked on a rota basis
Page 7 of 26
WITN05290100
WITN05290100
only. I think that a branch would only be checked every 2-3 years unless on
some kind of alert. As such this area was particularly prone to fraud.
22. Cheques were remitted on a daily basis, consolidated by Royal Mail and
delivered to a dedicated processing unit in London. Cheques were agreed
to branch generated batch headers and errors generated where necessary.
The overnight processing was aimed to meet the timescales for the London
clearing house system.
23.Sales of stock worked somewhat differently. All branches had a stock
remittance unit who would supply them with stock and withdraw stock when
an item was discontinued. The stock sales were calculated by totalling up
the numbers for all branches attached to a remittance unit together with the
balance for that unit.
24. The five thousand plus errors mentioned above were merely the tip of the
iceberg as far as error in the overall process was concerned. A recently
graduated MBA conducted an exercise, at my request, to measure the level
of error in the process and she estimated this to be 100,000 per week. To
be clear the vast majority were not financial based errors, but they did
require rework. For example, PIVOT was a transaction volume reporting
system piggy backing on the cash account and this alone generated
¢25,000 errors per week.
25.Non-Conformance to business procedures was a big contributor to this level
of error.
Page 8 of 26
WITN05290100
WITN05290100
26. Branches were subject to audit. I can’t recall the periodicity but there was a
risk basis embedded in the model. Audit would discover cash discrepancies
that in some cases would lead to prosecution
27.Whilst the majority of branches prepared manual cash accounts a number
generated their cash account by computer system. The Post Office owned
branches (and some larger sub offices?) used a system called ECCO. This
was used fo record all transactions. Within the M25 it also had a pensions
and allowances order book stop system and was called for these branches
ECCO+. POCL’s requirements for Horizon were based on ECCO+ I
believe.
28.A sub-postmaster named Richard Jackson produced a software package for
cash account production. This was approved for use by POCL. I have no
recall of its functionality or the numbers of branches using it. Group IT also
produced a product also approved for use by POCL. I have little recall of
this other than it existed.
29.1 was asked in what ways did office balancing and cash accounting change
as a result of the introduction of Horizon. It is important to bear in mind that
the initial release of Horizon did not automate any product that wasn’t
already automated i.e. bill payments. It did accumulate the value of
transactions as they were entered on the system. It did allow the capture of
stamp sales. It did close down some of the things that branches could do in
the manual system to hold over discrepancies for later investigation. My
memory on this is quite hazy and I am quite sure the above is far from
comprehensive.
Page 9 of 26
WITN05290100
WITN05290100
AUTOMATION TRANSFORMATION
30.1 was asked to describe the purpose and function of the Automation
Transformation Steering Group. This body was the Programme Board for
Automation. It was the ultimate Programme authority. The following is a list
of typical programme board responsibilities
* appointing a Programme Manager
* approving programme identification and definition
e agreeing programme plans
¢ agreeing and communicating the programme vision
* communicating progress to interested parties
« ensuring the required resources are available
e resolving any conflicts escalated to it
« reviewing issues and risks
¢ quality assurance for the programme and its constituent projects and
business as usual
* approving programme implementation reviews and lessons learned
« ensuring that a post-programme review is scheduled and takes place
There are numerous readily accessible references online describing the role
of Programme Boards and Programme Managers.
31.1 was asked to address concerns about the quality of the Horizon Project as
referred to in red light issues POL00028324 [WITN0529_01/4] refers. This
Page 10 of 26
WITN05290100
WITN05290100
document was the minutes of the ATSG in June 1998. Before I address the
specifics of the minute, I want to set some context.
32.In a project environment working with a supplier has quite a different feel
where there is trust and confidence and when there is not. From my
perspective there was little trust or confidence in Pathway to deliver.
Delivering to time builds trust. Consistently missing deadlines and not being
open about slippage does not.
33. The PFI basis of the contract did not help. This would have been quite foreign
to many of those involved. It was explained by solicitors acting for POCL in
the following way. In a traditional relationship if you wanted the means to put a
hole in a wall you would specify a drill suitable for the job. In a PFI deal you
would specify the hole. Add to this that Pathway were able to “Black Box” the
build and this is hardly a recipe to build confidence in any eventual solution. At
Pathways request POCL supplied staff to assist them in testing, but they were
required to sign NDAs to prevent them from sharing within POCL what they
were learning about the solution.
34. The decision to contract ahead of agreeing all requirements also in my mind
played a part. Foreign encashments was a requirement that cut across the
design that Pathway were working too. Were there other such conflicts?
35. Finally, it was known that work on the desktop started in London but was then
sent across to the US before being sent back to the UK for completion. This
created some suspicion that Pathway weren't up to the task.
36. There are always issues that arise in a project with the potential to derail
delivery. Working with a supplier where there is trust and confidence in the
Page 11 of 26
WITN05290100
WITN05290100
ability to deliver, such issues will be viewed with an expectation that solutions
will be found. Where that confidence is missing, however, concern about
issues will be if anything amplified by lack of confidence in the supplier. I
believe this was very much the case with Pathway and Horizon.
37. I was asked what in particular were the issues identified in relation to testing
and EPOSS. As far as the former is concerned I cannot recall any of the detail
and cannot comment on the evidence. However, Model Office and End to End
testing were POCL driven aimed at proving procedures and that business end
to end processes worked as they were meant to. This required the delivery of
a “clean” build into these tests. The clear message here was that testing
coverage was falling short of plan and that there was a risk that this would not
be recovered before POCL testing began. A build that had not been fully
tested or carried forward significant level of errors would undermine the
effectiveness of POCL testing. Tracking through ATSG minutes
(POL00028321 [WITN0529_01/5], POL00028322 [WITN0529_ 01/6] and
POL00028323 [WITN0529_01/7]refer) it is clear that this risk manifested itself.
38.The June 1998 ATSG minutes are not particularly helpful on the EPOSS
issue, there is a heading but no description, but by looking at the minutes of
subsequent meetings I believe the issue is that concerning the £3.1 m of TP
errors. I have absolutely no recollection of this item but there is sufficient
information in meeting minutes to give a broad idea of this issue.
39. There was a network of around 10,000 terminals used for certain payments
for utilities. The data centre for these terminals was based at the Group IT
facility in Farnborough. This network was to be retired but this was dependant
Page 12 of 26
WITN05290100
WITN05290100
on the delivery of CSR+ and then a complex migration from Farnborough to
Pathway.
40.Recording these transactions on the cash account gave rise to a new area of
cash accounting errors. The Service Development Team (a unit dedicated to
supporting take on to this network) took the actual errors occurring on the
cash accounts of ECCO offices and extrapolated these to the extended
network which is the derivation of the £3.1m. This £3.1m of errors was,
therefore, predicted new errors and was a workload burden not yet being
experienced. The reason for using ECCO as the baseline was that it was also
used as the basis of POCLs requirements for Horizon. The action was to doa
workload assessment so that TP could be properly prepared. With experience
already of the work required to correct these errors estimating the workload
impact would have been relatively simple. Minutes imply a fix of some sort
would be possible, but this would not be available until a future software
release. The issue would be resolved with the retirement of this network of
small terminals. There is reference to slideware being attached to the ATSG
minutes in POL00028323 and retrieving these would I suggest clarify this
further.
4
a
.I was asked to describe the nature of the work I carried out in relation to
EPOSS design. I must reiterate that I did not manage Horizon and it was
normally for the Horizon management team to manage the project issues and
risks. I did, however, step in on this issue. I commissioned a French Thornton
consultant, Darren Bosco, to see what if any information he could glean from
Pathway about EPOSS design. Against expectation Pathway allowed him
Page 13 of 26
WITN05290100
WITN05290100
inside the “Black Box” for 24 hours. Darren presented his findings to the
ATSG. Addressing a largely non-technical forum he would have simplified his
presentation so that it was accessible.
42.1 do have some recollection of this presentation, but by no means all of it.
Darren had expected to find a modular design. In such a design, new
transactions could be added without impacting existing transactions.
Interfaces would be established with some other modules e.g. a cash
accounting module. There would be exchanges of data but the software would
not be linked.
43.What he discovered was that all transactions would be rooted in a core
horizon. The implication was that when a new transaction was added it would,
through this core, be linked to other transactions and it could impact i.e.
introduce error, into pre-existing transactions. A consequence of this was that
extensive regression testing would be necessary every time a new transaction
was added to ensure that the legacy had not been corrupted. This distorted
the normal relationship between time in development and time in testing.
44.He did observe that the solution enabled rapid development of new
transactions. A transaction could be developed in days rather than weeks and
months.
45.As far as moving away from this design was concerned, he reported this could
not be achieved by tinkering around the edges (my words!) something
different would require starting over again.
Page 14 of 26
WITN05290100
WITN05290100
46. There may well be important detail that I have not recalled. Darren’s slideware
will have been attached and if it can be retrieved may well be of assistance to
the Inquiry.
47. lt needs to be remembered that under PFI rules design was for Pathway and
Pathway alone. We know the BA service requirements drove Pathway away
from a banking RAC model to a distributed system of authorisations. This was
because they did not believe that the public telephone network could support
the service levels required by BA. The decision to use Escher’s Riposte
product was driven at least in part by this product being designed to be
resilient when working with dial up networks. It maybe that the full benefit of
this resilience was only achieved by using Riposte for the desktop but that is a
consideration outside my skill set. Several foreign Post Offices only used
Riposte as a middleware product — I think Deutsche Post was amongst those.
48.1 was asked about Model Office and end to end testing. The initial concerns
arose from evidence of Pathway slippage against their testing plans and the
fear that these POCL rounds of testing would be significantly less effective in
proving processes and procedures than was required. This risk materialised.
At the time there would have been a log of errors and the Horizon project will
have tracked rectification activity. A further 4 week testing window was driven
into the plan to ensure that all planned testing could be completed. The issue
of integrity of files passed from Pathway to POCL remained an issue and a
new dimension surfaced late during the acceptance process and was deemed
category A (i.e. grounds for not accepting). This was about the lack of integrity
controls within Pathway. The rectification plan for this was closely monitored
Page 15 of 26
WITN05290100
WITN05290100
by members of my team in addition to the activities of the Horizon project
team.
REVIEW OF POCL AND ICL PATHWAY DEAL
49.1 was asked various questions on this review. POL00031230
[WITN0529_01/8] refers. My understanding of the purpose of the review will
have been exactly as Roger Tabor states in his introduction i.e.to stand
back and review the deal as independently as possible to see if it remains
sensible. My role in the review was as one of the senior managers
interviewed by Roger.
I have no recollection of what I said during my interview with Roger. I do
recognise the risks listed at paragraph 2.6 and would agree that it was proper
for them to be recorded in the report. I’m certain I would have taken a
balanced approach to my input to Roger and I would have highlighted both
the upsides and downsides of continuation.
The substance of the conclusions stated in paragraphs 3.4 — 3.6 are
“motherhood and apple pie”. It is difficult to see how anyone could or would
disagree with them.
ACCEPTANCE OF THE CORE SYSTEM RELEASE
50.1 was asked to describe my role in the acceptance of CSR. I cannot recall
how it came about and I will not speculate about this but it fell to me to put
together the team to assess the evidence produced by Pathway as part of
Page 16 of 26
WITN05290100
WITN05290100
the Acceptance process. The Acceptance process was very rigorous. For
every requirement there were acceptance criteria and for each criteria the
evidence that Pathway needed to furnish, be it test result, document or
witnessing of an event, specified. Where there was a gap in the evidence it
was crucial to understand the business impact not only at the point of the
fault but also in the wider end to end process.
5
=
.My Business Assurance Manager, an experienced and highly rated former
audit manager, led the substantial team we put together. Ideally every
member of the team would have been an expert in the businesses end to
end process. To do so would have stripped the business of too many key
roles so a blended team of end to end expertise and subject area experts
was put together. Apart from spending time each day discussing progress
and emerging issues with the Business Assurance Manager I took on the
responsibility of turning words in the contract describing fault severity into a
format that was measurable and getting business approval for the
framework so created.
52.1 was also a member of the team supporting Dave Miller in the negotiations
with Pathway through the Acceptance process and various other meetings
with acceptance as a subject matter.
53.1 was asked whether the acceptance timetable was sufficient. To balance
time available — I think, but cannot be certain, 3-4 months — resource and
the volume of data, the team took a risk based approach. By adopting this
tisk based approach the team made sure that the focus remained firmly on
substantial matters and did not get bogged down in trivia. The team
Page 17 of 26
WITN05290100
WITN05290100
undoubtedly worked under pressure but if I had felt at the time that time
pressures meant the business was at risk then I would have called it.
54.1 was asked what the key obstacles to acceptance were. Three categories
of faults were defined in the contract. The most severe of these was
category A with a business impact such that one incident gave POCL
sufficient grounds to withhold Acceptance. Above a certain number (I cannot
recall that number) of category B faults the business was also contractually
entitled to withhold Acceptance. These faults had a less severe business
impact and could usually in the short term be tolerated subject to work
rounds being available. The final category, category C, were minor faults
which could often be described as cosmetic in nature. An example might be
the date and time stamp on a report appearing at the bottom of a report
page and not the top as specified. These faults were usually never rectified
as the cost of doing so outweighed any resultant benefit.
55. There were four category A incidents as called by POCL . They were
training, integrity control, screen freezes/lock ups and the Horizon System
Helpdesk. Under the terms of the contract Pathway were paid nothing for
the development of Horizon until contractual acceptance had been
achieved. Both parties anticipated that the calling of any fault as category A
was likely to be contested. Whilst there was a contractual process for
dealing with disputes ultimately leading to arbitration this was seen by both
parties as taking longer than was desirable so it was agreed to inject Peter
Copping of PA Consulting into the process.
Page 18 of 26
WITN05290100
WITN05290100
56.1 was asked about my position in relation to acceptance and why I opposed
it in September 1999. I do not recall why I opposed conditional acceptance.
From the documents I was asked to consider it is clear that there was a gap
still to be bridged in addressing the acceptance incidents. I would also note
that withholding acceptance and therefore payment of a very considerable
sum of money gave PON a very strong bargaining position when seeking
changes in Pathway’s approach. Conditional acceptance would sacrifice this
bargaining position.
SUSPENSION OF ROLL OUT
57.1 was asked to describe my role in monitoring compliance with acceptance
conditions. I was not directly involved in the monitoring process but rather in
the chain of various meetings, both internal to PON and jointly with
Pathway, to review progress and define further actions where necessary.
Evidence of those meetings is contained in the documents I was asked to
review.
58.1 was asked what I understood to be the root cause of continuing cash
account discrepancies in autumn 1999. I have no recall of this level of detail.
I believe that these were discrepancies observed in the process of
transferring data from Pathway to PON.
59.1 was asked to what extent did Pathway meet the conditions for proceeding
with roll out in January 2000. The position is very clearly set out in
POL00028509 [WITN0529_01/9]. As roll out commenced it is a fair
Page 19 of 26
WITN05290100
WITN05290100
assumption that outstanding TP checks were satisfactorily completed and
that the third supplemental agreement was signed off.
60. I was asked to describe the checks which were put in place to monitor the
6
data integrity and help desk issues. The data integrity checks were carried
out by Transaction Processing. I can’t describe them as I can’t recall them.
My Business Assurance Manager would have probably walked me through
them at the time. Help Desks were not managed in my area. My colleague
Andy Radka was in charge of this area. Through the various meetings I
attended I would have been aware of the outcome of the checks on Help
desks I wouldn’t necessarily have been aware of the checking mechanisms.
.I was asked whether I considered these checks to be satisfactory and my
reasons for thinking so. My Business Assurance team was led by an ex -
auditor. She was extremely tenacious and was all over the integrity issue
and if there had been the slightest doubt about the checks she would have
given it very high profile. There are no such doubts expressed in any of the
meeting material I was asked to consider. For the reason explained in
paragraph 60 I can’t comment on help desk.
62.1 was asked what I understood the integrity control proposal to entail. I
cannot recall this in any sort of detail. A very simple example of this would
be if data was transferred from A to B and the data consisted of x records
totalling the value y at the end of the transfer B should have received x
records value total y. Integrity checks should run through an accounting
system like Blackpool through a stick of rock. They did not.
Page 20 of 26
WITN05290100
WITN05290100
63.1 was asked to what extent did Pathway demonstrate the successful
functioning of integrity control. It is clear from POL00028509 that PON did
not rely on Pathway but instituted its own checks via TP to ensure Pathway
controls were functioning as intended. Six weeks of such checks had been
completed without obvious problems and there was one final week with the
checks to be completed. It is clear that successful completion of this check
was one of the conditions for roll out to commence.
64.1 was asked what concerns I had about the integrity of Horizon when roll out
commenced. POL00028509 [WITN0529_01/9] is the minutes of a meeting I
chaired a few days before commencement of roll out. Had I had concerns I
have absolutely no doubt I would have voiced them. I expressed no such
concerns. My Business Assurance team will have reviewed Fujitsu's
planned integrity controls and the TP checks proved that these controls
were effective.
65. Finally, I was asked what action did I take to report concerns within or
outside POCL. Horizon was sponsored out of PON. Throughout this vital
period Horizon featured at PON Executive management meetings. There
was also a Programme Board attended by all PON Directors. I had frequent
conversations with senior colleagues about progress. Communication
outside the business was undertaken by Dave Miller, PON Managing
Director, who led the high level Acceptance meetings with Pathway. Several
documents witness this communication.
INTERNAL AUDIT
Page 21 of 26
WITN05290100
WITN05290100
66.1 was asked who and for what purpose was the audit report commissioned.
Please refer to the introduction and Appendix A of POL00028440
[WITN0529_ 01/10] where the purpose is explained in considerable detail.
The report was commissioned by the Horizon project.
67.1 was asked what input I had into the comments of the report prior to its
finalisation. I have no recall. However, I would be surprised if Chris Paynter
hadn't walked me through his findings prior to wider circulation. This briefing
was part of standard audit practice.
68. What if any assurances did I give concerning the resolution of issues
relating to transaction processing. This raises an important point regarding
organisation. The management of day to day problems was the
responsibility of Service Management and not the Automation Directorate.
In other words, change was delivered by Automation, business as usual
managed by Service Management.
69. I was asked what action did I take on receipt of the review. None of the
required actions were for the Automation Directorate so I’d be very
surprised if I intervened in matters that were for the Operations Directorate.
However, I have no recall of this report or of having taken any action.
CHRISTMAS HORIZON RESEARCH REPORT
70.1 was asked by whom and for what reasons was the report commissioned. I
was asked about end users concerns and finally what action was taken to
address those concerns. Having read NFSP00000261 [WITN0529_01/11] 1
Page 22 of 26
WITN05290100
WITN05290100
believe the Research Services report and my covering letter to Colin Baker,
both contemporaneous documents, cover these questions comprehensively.
GENERAL
71.1 was asked looking back if I consider PON effectively scrutinised the testing
trial and acceptance of the Horizon system. I believe what we did to be
effective. However, I believe there are much better ways of conducting this
scrutiny than the way it happened for CSR. If the ways of working adopted
from S50 onwards through to S90 had been adopted for Core System
Release I believe that the journey through to roll out of Horizon would have
been smoother and the process of scrutiny easier. That involved Fujitsu
involvement in requirements analysis, POL having full visibility of the
intended design, a joint approach to testing and a rather more collaborative
approach to problem solving.
72.1 was asked whether I consider that the Horizon system was fit for purpose
at the point at which it was rolled out. Given the rigorous process around
release management and acceptance I had no reason to believe that
Horizon was anything but fit for purpose at the time of roll out. I hope I am a
realist. I wouldn’t have regarded fit for purpose meaning that the system
would not in operation prove to have bugs that would require fixing. All the
systems I’ve experienced are in a constant state of bug fixing. Testing and
the other feeds into Acceptance will have demonstrated the business
processes could continue as designed.
Page 23 of 26
WITN05290100
WITN05290100
73.1 was asked whether there were any other matters that I consider would
assist the chair. There is a National Audit Office report “The Cancellation of
the Benefits Payments Card project” which gives an independent view of the
procurement and management of the project through to the cancellation of
the Benefits Payments card. This was discussed at a parliamentary
committee and the minutes of such may provide further insight.
Statement of Truth
I believe the content of this statement to be true
Signed;
GRO I
Dated: 30/08/2022
Index to First Witness Statement of David Smith
Exhibit Number
Document
Description
Control
Number
URN
Ia
WITNO529_ 01/1
Paul Rich’s letter IT
concurrence Meeting
Dated 9" Feb
Flash Report —
Urgent!!
POL00031276
In
WITNO529_01/2
Paul Rich’s letter IT
concurrence Meeting
Dated 9'" Feb
Interfaces between
POCL systems
POL00031277
foo
WITNO529_ 01/3
Letter Basil Shall to
Paul Rich ‘Flash
POL00031278
Page 24 of 26
WITN05290100
WITN05290100
Exhibit Number
Document
Description
Control
Number
URN
Report- Urgent!!-
Supplier
Requirements
Sy
WITNO529_01/4
Automation
Transformation
Programme Steering
Group Meeting
Minutes, 23 June
1998
POL-0024806
POL00028324
In
WITNO529_ 01/5
Automation
Transformation
Programme Steering
Group Meeting
Minutes, 20 October
1998
POL-0024803
POL00028321
Ia
WITNO529_01/6
Automation
Transformation
Programme Steering
Group Meeting
Minutes, 28
September 1998
POL-0024804
POL00028322
IN
WITNO529_01/7
Transformation
Steering Group
Progress Report to
28 September 1998
POL-0024805
POL00028323
loo
WITNO529_01/8
Review of the
POCLI/ICL Pathway
Deal by Roger
Tabor, Finance
Director POCL
(January 1999)
POL-0028132
POL00031230
ko
WITN0529_ 01/9
Horizon/Pathway
Delivery Meeting:
Special Meeting
Notes, 14 Jan 2000,
sent by Dick
Brazear, Head of
Programme Office
for Post Office
Network to POCL
and ICL employees
POL-0024991
POL00028509
WITNO0529_01/10
Review of Horizon
Performance and
Problem
POL-0024922
POL00028440
Page 25 of 26
WITN05290100
WITN05290100
Exhibit Number
Document
Description
Control
Number
Management
Reporting, Post
Office Network
(internal Audit), Nov-
Dec 1999
WITNO529_ 04/44
Circulation: National
Executive Council,
NFSP, enclosing: i)
letter from David
Smith to Colin Baker,
31 Jan 2000; ii) PO
Consulting
“Christmas Horizon
Research Report",
Jan 2000, by Lorna
Green
NFSP00000261
Page 26 of 26