Official hearing page

2 November 2022 – Stuart Sweetman and Jeremy Folkes

Hide video Show video

(10.00 am)

Mr Stuart Sweetman

MR STUART SWEETMAN (continued).

Further Questioned by Mr Stevens

Mr Stevens: Good morning, sir, can you see and hear me?

Sir Wyn Williams: I can certainly hear you and no doubt I will see you in a moment.

Mr Stevens: Mr Sweetman, can you see and hear me?

Mr Stuart Sweetman: I can hear you but not see you. I can see the Chairman.

Mr Stevens: I wonder if that may be fixed. If you bear with us a moment.

(Pause)

Mr Stevens: Sir, I’m told five minutes will be required to address that so you can see me.

Sir Wyn Williams: All right. Then we will just break off. I will come back visibly in five minutes, all right?

Mr Stevens: Thank you, sir.

(The Inquiry was paused for technical reasons)

Mr Stevens: Sir, can you see and hear me?

Sir Wyn Williams: Yes, I can and I can see Mr Sweetman and I guess he can see me?

Mr Stuart Sweetman: I can see the Chairman and I can see you, sir, yes. I can see both of you.

Mr Stevens: Excellent.

Well, Mr Sweetman, you were giving evidence yesterday and you are going to continue to give that now. I will pick up where we left off. We were discussing, towards the end of the day, Acceptance Incidents and the workshops that went into it and you were briefed on the progress of those acceptance workshops as they were progressing; is that correct?

Mr Stuart Sweetman: Probably, I think the record shows that. I don’t recall that.

Mr Stevens: We were yesterday discussing one of the Acceptance Incidents, which is number 376, concerning data integrity and discrepancies in the cash account, yes?

Mr Stuart Sweetman: Yes, we were.

Mr Stevens: Now, eventually, in the second supplemental agreement, Post Office and ICL Pathway agreed in respect of that incident that between 3 October 1999 and 14 January 2000, the percentage of cash accounts received across the TIP interface, with discrepancies, should not exceed 0.6 per cent. Do you recall that?

Mr Stuart Sweetman: I don’t.

Mr Stevens: Yesterday, we discussed that you looked at the bigger picture when considering whether an error rate was material.

Mr Stuart Sweetman: Yes.

Mr Stevens: Did you listen to the evidence of Mr Copping earlier this week?

Mr Stuart Sweetman: I haven’t.

Mr Stevens: This was put to him, this agreed rate of 0.6 per cent for the rate of discrepancies, and it was put to him that when applied across the entire Post Office network, that would amount to 100 cash account discrepancies in any week, which he considered to be quite a significant error rate. Would you agree with that?

Mr Stuart Sweetman: I suppose I would have to compare it with the pre-Horizon error rate that arose within the cash accounting system, the old manual system because there were – I don’t know the number. But there were lots of errors coming out of offices which had to be corrected and there was a team of people in Chesterfield who picked up those errors, analysed them and did what was, therefore, necessary to correct the records. That sometimes was adjustments within head office, sometimes it was going back to the office and saying, “Can you do this on the next cash accounts and that will bring it back into balance?”

I think there were dozens of people in Chesterfield doing that correction process and they would have the capability of handling that level of errors because it was common practice. So, that being in place would have given me personal comfort that that low level of error rate that we had defined in that agreement you quoted was handleable and I think that’s what I would have assessed the issue as.

Mr Stevens: So, before moving on, again on this point of materiality, I think what you are saying is, from your perspective, this error rate passed the materiality threshold which you were applying and you would be happy with that level of errors, yes?

Mr Stuart Sweetman: You are never happy with any errors but if you can handle them, that it doesn’t undermine the completeness – the truth and fairness of the record keeping, then, from my perspective as a director, I would be happy that we are running an accounting system under control because we can pick up the errors, we can correct them and move forward.

I was looking at it from an organisational basis, not a subpostmaster basis.

Mr Stevens: Yes. You said yesterday that the perspective from a subpostmaster within – who is affected by one of these errors would be different. Was anyone within Post Office Counters representing the interests of subpostmasters at this stage?

Mr Stuart Sweetman: Well, the whole management structure. From what I have read and I think I remember, we had an organisational structure where maybe 50 post offices were looked after by a retail network manager and during this implementation phase we had specific managers with that sort of line experience looking – holding the hands of and looking after the subpostmasters who were going through the implementation. They would have been there, on the spot, seeing what was coming back and what was causing errors in the local office and helping the subpostmaster respond.

Mr Stevens: I think we are talking at cross-purposes?

Mr Stuart Sweetman: Are we? Sorry.

Mr Stevens: I’m discussing the considerations that were taken into account for whether this 0.6 per cent figure was material and in your evidence yesterday you compared the different perspectives. On the one hand, from your perspective, looking at it from Post Office Counters as a whole and then on the other hand from an individual subpostmaster who would be affected by an error.

Now, when considering this level of errors, I say in that context, was anyone at Post Office Counters representing or considering the interests of the individual subpostmasters in respect of that error rate?

Mr Stuart Sweetman: The honest answer is I can’t remember. But I suppose that was down to all of us. But no one specific had that hat on to say “In this meeting I’m representing the subpostmaster”. I don’t think that was in place but I really do not remember, sorry.

Mr Stevens: I think you may have answered this already but just so the question is put to you, are you aware of anyone seeking the views of subpostmasters on that issue?

Mr Stuart Sweetman: We had lots of feedback routes from subpostmasters. At national level: the general secretary, the president. At regional level there would be feedback mechanisms and there would be mechanisms down in subpostmasters and in the regions. So there would have been various lines of communication. What those specifically were about this error type, I don’t recall, sorry.

Mr Stevens: I want to jump now to January 2000. Please can I turn up POL00000336.

This is a meeting on the Post Office board held on 11 January 2000 in which you attended. Please can we turn to page 11.

Can we go further down, please. Sorry, slightly further up. Actually, I’m so sorry, if we start on the page before that at the bottom.

Sorry for the delay there, Mr Sweetman.

Mr Stuart Sweetman: That’s okay.

Mr Stevens: This concerns an update on the Horizon programme and it refers to the rollout of Horizon being due to recommence and that a great deal of work had been undertaken to rectify difficulties identified in three areas:

“Systems stability;

“Accounting integrity and;

“The provision of support to officers

“Although as yet uncertain, it was anticipated that these issues would not prevent rollout recommencing.”

Go over to the next page slightly please.

“Given that the programme was expected to recommence rollout, it would be helpful for the Board to understand what marketing opportunities were now being considered.”

Mr Stuart Sweetman: Yes.

Mr Stevens: I understand you don’t have any recollection of this meeting?

Mr Stuart Sweetman: Not that specific meeting no but I can read the words and I can interpret them.

Mr Stevens: So at this stage, were the board asking you any directive questions about the accounting integrity issue which we have been discussing?

Mr Stuart Sweetman: The minutes record – so this board meeting would have been earlier in the month prior to the recommencement of the rollout and the board would have had a report, which I’m not sure if I have seen, which says “We are working on these issues and if those issues are satisfactorily resolved we will recommence rollout”.

I don’t recall whether – how far I was pushed on that or asked about it – but they could well have asked, but I don’t know.

Mr Stevens: Please could we turn to FUJ00118186. This is the third supplemental agreement between Pathway and Post Office Counters dated 19 January 2000, just over a week after that board meeting. So presumably this was being discussed around that time of that board meeting we were discussing?

Mr Stuart Sweetman: Yes, it must have been.

Mr Stevens: Can we go to page 2, please, and to (d), thank you.

It says:

“By clause 6.1.1 of the Second Supplemental Agreement, POCL has a right to postpone the resumption of rollout from January 2000 if any of the criteria in parts a to c of Schedule 4 to the Second Supplemental Agreement shall not have been met by 24 November 1999.”

(e):

“Both POCL and the Contractor acknowledge that at least one of those criteria were not met and accordingly that the right contained in clause 6.1.1 became exercisable.”

Then please can we turn to page 5, paragraph 5.3. We’re back to the data integrity issue and it says that:

“The Contractor shall from the date of this agreement until the end of the TIP integrity Checking Period make available to POCL promptly upon request appropriate experts to explain to POCL the Contractor’s analysis of all root causes of Cash Account Discrepancies and the measures which the Contractor shall have implemented in order to prevent the recurrence of any Cash Account Discrepancies which would not have been detected by the Accounting Integrity Control Release.”

Do you accept at this stage cash account discrepancies remained an ongoing problem?

Mr Stuart Sweetman: I think that’s evidence that they were.

Mr Stevens: By this clause it was envisaged that the reconciliation processes that were supposed to identify cash account discrepancies may fail to do so?

Mr Stuart Sweetman: I could read that into those words. They are quite technical words. The end bit, which says “which would not have been detected by accounting integrity control”, does imply that, yes.

Mr Stevens: Would you have raised these concerns with the Post Office board at the time?

Mr Stuart Sweetman: Not at this level of detail, I would not have thought. Apart from the generalities which were noted by the board, that the errors were still being worked on and improvements sought. So, in general terms, I think what the board minutes record is us saying “There are still issues that we are managing”. This is a level of detail that we would not have, in those words, taken to the board.

Mr Stevens: Let’s move to the March board meeting. That’s POL00021469. The 14 March 2000 board minutes, again at which you attended. Please could you turn to page 7 of this.

If we could move down, sorry. Thank you. This is described as “Commercial Development of the Horizon Platform in Post Office Network”. It refers to, firstly, the rollout and then it moves on to discuss the other commercial uses of the Horizon platform?

Mr Stuart Sweetman: Yes.

Mr Stevens: At this stage, this is following the third supplemental agreement. Did you discuss with the board in any detail the ongoing issues with data integrity?

Mr Stuart Sweetman: I don’t know but, looking at the record here, the focus was on the future, not the current, because the rollout had been accelerating and we had learned all the lessons of the early offices and had put those in place and the rollout was now going at a rate that we had originally planned and so the board would have taken comfort from that but I can’t see any evidence that we brought to them anything else.

Mr Stevens: Do you recall whether either John Roberts or anyone on the board asked you any questions about that issue at the time?

Mr Stuart Sweetman: No, I don’t.

Mr Stevens: Thank you, sir. That concludes my questions. But we have some questions from recognised legal representatives.

Sir Wyn Williams: All right. Well, my understanding from last night was that Mr Henry and either Mr Stein or Mr Jacob had comparatively few questions. Is that still the position? If so, then they can go first and then Hudgells can mop up, so to speak.

Mr Stevens: My understanding is no questions from Howe+Co.

Mr Jacobs: That’s correct, yes.

Mr Henry: Sir, no questions on behalf of Hodge Jones & Allen either.

Sir Wyn Williams: All right then, straight over to – is it Ms Patrick or Mr Maloney who is going to ask the questions?

Ms Patrick: Sir, it is me, Ms Patrick.

Sir Wyn Williams: Fine.

Questioned by Ms Patrick

Ms Patrick: Good morning, Mr Sweetman, can you hear me?

Mr Stuart Sweetman: Good morning, Mr Patrick. Yes, I can.

Ms Patrick: And can you see me?

Mr Stuart Sweetman: I can.

Ms Patrick: Thank you. We only have a very few questions and it is on two topics. The first question we have is about one document and it is at POL00031230.

Is that now on the screen for you?

Mr Stuart Sweetman: Yes, it is.

Ms Patrick: This was an internal review within POCL, commissioned from the POCL finance director in January 1999 and, at that time, you were the head of the POCL management team, weren’t you?

Mr Stuart Sweetman: Yes, I was.

Ms Patrick: It is not marked as to who received the document but, as the MD, would it have been provided to you?

Mr Stuart Sweetman: Yes, it would have been.

Ms Patrick: Thank you. If we can go to page 2, and we are looking at 2.4, please, which is the second paragraph from the top. I will read it out, so that we have all got the same understanding:

“The conclusion of negotiations with a firm decision to proceed should put an end to a protracted period of uncertainty, permitting a fresh start with renewed focus not only for the Horizon project but for the POCL business.”

It is this next part I want to look at particularly:

“Unfortunately, many uncertainties, unanswered questions and doubts about the future remain, so that the benefits of such a fresh start seem unlikely to be obtained without a concerted, focused and single minded leadership effort by both POCL and ICL teams to emphasise the positive.”

If we can skip down a little to paragraph 2.6. I think you can see that there on the screen Mr Sweetman? Can you see paragraph 2.6?

Mr Stuart Sweetman: Yes, I can.

Ms Patrick: That starts:

“Several senior managers, close to the project, but not principal negotiators, whose judgement I respect, express significant reservations about the risks of proceeding. These centre on their continuing doubt about the ability of ICL to deliver a satisfactory product; the absence of transparency in the PFI contract; the risk that ICL’s financial fragility will endure throughout the project, with the possibility of repeated claims on The Post Office for extra contributions (which, by then having no alternative, it will be unable to resist); and doubts about POCL’s own ability to give it the focus essential for success. Observation of the track record so far offers reasonable foundation for such views.”

If we could skip over to page 6 of this document, now I also want to look at paragraph 2.24, which is a little bit further down on that document as you can see it now.

This is the summary of his findings:

“In summary, there are drawbacks and uncertainties with going ahead, but they are not greater than those associated with termination. Going ahead will require very heavy, single minded commitment to Horizon and to the partnership with ICL in order to minimise the drawbacks.”

If we skip to the very next paragraph, 3.1, which I think you can see. It goes on with his recommendations:

“The high-profile of the Horizon renegotiation, and The Post Office’s support of Horizon against significant opposition mean that failure to make the deal stick with a successful implementation would be politically and commercially extremely damaging.”

This part is in bold:

“It is of great importance for the credibility of The Post Office (not just POCL) that it should be seen to have judged the debate correctly and made the right decision.”

If we skip further down to 3.2, which goes over the page, his recommendations continue:

“Furthermore, POCL’s commercial success will now depend heavily on Horizon. It will not have the funds for alternatives. Horizon must therefore be implemented in a way that which ensures achievement of service and commercial goals, for customers and clients. To be sure of this, the approach to developing the business vision will need to be adapted to become visibly Horizon-centric. People’s enthusiasm for finding workarounds and alternative approaches will need to be firmly channelled into making Horizon deliver what is required. It is likely that this Horizon-centricity will need to apply beyond the bounds of the current POCL business. Shaping for Competitive Success will need to ensure that organisation boundaries facilitate effective operation of Horizon and the ICL partnership, and not make it gratuitously more difficult.”

Now that we have read that and we have all got the same understanding, yesterday I think you said POCL had to be sustainable in the post-ACT world and I think you agree that to do that, first, Horizon had to work; is that right?

Mr Stuart Sweetman: Correct.

Ms Patrick: I think you said yesterday Ian McCartney may have told you, or something like, “I’m going to make sure everyone knows in the Post Office that this has got to work”; is that correct?

Mr Stuart Sweetman: Yes, yes.

Ms Patrick: So POCL would have had external pressure to adapt to become visibly Horizon-centric; is that fair?

Mr Stuart Sweetman: But we wanted – yes, we wanted to be Horizon-centric, that was our strategy.

Ms Patrick: And what I’m saying is you wanted that –

Mr Stuart Sweetman: Yes.

Ms Patrick: – but there was also external pressure to achieve that approach?

Mr Stuart Sweetman: Isn’t it an iterative process? We wanted Horizon because what it would equip the company to do in the marketplace and we went out and sold the idea to the politicians and the senior management and the board that if we had this computerised network – modern network, we could do these things, we could actually sustain our commercial future. So we were broadcasting “That’s what we want” and that bounced back to us saying, “Yes, okay, you get on with it but make sure you deliver on the targets”, and that’s the management process. So I don’t think they were over-the-top pressures, I think that people were playing their roles. Politicians were making big decisions and they had very difficult decisions to make, the board were taking those on board, the chairman and chief executive had that obligation to deliver to the political needs, the shareholders’ needs. That then got disseminated down to the businesses and we all responded.

This particular report, I think, was by Roger Tabor, who was the then finance director of Post Office network or Post Office Limited and he was a very professional, analytical individual and I think he would have been asked to produce this report to make sure, as a team, we had everything – do we have all this in place? Do we have our own confidence that we have this in place to deliver? And this is an internal document which says “Are we fit for purpose”? And he was telling us, “All these things need to be in place if you are going to deliver what the business plans are”.

Ms Patrick: Mr Sweetman, thank you. So it was becoming visibly Horizon-centric, the message which you and you staff and your board, your team, adopted from then on?

Mr Stuart Sweetman: It wasn’t from then on. Running up to it – I think Roger, in this report, was saying, “You have got to continue it. Don’t back off from this core strategy that you are following of equipping the network of postmasters with a modern computer system. You can’t back off of it because there isn’t a plan B”.

Ms Patrick: Thank you. Sir, I’m going to move onto the second topic that we wanted to ask about. You said yesterday, in detailed discussions, the board would have expressed concerns about outstanding technical issues. I want to look at two later board meeting minutes and the first is a meeting minute from May 2001, which is RMG00000009. We have got it on screen and I think what I would like to do is – On the first page we can see that you were present and if we can scroll down to page 5, the part that I want to deal with is on page 5. That was the 1 May 2001.

Can you see that document, Mr Sweetman?

Mr Stuart Sweetman: Yes, I can.

Ms Patrick: We can see at the top there, there is a heading “error reconciliation and accounting” and I think a paper number and “Horizon beyond 2005” and again a paper number. I’m going to read underneath so we are all looking at the same document:

“The Board considered the two papers from Stuart Sweetman, and the accompanying presentation by David Smith, which gave an illustration of the fundamental nature of the change to the operating process that would be delivered by the Error Reconciliation and Accounting Project (ERA). ERA needed to be viewed in conjunction with options for the future of Horizon beyond 2005 which included inter alia an approach to securing internal funding for ERA.”

It goes on to say things that the board noted in relation to that project, or that plan and if we could scroll down to (d). I think you can see that, Mr Sweetman?

Mr Stuart Sweetman: Yes, I can.

Ms Patrick: “Success of the ERA project would depend on client cooperation in redesigning their own forms and procedures. Most current clients were keen to be involved, especially now that they were able to see Horizon as a working reality.”

If we could scroll down to (e). I think we are going to have to go further. If I could bring you up to the top of the page that would be helpful. It goes on:

“the success of the Horizon installation programme had helped increase confidence in ICL as a supplier. However they were not necessarily the best future supplier, but the recommendation was to continue with them as the potential disruption to the PO network from starting a new procurement process to source a new supplier now would be considerable, and require a rewriting of the strategic plan. However it was recognised from a negotiating point of view it was highly risky to give ICL a commitment for the future, and more thought should be given to our negotiating stance …”

It goes on a little to say some more about:

“It should not be assumed automatically that ICL’s funding of the investment was the only option. It may be preferrable … to seek external funds …”

If we could go over the page please it goes on to talk about what the executive board agreed and it says:

“while, inevitably, there were a large number of unresolved issues about ERA and Horizon, their general direction was right and the respective strategies should be worked up further in the light of this discussion, and would be taken to the July Consignia Board as a strategic issue.”

That last point, what did you understand to be the large number of unresolved issues about ERA and Horizon?

Mr Stuart Sweetman: I don’t recall a lot of detail to be honest. What I have read there, in my earlier evidence I said that there was a group of people in Chesterfield whose job it was to pick up errors and then chase them down until they have been corrected, either in the centre or in the cash accounting system of subpostmasters. And that was a very big and expensive operation because it was there and, in a perfect world where systems are working absolutely perfectly, it is a wasted cost, a big lump of – a big group of people correcting errors.

If errors aren’t created, you don’t need those people. And I think ERA was about smartening up that whole process of picking up and correcting errors.

That would need to take input from Horizon but would be a sort of central accounting reconciliation system. I’m sort of thinking through what this would have been. And, clearly, how you link that central reconciliation process to the detail of Horizon in local offices would take some designing and some development and that is what I think this refers to. But I can’t absolutely remember. This is me putting words –

Ms Patrick: Mr Sweetman, I may be able to assist you. In the interests of speed, there is a part of that minute that I did not read and I am sure you can see it at the top of the page there:

“ERA would cause at least 400 job reductions in Chesterfield, and a plan for managing these – and the associated negative PR, would be needed.”

What you have said about error corrections happening at Chesterfield and that team being there, does that note there help your memory?

Mr Stuart Sweetman: I hadn’t remembered it was of the order of 400 but, certainly, to keep on top of the error rates and correcting them to make sure we were keeping proper books of account, we had invested heavily in this correction process. Now, if we could develop a system which did that electronically, computer to computer, we would then, you know, coldly, be able to save the cost of 400 jobs.

Now, I think there were 2,000 or 3,000 people employed in Chesterfield. We were the major employer in Chesterfield and we would have to handle that not only negative PR but, from an industrial relations point of view, that would all be very sensitive issues to manage.

Ms Patrick: Thank you, Mr Sweetman. So this may be a project, from your recall, that would be looking at adjusting how errors are handled once they are being managed. Looking at the record, there is no record here of the board asking for any further information or any update on what the management of reconciliation or balancing errors, which were happening in Horizon, looked like, is there?

Mr Stuart Sweetman: There isn’t.

Ms Patrick: It says of course, we have gone to that note:

“… inevitably, there were a large number of unresolved issues about ERA and Horizon …”

But there is no note here or record of the board asking for any further information on what those inevitable and seemingly unresolved issues were or were likely to be, is there?

Mr Stuart Sweetman: No, there isn’t.

Ms Patrick: In hindsight, was the board here being invited to approve a commercial project –

Mr Stuart Sweetman: No.

Ms Patrick: – without sufficient information about underlying issues which might relate to their decision?

Mr Stuart Sweetman: No, they weren’t authorising it, no. If you page back up, it will give the context to which all this was being discussed, I think.

Ms Patrick: I think if we go back to the page we were on, I may be able to assist, Mr Sweetman. If we go back to point (e) and down and over the page, you will see there the board was saying their general direction was right and the respective strategies should be worked up further –

Mr Stuart Sweetman: Yes, I think what – to understand the management process within the Post Office, I was bringing this to my colleagues on the executive board as, “In our plan, we are thinking of – we need to spend this sort of money on doing this sort of thing. Can we have support for that direction?” This is what this discussion was about. “Is it the right direction to go?” They were not all – they were saying “Yes, go away and work out the detail and come back with a project to be authorised”, and then that would have been authorised by the Major Projects Committee and, if it was big enough, by the board. This was a nod through, “This is the right way to go, go ahead and develop a project”.

Ms Patrick: A nod through but at no point, or no record there, no record there of them asking about an update on reconciliation, or balancing errors, or for any further information on what the inevitable and unresolved issues were likely to be at that point.

Mr Stuart Sweetman: No, there was no record there and it doesn’t surprise me that there was no record because that was not the purpose of the discussion. It might well have come out of the discussion but it was not the purpose of this discussion.

Ms Patrick: Thank you. I’m going to move on to the last document that we want to look at, Mr Sweetman, and it is POL00021476. I think we can see you on the first page there and you are in attendance. The date is 12 June 2001, so the following month, and we can see there you are now, by this point, group managing director, customer and banking services?

Mr Stuart Sweetman: Correct.

Ms Patrick: Is that a change in role for you?

Mr Stuart Sweetman: Yes. We went through a reorganisation and, in that role, I had the managing director of the Post Office Network reporting to me, so that individual would have looked after, effectively, the operations of the old Post Office Counters network, but I also had strategic directors developing the banking services and also customer services down in Swindon which ran the BBC licensing system.

Ms Patrick: So if we can look over to page 4 and there is only one point that’s relevant to the Inquiry on that page. You will see, a third of the way down, this is in the chief executive’s report which is made clear on the page before. It reads:

“Horizon: the Board also expressed its congratulations and thanks to the team working on the Horizon programme, on the successful completion of the installation of over 40,000 machines and training of over 60,000 people in Post Office Network.”

Mr Stuart Sweetman: Yes.

Ms Patrick: The thanks are minuted. There is no recollection – or do you have any recollection of any update then on any impact across the network of the installation, or any record of any request or any update as to the impact of any training as part of that process?

Mr Stuart Sweetman: No, I don’t recall that sort of discussion.

Ms Patrick: There is no record there or any update on whether there were, at that time, any recorded problems arising from subpostmasters.

Mr Stuart Sweetman: No, there isn’t.

Ms Patrick: And there is no record of any discussion here, is there, it’s only a note of congratulations?

Mr Stuart Sweetman: Correct.

Ms Patrick: Would it be consistent with your recall that, after the resumption of the rollout in January 2000, the board and the board meetings focused only on the commercial opportunities for Horizon and the successes of Horizon?

Mr Stuart Sweetman: I think that’s – whether it was only, I don’t recall, but, principally, the focus was on the future and developing profitable services to operate through our network.

Ms Patrick: Thank you, Mr Sweetman. We have no further questions for you.

Mr Stuart Sweetman: Thank you.

Mr Whittam: Sir, Richard Whittam, we indicated yesterday we had very one short point for clarification.

Sir Wyn Williams: Fine.

Questioned by Mr Whittam

Mr Whittam: Mr Sweetman, my name is Richard Whittam and we represent Fujitsu. I want to take you back, please, to late August/early September 1999 and it was the Ernst & Young letter we looked at yesterday. I will ask that to come up. POL00090839. On that page, you told us yesterday, Jeff Triggs was the very clever lawyer at Slaughter and May.

Mr Stuart Sweetman: Yes.

Mr Whittam: Can you recall now what role Keith Baines had at that time in Post Office Counters Limited?

Mr Stuart Sweetman: Well, it says there “Horizon Commercial”. I wouldn’t like to produce a job description now, I really don’t remember but he was an individual who was good at handling detail and would have ensured that what we agreed with Pathway was reflected in agreements, were properly priced, and that sort of thing. But I really have not a very clear view of that.

Mr Whittam: Don’t worry, I appreciate I’m asking you about a single document 23 years ago. But if we could go to the next page, please, just so you can recall its context. The very first paragraph, it is obviously a letter that had been requested by Post Office Counters Limited?

Mr Stuart Sweetman: Yes, that is right.

Mr Whittam: You will recall that David Miller had suggested you might have been the person who requested it and you said you weren’t surprised, it could have been you, you couldn’t recall at this remove of time. But you did remember –

Mr Stuart Sweetman: I don’t recall specifically requesting it, but it was the sort of thing I might have suggested to him would have been useful in our discussions with Pathway.

Mr Whittam: You described the discussions at this time as the very hard-nosed discussions with Pathway and this would be useful to give you a bit of clout?

Mr Stuart Sweetman: I think that’s fair, yes. And I think that’s totally reasonable.

Mr Whittam: So this letter, could it be summarised, was requested as a tool to be used by Post Office Counters Limited in its negotiations with ICL?

Mr Stuart Sweetman: Not solely as a tool because we wanted to keep the auditors on side. They needed to be able to design their audit processes, et cetera, and it was important for them to understand the details of the system and it was a way of bringing them in as well.

I would say giving us a bit of clout was one of the objectives but not necessarily the sole objective because we wanted to know their professional view, because that gave assurance to what we were trying to do on our internal agenda.

Mr Whittam: Mr Sweetman, thank you very much.

Sir, that’s all that I ask.

Sir Wyn Williams: Thank you. I think that now concludes your evidence, Mr Sweetman.

Mr Stuart Sweetman: Thank you.

Sir Wyn Williams: I would like to thank you for making your written statement and for devoting the time to give oral evidence to us.

Mr Stuart Sweetman: Would I be permitted to read a final statement that I have written into the record?

Sir Wyn Williams: Yes. I had forgotten you mentioned that yesterday, but please do.

Mr Stuart Sweetman: Okay, thank you.

I have learned from the media and my involvement in this Inquiry of the devastating impact that flawed prosecutions have had on the lives of subpostmasters and their families. They all have my sincere sympathy. These are easy words for me to say but I really do mean them.

I am sure that this Inquiry will identify numerous contributing factors of commission and omission that led to what happened. My detailed memory of events of 20 to 25 years ago is poor but it has been stimulated by the documents you have questioned me about. I hope it has been shown that throughout my involvement with Horizon, I was, at all times, acting to ensure the long-term viability and sustainability of Post Office Counters and its network of Post Offices. If Horizon had failed, the many thousands of postmasters and Crown Office staff would have lost their livelihoods and communities throughout the country would have been deprived of access to important services that the network provided.

I believe I led Post Office Counters by balancing the needs of our stakeholders, our public customers, our paying clients, our employees, our subpostmasters and our shareholder. I was personally driven by the concept of continuous improvement with an equality management framework we call “Customer First”. My personal integrity has its origins in training and practising as a chartered accountant. I believe that I adhered to those principles throughout the events being investigated.

I believe I had well-founded confidence in the people and teams that reported and supported me in my role. When I used to go into my local Post Office, it was with a sense of pride to see the Horizon terminals being used. That pride has now been tarnished by the revelations that this Inquiry is investigating. For the record, I don’t believe I have had any personal involvement in the prosecution decisions that this Inquiry is investigating. I’m appalled by what has been revealed about them.

Thank you.

Sir Wyn Williams: Thank you, Mr Sweetman.

Mr Stevens: Thank you, sir.

If we may take a short break while we change witnesses here.

Sir Wyn Williams: Yes, of course. Five minutes or do you want longer?

Mr Stevens: I think 10, sir, that would be appreciated.

Sir Wyn Williams: All right a 10-minute break then.

Mr Stevens: Thank you, sir.

(10.55 am)

(A short break)

(11.03 am)

Mr Beer: I call Jeremy Folkes, please.

Mr Jeremy Folkes

MR JEREMY PETER FOLKES (sworn).

Questioned by Mr Beer

Mr Beer: Please take a seat, Mr Folkes. As you know my name is Jason Beer and I ask questions on behalf of the Inquiry. Can you tell us your full name please?

Mr Jeremy Folkes: Jeremy Peter Folkes.

Mr Beer: Thank you very much for giving evidence to the Inquiry and thank you very much for the very detailed statement that you previously provided to the Inquiry. We are very grateful to you for the assistance that you have given and which you will give today.

You should have in front of you a hard copy of your witness statement which, excluding the index to the exhibits to it, is 70 pages in length and is dated 7 September 2022. Is that in front of you?

Mr Jeremy Folkes: Yes.

Mr Beer: Could you turn to page 70 please, the last page. Is that your signature?

Mr Jeremy Folkes: It is.

Mr Beer: Are the contents of the statement true to the best of your knowledge and belief?

Mr Jeremy Folkes: There is one very minor correction on page 39.

Mr Beer: I wonder whether we can go to that. That is WITN05970100 at page 39.

Mr Jeremy Folkes: It is paragraph 114.

Mr Beer: So page 39.

Mr Jeremy Folkes: It is just – it says there that Bird & Bird were POCL’s legal firm. In re-reading documentation, I realise they were the programme – the PDA’s legal firm, rather than being POCL’s.

Mr Beer: Thank you very much. With that correction are the contents of the statement true to the best of your knowledge and belief?

Mr Jeremy Folkes: They are.

Mr Beer: Thank you very much. A copy of that statement will be uploaded to the Inquiry’s website. I’m not going to ask you questions about every aspect of it, just related parts of it, do you understand?

Your background and experience, please. I think you were employed by the Post Office between 1987 and early February 2000; is that right?

Mr Jeremy Folkes: That is correct yes.

Mr Beer: Working primarily in projects for Post Office Counters Limited?

Mr Jeremy Folkes: Yes. I was working, actually employed by the Post Office IT department but almost everything I did was for POCL projects.

Mr Beer: So far as concerns this Inquiry, your most relevant work, is this right, was on the Horizon project or Horizon programme as it became known, from 1994 until early February 2000?

Mr Jeremy Folkes: Yes.

Mr Beer: In terms of your qualifications and career before Horizon and indeed after it, I think you qualified with a degree in mathematics, is that right?

Mr Jeremy Folkes: Yes.

Mr Beer: On graduation you worked for British Gas, then Logica, which I think was a IT and management consultancy firm?

Mr Jeremy Folkes: To be pedantic, I actually worked for British Gas before going to university, I had a gap year, and during my time at university. I did work in IT during that time.

Mr Beer: Then after graduation to Logica is that right?

Mr Jeremy Folkes: Yes.

Mr Beer: Am I right; it was an IT and management consultancy firm?

Mr Jeremy Folkes: It was but my work was on IT projects.

Mr Beer: And you worked on software projects, always holding a technical role; is that right?

Mr Jeremy Folkes: Yes.

Mr Beer: Whether as a developer, a designer or a team leader?

Mr Jeremy Folkes: Yes.

Mr Beer: You joined, as I have said, the Post Office in 1987. Left in 2000 and you went to work for a company that was later acquired by the Escher group is that right?

Mr Jeremy Folkes: Yes.

Mr Beer: You worked with the Escher group for about 21 years rising to chief technical officer, CTO, until your retirement last year, 2021?

Mr Jeremy Folkes: In the last couple of years I actually moved into a consultancy role and did actually work part-time during that – so I think my job title technically was principal consultant in the last couple of years.

Mr Beer: Thank you. When you joined the Post Office in 1987 I think your employer was the Post Office, a statutory corporation; is that right?

Mr Jeremy Folkes: Yes.

Mr Beer: And you worked in the IT department of the Post Office; is that right?

Mr Jeremy Folkes: Yes.

Mr Beer: Did you have normal line management reporting structures within the IT department?

Mr Jeremy Folkes: Yes.

Mr Beer: You tell us in your statement, no need to turn it up, it is in paragraph 1, that in 1994, so that’s about 7 years after you joined, you were “effectively seconded to Post Office Counters Limited”; is that right?

Mr Jeremy Folkes: Yes.

Mr Beer: What did that secondment mean in terms of your employment status?

Mr Jeremy Folkes: To my formal status, none whatsoever. I was basically working on a POCL project but I was still, from a pay and rations point of view, employed by Post Office IT.

Mr Beer: Was your line manager in the IT department or was it – he or she within Post Office Counters Limited?

Mr Jeremy Folkes: I had a line manager within Post Office IT but I had very little contact with them to be honest. I was effectively a free operating member of the POCL team.

Mr Beer: But why were people brought from – it may seem an obvious question – the Post Office’s IT department into the POCL Horizon programme?

Mr Jeremy Folkes: The way Post Office was structured at that point is the individual businesses didn’t have IT functions, there was a central IT function. There were many projects done for the various business units by Post Office IT. Because this was a project obviously with a major IT part of it, they did want to bring in people from Post Office IT.

Mr Beer: Without that bringing in, did POCL have the relevant IT experience?

Mr Jeremy Folkes: No I do not think they would have done.

Mr Beer: What, if any, technical expertise was there at POCL management level?

Mr Jeremy Folkes: There was a Post Office Counters – I think it was called an IS strategy information, so information systems rather than IT, looking at the overall strategy. I can’t honestly remember what other functions there were.

There may have been functions relating to individual projects that were up and running as far as day to day management of those functions within POCL but work on new projects would always have been put out to Post Office IT.

Mr Beer: Would you know whether at this time, 1994 to 2000, there was any technical expertise at the POCL board level?

Mr Jeremy Folkes: I would not know.

Mr Beer: Can I turn to the stages of the Horizon programme in which you were involved. So you joined, I think, after the procurement process had been launched in August 1994, the initial very large list of service providers had been cut down to five?

Mr Jeremy Folkes: Yes.

Mr Beer: At that stage, the five were BT, CardLink, EDS, IBM and Pathway?

Mr Jeremy Folkes: Yes.

Mr Beer: At the time you joined, the statement of service requirements had already been issued to the five suppliers that I have just mentioned?

Mr Jeremy Folkes: Yes, I think so.

Mr Beer: That was back on 13 April 1995 so pre your joining – no, that’s post your joining, isn’t it?

Mr Jeremy Folkes: I can’t remember exactly what date I joined the programme.

Mr Beer: Okay. Can I break down your role over the succeeding six years or so into five parts. These are my descriptions of it. Please agree or disagree with them but it is just to give some structure to your evidence.

It is not how matters are arranged in your witness statement. Would it be right that your first role was the evaluation of the five responses, of the five bidders that I have just mentioned, and that resulting in the list being cut to three with BT and the EDS being eliminated?

Mr Jeremy Folkes: Correct.

Mr Beer: Your second role was within the so-called “demonstrator stage”; is that right?

Mr Jeremy Folkes: Yes.

Mr Beer: Just explain to us, because it is an odd word “demonstrator stage”, what the demonstrator stage was?

Mr Jeremy Folkes: It was a slightly odd phrase for us as well I think. The intention of the demonstrator was to give the Post Office team a chance to look at the three potential service providers, to understand what they are proposing in more detail than was within their documentation, so to be able to help them through the process of refining their offerings to us and also to give them the ability to come back to us and ask further questions and clarification.

Mr Beer: Thank you.

Mr Jeremy Folkes: And at demonstrator – I think was, they were trying to demonstrate their capability and their solution to us, I think that’s where the name came from.

Mr Beer: The demonstrator phase, is this right, was broken down into streams or strands?

Mr Jeremy Folkes: Yes.

Mr Beer: And you were the team leader for one of those strands called POCL infrastructure?

Mr Jeremy Folkes: Yes.

Mr Beer: We will come back in more detail to what that involved in a moment. Your third role was within the evaluation stage and would this be right, in broad terms, it involved scoring the bids against some predefined criteria, and you again had responsibility for part of that process?

Mr Jeremy Folkes: Yes.

Mr Beer: The fourth role was in the development and assurance stage of the system and that’s after the contract had been awarded to ICL Pathway in April and May 1996 and then your fifth role was within the live trials that happened thereafter, or various iterations, as part of the acceptance process?

Mr Jeremy Folkes: Yes.

Mr Beer: Can I turn to the first role – and I’m going to deal with this very shortly – the evaluation of the five selected bidders and the narrowing down of that to three. You deal with this very briefly in your witness statement; no criticism there. Is it right that nothing critical emerged at that stage of the process, so far as concerns ICL Pathway and so far as concerns this Inquiry?

Mr Jeremy Folkes: Correct. That was an initial, if you like, sift to reduce down to three and then we were going to be taking those three forward. So I believe the intention was, at that stage, that everybody who went through in those three should be credible, that passed initial hurdles. So they passed those hurdles, I believe, to get to that stage.

Mr Beer: Thank you. Can I turn straight then to the demonstrator phase or stage and your second role. As we have said, you were the team leader in the demonstrator stage with responsibility for the POCL infrastructure strand. Can we look, please, at WITN05970101. That will come up on the screen, Mr Folkes.

It is a single-page document, which you exhibit to your witness statement, and it sets out, as the heading suggests, the “Objectives of the Demonstrator Stream”, as it is called here. First:

“to clarify the requirements with the three suppliers and ensure that they have a valid understanding of these requirements.”

Second:

“to identify deficiencies in the requirements and to feed these back to the BA/POCL requirements team for resolution.”

Under “Solutions”:

“to explore and understand the supplier’s solutions and to identify issues and risks associated with their solutions (input to Service Provider Risk Register).

“to provide a process to allow suppliers to reduce their Risks.”

Then “Assessment”:

“to assess the supplier’s solutions as input to the overall Evaluation process.

“to provide confidence to the stakeholders in the supplier’s solutions.”

Do you agree that this accurately sets out the objectives of the demonstrator stage?

Mr Jeremy Folkes: Yes, I do.

Mr Beer: So, is this right, it was intended to be mutually beneficial, in particular, it was also intended to be beneficial to the service supplier who may ultimately go on and win the bid?

Mr Jeremy Folkes: Very much so and, from the point of view of being able then to get more information but also to be able to raise concerns with us if the requirements didn’t make sense or were unmeetable in some way.

Mr Beer: So it is not just beneficial to you as the clients, it was intended to improve the quality of the service and the system being proposed by the supplier, in the event that they won the bid?

Mr Jeremy Folkes: Yes.

Mr Beer: This all took place, is that right, in the second half of 1995?

Mr Jeremy Folkes: Yes, primarily, I think, October, November, December 1995.

Mr Beer: Thank you. Can we see what you learned about ICL Pathway in this part of the procurement exercise and look at WITN05970102.

This is a summary of activities as part of the demonstrator stage and is a report, we can see, written by you; is that right?

Mr Jeremy Folkes: It is, yes.

Mr Beer: Who would the report have been sent to? Who was it sent to?

Mr Jeremy Folkes: I believe it was input into the overall procurement team, there was a specific team running the procurement and it would have gone, I presume, from there into the evaluation board at various levels within that team. Unfortunately, I can’t tell you exactly which individuals received it but the purpose of this was to basically summarise what we had been doing over the three to four months and to feed back the key issues from it.

Mr Beer: Thank you. So it would have been seen both within Post Office Counters Limited and within ICL Pathway?

Mr Jeremy Folkes: It wouldn’t have gone to ICL Pathway because this document contains information on all three bidders. It would have been seen within the PDA, the Programme Delivery Authority, or its – the team, as then existed, to do the evaluation, to do the procurement.

Mr Beer: So both the Post Office and the Benefits Agency sides of the house.

Mr Jeremy Folkes: They should have done, yes.

Mr Beer: Thank you. Can we go over the page, please, and just look at the introduction and the second paragraph reads:

“The paper first outlines the structure and organisation of the strand and the general philosophy followed during the life of the strand. This is followed by an appendix per service provider, in which their general style is described, together with a list of meetings attended.”

Then “Background”, under paragraph 2 explains when the demonstrator strand was conceived, October 1995. Ran as one of six strands until closure in January 1996.

Skipping a paragraph: the original plan did not contain an infrastructure strand, per se, “it would have been partly covered by design assurance”, partly by other strands.

You say in the last line there:

“… the Infrastructure Strand enjoyed the dubious advantage of starting in October from a clean sheet.”

What did you mean by that?

Mr Jeremy Folkes: I think when the plan was first put together there was no concept that we needed to look at the infrastructure. The programme was based around the idea of a number of different services and some of those services were applications, such as BES or EPOSS or APS, within the Post Office side, but obviously all those needed to run on a platform and what we were trying to procure was an overall platform for POL to – Post Office to go forward with and the discussions that we had in the programme was that you needed to look at that platform as a whole.

Mr Beer: Got it.

Mr Jeremy Folkes: It was no good looking at – we weren’t going and buying an Automatic Payment Service and separately a BES service and separately an EPOSS service. They were all going to be running on the same hardware provided by the service provider, the same underlying platform services, the same comms network, the same central services. So it was to look at that – the techie side, if you like, rather than the application side.

Mr Beer: I understand. Can we go forward to page 5, please, and look under “Approach” in paragraph 5, and 5.1 “Demonstrator Meetings”, to see what happened. You say:

“The demonstrator process was based around a series of full day meetings with each service provider, with each strand being allocated a specific day of each week for each supplier … as part of the planning at the Introductory meetings.

“[They] were generally held at the service providers main offices … some were located at specific subcontractors sites if this facilitated specific demonstrations … In addition, a two-week period in December 1995 was reserved for ‘site visits’ … this being used for a combination of reference site visits and presentations/discussions with overseas subcontractors.”

You set out the format of each meeting. So is that the approach taken?

Mr Jeremy Folkes: It was, yes.

Mr Beer: Can we go forward to page 15 to see what you say about ICL Pathway. I should say that, in between page 5 and page 15, there is information about the other bidders. I’m concentrating on Pathway.

This is divided into two parts, what you say about it. If we just look at the headings first, C.1 is “Technical Infrastructure Area”, and then, over the page, please, at the foot of the page, “Support Services Area”, yes?

Mr Jeremy Folkes: Yes.

Mr Beer: If we go back to the first page, please. Thank you. “Technical Infrastructure Area”, what does “Technical Infrastructure Area” mean?

Mr Jeremy Folkes: So this basically meant everything around the technical platform that Pathway would be providing for the application services to run on. So this would include everything from the hardware in the office, the communications networks to the centre, what systems would be provided at the centre and all, if you like, the common elements that were not part of the individual applications.

Mr Beer: I understand. You say this:

“Meetings with Pathway took place in the meeting rooms at their offices Feltham. Unlike the other two suppliers, the meetings were fronted by sales orientated rather than technically orientated staff – initially Liam Foley, and then Martin Johnston – and these representatives also took the notes/actions from the meetings.

“Numbers at the meetings varied”, you set out some core members of the team with others being brought in. In the third paragraph, you say:

“The meetings were characterised by less structure and less evidence of preparation than with the other two suppliers. Some presentations were given, however these were fairly informal with very few prepared slides, with diagrams drawn on a flipchart when required.

“Papers were initially hard to extract from Pathway, and although this problem did ease up to a certain extent during the demonstrator … a significant amount of chasing was required to career the outstanding documentation at the end of the phase. Papers themselves varied in quality and detail, with less evidence of internal review prior to issue.”

Then scroll down, please:

“Towards the end of the demonstrator phase, Pathway started taking a fairly robust attitude on risks, with the appearance of their Risk Director (Martyn Bennett) at the start and finish of each meeting to check on the status of risks and actions. Although Martyn took a fairly aggressive attitude towards the demonstrator team, his prime raison d’être seemed to be to ensure that the Pathway staff produced suitable responses. Despite this additional focus, adequate risk responses were still difficult to obtain and a number of risks required repeated iterations of responses before clearance could be recommended.

“In the cross stream meetings, Pathway again took a more sales-orientated approach, with less solution content than with the other two suppliers. This was being evidenced by the demonstration of the somewhat irrelevant Household Budgeting Scheme, and of demonstrating putting demo team photos on cards, rather than showing a prototype of their solution to genuine requirements.”

You are identifying maybe five or six problems with the way in which they were demonstrating to you?

Mr Jeremy Folkes: Yes. What we wanted these meetings to be was a genuine substantive interaction back and forth between the service provider and our team. We felt that that worked with the other two service providers, as far as we could expect. I think it was six meetings over a number of weeks.

What we found here with Pathway is it was the team very much as a sort of sales event. They were run by a sales team rather than a technical team and, you know, they hadn’t prepared as much in the way of technical documentation for us, or diagrams or whatever, and that last comment in there was it felt very “salesy”. They were showing that you could give customer’s cards with photos on so they brought in a card printer and took our photos and put the photo on a plastic card.

That might work from a sales point of view. From my point of view, that was no good whatsoever. I know you can put photos on cards. I wanted to understand their technical solution.

So they seemed to be operating at a slightly different level and they almost saw these as a sales event that kind of had to be done, rather than opportunity to actually work with us. And going back to what you said earlier, the intent here was that it was going to be of mutual benefit to help us understand them but also to allow them to improve their solutions.

Mr Beer: To what extent does what we read here about Pathway’s approach reflect the remaining time that you spent working with Pathway over the succeeding few years?

Mr Jeremy Folkes: Again, it would be simple to say it does reflect it. I think it probably reflects it for slightly different reasons, in that when we moved forward into the contract, it was the PFI nature that I think caused a total difference in opinion. In this case, I’m not quite sure why they took this approach. From our point of view, it was equally as annoying because we wanted to – we genuinely wanted to help all three service providers to come up with the best offerings to the Post Office and BA so that we could then pick the best one from them.

Mr Beer: So it would be dangerous to say that what we read here demonstrated behaviours or an attitude of mind by the company that we then see played out over the succeeding years in its dealings with you?

Mr Jeremy Folkes: In hindsight, I can see similarities but, as I say, I think they are probably for different reasons.

Mr Beer: In the paragraph starting “Towards the end of”, you say:

“… Pathway started taking a fairly robust attitude on risks …”

What does that mean, please?

Mr Jeremy Folkes: Okay, so one of the outputs from the demonstrator phase, or one the tools we had, is we could raise risks against each service provider.

Just to be clear, risk was, basically, we’re raising a potential issue and giving them a chance then to address it. So the fact that a risk was raised, if it was then addressed it wouldn’t count against them, but it gave us a formal mechanism to say “Look, you talked about this, either we don’t believe it or we don’t think it is going to work or it doesn’t meet a requirement”, whatever, “we are going to raise a risk against it”, that put it down on paper as a risk.

Those were then shared with them and they were then given the opportunity to address those risks. And the idea was they could then come back with a risk response which we could then evaluate and that might say “Yes, that risk is fine, it has been cleared”, or it would be a risk, if it wasn’t cleared, that would then go forward into the evaluation and then actually taken forward with the Pathway risks into the real projects.

So what Martyn Bennett was – I think they sussed at this point that if they didn’t take us seriously on risks they were going to count against them because it wasn’t just the individual’s strands who were being – that they were meeting with. If I raise a risk, that risk went into the service provider –

That risk went into the SPRR, the service provider risk register and would then have full visibility and count against them. So I guess, at this point of view, Martyn was doing his job, which was to minimise the number of risks.

At some points, it appeared to us that he was not keen on us not raising risks but he was also, in that line here, I think he was raising that and that seemed to be to ensure that Pathway’s staff produced suitable responses; he wanted them to go and clear the responses because he was going to be marked down if he ended up with 20 risks at the end of it.

Mr Beer: I understand. Can we go over the page please and look at the bottom half of the page, “Support services area”. Can you explain what support services area is please?

Mr Jeremy Folkes: Okay. So when we set up the POCL infrastructure stream, there was a second – there was a piece of work that didn’t really have a home and that was the support services such as helpdesks, such as field engineering, I think such as installation, that didn’t really have a home until we invented POCL infrastructure and then it was added to my remit within POCL infrastructure.

Because support services, Helpdesk, et cetera, wasn’t my speciality, I actually got in an experienced person from POCL who sort of led on this – a guy called Steve Grayston, who led on the support services side. So that was very much looking at helpdesks –

Mr Beer: I think I have the description, thank you. You say that Stephen Muchow was the Pathway consortium representative who dealt with the POCL support service aspects – I think we are going to hear from him in a later phase – and you say “The impression was given that the methodology”, who was that impression given by?

Mr Jeremy Folkes: Given by Stephen Muchow, I think.

Mr Beer: “The impression was given that the methodology by which the procurement was being conducted was unnecessary and time consuming/costly. Meetings were conducted in a more ad hoc manner. Papers and reference documents were not easy to obtain and, when received, were less comprehensive than anticipated. Discussions although fruitful were less flowing than expected.

“A site visit was made [at the ICL facility in Havant]. This was well conducted with appropriate consortium personnel available for questions/information.”

Now, in the course of this stage of the process you, as you have said, held a series of meetings with ICL Pathway, especially in November 1995 and I think notes were taken of the meeting which were turned into meeting reports; is that right?

Mr Jeremy Folkes: Yes.

Mr Beer: I just want to establish the date and the structure of them first please. Can we look please at WITN05970106. This is a meeting report of 1 November 1995. We can see the attendees from the Benefits Agency and POCL, it was you and Mr Grayston, who you just mentioned, and then from the supplier side – from ICL’s side on the right-hand side.

Mr Jeremy Folkes: Yes.

Mr Beer: Did you write these?

Mr Jeremy Folkes: I wrote these yes.

Mr Beer: If we just go through them to put them in evidence. Can we go to WITN05970107 please.

This is a report for the 8 November we have just looked at 1 November, this is 8 November. And then same reference but 0108.

Same reference – sorry, that’s on 15 November 1995. Same reference but 0141, that is for 22 November. Same reference 0109, 29 November 1995. Same reference 0142, that is for a meeting on the 11 and 12 December 1995, I think in Boston; is that right?

Mr Jeremy Folkes: Yes.

Mr Beer: Then, lastly, same reference 0139, 11 January 1996. So those are contemporaneous records that you took, turned into meeting reports of your contact with, at these meetings, ICL staff?

Mr Jeremy Folkes: Yes. Just to say, we were having meetings with all three service providers on Tuesday, Wednesday, Thursday and generating copious notes and, I can’t remember whether it was that evening or the Friday, we spend the time turning these notes into permanent records and then taking forward the individual items within there, including, in many cases, either raising risks or closing down risks.

Mr Beer: That’s why we see, for example, the dates 1 November, then seven days later on 8 November, then seven days later on 15 November, et cetera.

Can I look at some of the thing that were said in the course of three of those meetings reports. Can we go back to same reference, 0106, please.

This is the meeting note of 1 November 1995. Can we look please at the second page at paragraph 13. Thank you:

“Counter hardware. Pathway believe – ‘no problem freezing tech base during the rollout’ (if 12 month-ish). Lengthy discussion, [especially] around POCL wanting to test [equipment]. Pathway expecting very hands-off approach – and practicalities of expecting that stability. All down to Pathway’s agreement with sub-cons. (!)”

Can you tell us what that means please, that paragraph. Decode it for us?

Mr Jeremy Folkes: Okay. The rollout was going to be – would have taken 12 to 18 months to rollout to 20,000 offices and 40,000 or so terminals. One of the questions that we asked, probed, was how they were going to actually manage doing that rollout, as in, do they buy 40,000 bits of kit and put them in a warehouse and roll them out or are they going to be taking them on month by month? Computers changed, technology changes, in particular, firmware versions in PCs change.

It is quite possible that at the start of 18 months the end of 18 months, the hardware may have changed and that would affect things like testing and field support etc. We weren’t trying to manage it, we wanted to understand how they would manage it.

Mr Beer: What was the sentence “Pathway expecting very hands off approach” intended to convey?

Mr Jeremy Folkes: They were expecting BA/POCL to be hands off.

Mr Beer: What do you mean by hands off, what did they mean by hands off?

Mr Jeremy Folkes: So they were not expecting us to have any particular interest in this or any involvement in this. So their view would be – I think it is their job to manage the hardware, what are you worrying about?

Mr Beer: Thank you. Can we turn to same reference 0107, please. These are the meeting notes – or the report of the meeting for 8 November 1995. Can we turn to page 5, please. Can we look at the fourth and fifth bullet point entitled “lack of cohesion” and you write:

“Lack of cohesion between the people at the meeting, must be doubt over ability to manage project if this interface to their customer is so weak.

“General problem that there is no documentation about the system, and late arrival of Mike Murphy and his contradiction/clarification re earlier explanations call into severe doubt the knowledge of the consortia about what they are proposing and then how they may develop it/support it in any timescale.”

Can you explain what you meant by those two bullet points, please?

Mr Jeremy Folkes: Yes. So this meeting, we were looking at the Riposte software that Pathway were proposing. Riposte software which was already in use in An Post the Irish Post Office. Mike Murphy was the CEO and I think owner, part owner, of Escher, the provider of Riposte at the time and Mike came to this meeting.

The observation generally through this note is, there seemed to be a lack of join up between the Pathway people and what Mike Murphy was saying. And, you know, the concern here was that we were there as the customer, we were expecting Pathway to provide a single voice. We were more than happy to have an expert/experts from Escher there, that what’s what we wanted but what we found was a lack of join up as to what it was that Pathway were providing. The whole purpose of the demonstrator phrase was to try and get clarity as to what they were providing.

Mr Beer: You make a bigger point, “must be doubt over ability to manage project if this interface to their customer is so weak”. You are pointing towards the entirety of the project there, is that right?

Mr Jeremy Folkes: I think what I meant in that point was, given the lack of cohesion between this team, in what was probably one of the more important meetings they would have had – you know, when I wrote these notes I was thinking “how would this work in reality on the whole projects”. Now, I went on to say that there seemed to be contradictions and the comment there that there seemed to be doubt about the knowledge of the consortia, ie Pathway overall, and what it was that they were proposing.

Mr Beer: Thank you. Then lastly in this selection of minutes, can we go to the same reference 0109 please. Where this is the meeting report of 29 November 1995. Can we go forward to page 5 please. Under the heading “Riposte” in paragraph 5, look at the second bullet point, you say:

“Went over the failure in the walk through case in tedious detail (again) with Pathway tripping over themselves, and Martin Johnson trying (badly) to show that he understood something. Pathway seemed keener to rubbish the specific example we had come up with, rather than addressing the issue. Seemed to miss the point that Mike Murphy had acknowledged it and did have an answer (using strong identity – see earlier) but Pathway were unable to explain.”

Can you decode that for us? Explain what you were referring to there?

Mr Jeremy Folkes: I can’t remember what the specific case was but we had come up with, “well, how will this work”. The Riposte system, if I can just digress for a moment, involves software running on each one of the terminals in the office and these terminals, they can replicate data between each other and replicate data up to the data centre and that’s the whole benefit of this and the whole way the system operates. We, I think, had come up with questions about failure cases, what would happen if that became disconnected, or that became disconnected? And what we wanted to tease out is (1) how did these failure cases happen, but also, what became clear is that the Pathway board didn’t necessarily understand it. In this case Martin Johnson – who I think was a sales person, who was sort of, no disrespect meant to him, but he was in these meetings to sort of manage the meeting rather than provide technical information – went off trying to explain how Riposte works; which wasn’t a great success from what I see here. When we started raising issues on failure conditions they seemed to be keener on rubbish the specific examples we put forward rather than trying to address it.

Mr Beer: Can we go over the page, please – sorry.

Mr Jeremy Folkes: In a population of 40,000 terminals, if it can go wrong, it will. You know, it is not like – I am sure the IT guys with their systems here will probably tell you the same with 100 terminals. In a big Post Office estate, failure of hardware and network counters(?) it was always going to happen, therefore you needed to ensure, especially with a distributed system, that there was adequate coverage of the failure cases and that the system would work. What we had here was that the examples appeared not to be taken seriously rather than being addressed.

Mr Beer: In that sentence you said “especially with a distributed system”. What do you mean by a distributed system?

Mr Jeremy Folkes: Okay. So there are – in the Riposte system there’s persistent storage on every terminal and the great advantage of this, it gives the ability for the terminal to operate even if the communications to the centre is offline. But a number of the other solutions, including I believe Horizon online, which Post Office then moved to and also from, I believe, CardLink and IBM, they were reliant upon online solutions. That would have meant that if the communications to the centre went down for any reason, that there would be cases where the counter clerk just wouldn’t be able to serve and the ability to serve, even in cases of failure such as a network going down, was important to the Post Office. And that was one of the perceived advantages of the Pathway solution, that it was distributed and therefore as long as the terminal was up and running, they could still serve.

Mr Beer: Thank you. Over the page please. Can we look at the second bullet point from the bottom please. You say:

“Another extremely frustrating, contradictory day. Pathway seem afraid to admit that they are changing Riposte. On [the] one hand it is of concern as the changes reduce the value of the reference sites/track record, on the other it is good at showing that they recognise that the product is not perfect and may need changing for the higher volume environment that they are proposing … However, the secretive and ill-informed attitude is damaging credibility and amplifying our own doubts over the viability of the product.”

We have looked at three examples of the things that you said in meeting reports on 1 November, 8 November and 29 November 1995.

Was the kind of thing that you were saying here, fed back into those who had power to make a decision over the award of this contract and if so how?

Mr Jeremy Folkes: It was fed up in the summary document, particularly it was fed up in the risks. So we had specific risks. The risks had very high visibility. Risks on, for instance, the scalability Riposte, the relationship with Escher, the ability of Pathway to manage the relationship with Escher and that those risks – I think I go through a list of them in the witness statement – those risks were visible all the way up to the evaluation board.

Mr Beer: I was about to say, to which people within POCL were these meeting reports sent or distributed?

Mr Jeremy Folkes: These meeting reports that I had here, I think would have only been distributed within the demonstrator team. These were obviously very detailed contemporaneous material.

The risks that came out of these went up into the procurement team, to the service provider risk register and they would have been visible at the level of the evaluation team management and the – I can’t remember the names on all of those but there is a document which records the outcome of the evaluation that has a list of the personnel who were in the – on the evaluation team.

Mr Beer: Notwithstanding what was written here, we know the five bidders were narrowed to three. Did you express a view at that time about Pathway being amongst that group?

Mr Jeremy Folkes: Sorry, these meetings here were when we were already at three.

Mr Beer: Thank you. Can we turn, then, to your third role which was, I think, the evaluation stage and you say that there was a part it codenamed Amazon.

Mr Jeremy Folkes: Yes.

Mr Beer: Amazon was, more specifically, an evaluation of the three bidders responses – paper responses to the rather extensive invitation to tender document; is that right?

Mr Jeremy Folkes: Yes.

Mr Beer: Would this be in February and March 1996?

Mr Jeremy Folkes: I believe so, yes.

Mr Beer: Did it involve the team, of which you were a part, working away from the office, in particular, for an intensive two week session?

Mr Jeremy Folkes: Yes.

Mr Beer: Looking at it in high level summary, were there two elements or parts of it: firstly, a financial and risk transfer evaluation and, secondly, a business and technical evaluation?

Mr Jeremy Folkes: Correct. I think it was the second of those that I was involved in.

Mr Beer: Now, I think the evaluation took place by reference to a combination of monetary and nonmonetary factors, is that right?

Mr Jeremy Folkes: Yes, although the part that we were involved in was purely on the qualitative rather than the quantitative.

Mr Beer: Can we look at those please at POL00031154.

You can see this is a document of which you are not the author dated 11 March 1996, “Supplier scores in respect of value factors”. You are familiar with this document I think?

Mr Jeremy Folkes: Yes.

Mr Beer: Can you explain, in general terms, what it is?

Mr Jeremy Folkes: Okay. So the procurement team – and Derek Selwood was a member of that team – had come up with a scoring model.

The model had a fairly complicated mapping of, “value factors” they were called, in a number of different categories.

I believe there is a table in there that explains what those are. I can’t remember them individually.

Mr Beer: Can we go to page 7 of the document please.

If we just look at the whole thing. Is that the table of the value factors that you were just speaking about?

Mr Jeremy Folkes: Yes.

Mr Beer: Then if we go to page 9 please. We can see the – if we can display page 10 at the same time please. We can see the two teams, the “contracts stream” on the bottom of the left-hand page and the “demonstrator stream” on the right-hand page?

Mr Jeremy Folkes: Yes.

Mr Beer: Of which you were a member and the group leader for, again, POCL infrastructure; is that right?

Mr Jeremy Folkes: Yes.

Mr Beer: Can you just tell us what, before those two streams, the programme review panel was, the membership of which is set out in the top left-hand side of the page?

Mr Jeremy Folkes: I think the programme review panel was, if you like, the senior team providing the evaluation. They had representatives from each one of the streams. So you have got on there one or two representatives from the demonstrator team, one or two representatives from the contracts team. You also had people on there who were not part of the demonstrator, for instance Bob King, who was a Post Office Counters manager but he wasn’t part of the programme as such.

Mr Beer: Thank you.

Mr Jeremy Folkes: The demonstrator team was doing detailed work that then fed into that and I presume the contracts stream likewise.

Mr Beer: Can we go forwards to page 11, please. This is annex C of the document. If we can look at the whole page to start with, please. I think this breaks down the ten value factors that we looked at earlier. In fact, we only displayed 1 to 7 of the value factors.

Then, by reference to a series of topics identified in the left-hand column, it shows us by a tick the likelihood of those value factors having relevance to the issues identified; is that right?

Mr Jeremy Folkes: Yes, I don’t think I would use the word “likelihood”. They were the ones that – we were scoring, I believe, based upon what’s in the left-hand column by the different functional areas of the solution against criteria set by the value factors and some of those – some of the value factors weren’t deemed relevant to the area, hence the lack of a tick.

Mr Beer: For your part of this stream of work, looking at the list down the left-hand side, which of the identified headings and then subheadings were of relevance to you?

Mr Jeremy Folkes: I will be honest, I can’t remember whether we just did our own area or whether, as a team – I have a feeling as a team, the whole team went through it but maybe we led on an area. Certainly, the POCL infrastructure section on there would have been the area that I would, if you like, led upon.

Mr Beer: That included “OP”. What does “OP” stand for?

Mr Jeremy Folkes: Okay. So the vision for the programme had a number of services and one of the services was the office platform service, OPS, office platform being, at its simplest, the PC in the office and the devices attached to the PC in the office and, in that case, the middleware which in this case would have been Riposte, the firm of suppliers, would have been whatever middleware they were proposing.

Mr Beer: Can you just explain to the Chair what middleware is, please?

Mr Jeremy Folkes: Okay. Typically a software system has a stack of different elements to it. At the top of that stack you would have applications, bottom of the stack you have the hardware. Middleware, as it is, suggests is what goes in the middle. It tends to be software that provides a technical function, such as a database or, in the case of the Pathway solution, message replication system. It doesn’t necessarily have any sort of user interface. The counter clerk user doesn’t know they are interacting with it but it is sitting there providing a vital function.

Mr Beer: So the type of software that provides services to software applications, other than the operating system?

Mr Jeremy Folkes: Correct. Far better way of putting it, thank you.

Mr Beer: “WAN”, please?

Mr Jeremy Folkes: Wide area network.

Mr Beer: What’s the wide area network?

Mr Jeremy Folkes: So the wide area network is what was going to link the individual post offices to whatever central system which the service provider had. In the Pathway case, that was using ISDN in the majority of the cases.

Mr Beer: TMS, transaction management service?

Mr Jeremy Folkes: That was the central systems that the service provider would provide, which, in Pathway’s case, would have included the central correspondence servers and other sort of mainframe type systems behind them.

Mr Beer: In order to score these issues listed under POCL infrastructure, that would require the demonstrator team, including you, to be able to judge satisfaction or compliance with the value factors at a detailed technical and granular level; is that right?

Mr Jeremy Folkes: Yes. That was done by reference to the responses that the service providers gave to the information to tender. So they provided the – each one provided their bids and they had to respond, I believe, to each individual requirement and then we had to score those individual requirements.

Mr Beer: Thank you. Can we go to paragraph 34 of your witness statement, WITN05970100, at page 11, paragraph 34. You tell us:

“One key aspect of PFI [private finance initiative] was that requirements had to be presented as high level ‘Output-Based Specifications’ so as not to constrain the Service Providers, that is stating the ‘what’ but not the ‘how’, and at the level of the Service rather [than] a system. This was contrary to most experience where specifications would be far more detailed and include some ‘how’.”

You are making the point here, is this right, among a series of other points about the effect at this stage of the contract being a PFI?

Mr Jeremy Folkes: Yes.

Mr Beer: How could the exercise that we have just looked at be undertaken or how could it be completed without detailed insight into the “how”?

Mr Jeremy Folkes: The requirements had to be presented as high level output-based specifications. We weren’t allowed to tell them how to do something. The service providers had to respond in their tender documentation and tell us to a level how they were going to meet that requirement, and the purpose of the demonstrator was also that we gained understanding of how it was going to be done. So what we were scoring was their responses to the invitation to tender.

Mr Beer: Without knowing what sat underneath the responses?

Mr Jeremy Folkes: They had to provide sufficient information in the response for us to be able to score it. That wasn’t going to be down at the level of detailed design because at this stage they had not done detailed designs but they had to provide adequate information and, if they didn’t provide sufficient evidence, then they would have got a low score.

Mr Beer: You tell us in paragraph 35, if we can continue:

“The other key aspect of PFI was that of Risk Transfer. Whilst there was an explicit and well-defined attempt at Risk Transfer for certain types of Benefit Payment Fraud by BA, there were of course many Risks which could not be transferred to a Service Provider, as POCL has found to its cost over the years.

“36. Outsourcing a major part of your core business (and the transaction processing/counter system for a Post Office is about as core as it gets) does not remove the risk to that business if the counter system (or service) does not perform. Paraphrasing somewhat, the ethos was that risk was transferred to the Service Provider, and so we should not worry about it. If they failed it was at their cost. I think this was a fundamental issue – whatever idea there was of Risk Transfer in specific areas, POCL still needed assurance in the quality and fitness of the service being developed and provided by the Service Provider, to manage the risk to their business.”

What you have said there in paragraph 35/36 is said by you in the context of the transfer of fraud risk to ICL Pathway but does the point apply more broadly, ie that ICL Pathway were saying that POCL should not worry about the project because, if it failed, then it was at their cost?

Mr Jeremy Folkes: Simple answer to that is yes. Can I just say 36 wasn’t specifically about fraud risk. It was – what I was trying to say there was the PFI ethos was all about risk transfer and what I feel in 36 is that some risks can be transferred, for instance, certain risks regarding benefit encashment were transferred but the risk that the service provider gets it wrong and screws your business can’t be transferred.

And that was the whole basis on which we felt, in the assurance team – we have jumped forward a bit here – in the assurance team, that we did need to, if you like, know what was in the box. Waiting for the service provider to get it wrong and then they then take a financial penalty, it wasn’t going to help POCL. What we wanted to do was to understand what Pathway were doing and make sure they were doing it in the right way so that we ended up with a successful solution.

Mr Beer: You are saying that ICL Pathway’s ethos was that you – that’s POCL – should not worry about it and you are saying this in your statement at a point where the contract was still a PFI one involving the Benefits Agency. Did the same approach still apply when the Benefits Agency had pulled out: this was not a PFI contract and was instead a much more standard design and supply contract?

Mr Jeremy Folkes: In 1999, bearing in mind I left at the start of 2000, so I don’t know how it went after that – in 1999, I think it was still very much in that ethos. I think the key point, though, is the damage was done by then. We had gone through from when Pathway started work in 1996 through until the point that the contract was renegotiated in the second quarter of 1999, under the PFI cloud.

And suddenly saying this is not a PFI contract any more, we didn’t suddenly get access to everything we had not had access to over those three years and things that may have happened during those three years didn’t mysteriously go away.

Sir Wyn Williams: Mr Beer, if I may, I think I need a five-minute break.

Mr Beer: Sir, of course, and in fact I fortuitously was about to suggest one because of the transcribers have suggested that we should go for an hour or so.

Sir Wyn Williams: Well, then, if that’s the case, are we having a more traditional break or just five minutes?

Mr Beer: Just five minutes, please, sir.

Sir Wyn Williams: Thank you.

Mr Beer: Thank you very much.

(12.07 pm)

(A short break)

(12.14 pm)

Mr Beer: Can we turn, Mr Folkes, to paragraph 37 of your witness statement, which should be on the screen. You say:

“As the Project progressed, it appeared that the effect of PFI was that we were expected (by the [Service Provider]) to treat the underlying solution as a ‘black box’. The Service Provider’s job was to ensure it created the right outputs but the contents of the box were not available for scrutiny – either how it worked or how it was being built. As I will cover later, this had major effects on POCL’s ability to gain assurance on the solution and to inform later activities.”

This idea here that ICL Pathway expected you and Post Office to treat the system as a “black box” is one that you return to in the course of your statement. Are you using the term “black box” there as a term of art, not in the sense that a layman like me might understand it, to refer to and only to refer to a flight data recorder on an aeroplane?

Mr Jeremy Folkes: It is not a flight data recorder. A black box, I think, is something that you can’t see inside.

Mr Beer: So it’s a term of art, would this be right – I’m going to have another crack at a definition here – it is used in science, computing and sometimes engineering to refer to a device, system or object which produces useful information without revealing any information about its internal workings?

Mr Jeremy Folkes: Yes.

Mr Beer: Is that the sense in which you’re referring to “black box”?

Mr Jeremy Folkes: What I was meaning here is the approach that the service provider took was that the solution was a box that we couldn’t see inside. It was there to take those inputs, provide various outputs. They had a set of requirements. Their job was to make sure it met the requirements but we weren’t permitted to either see how it worked inside that box or how they had built the box. And I noticed the word used in another document, it is a matter of transparency. The black box is not transparent.

Mr Beer: You say, in the last sentence, that this:

“… had major effects on POCL’s ability to gain assurance on the solution and inform later activities.”

Why was that?

Mr Jeremy Folkes: Okay, so we were set up, post award of contract, as a team whose role it was to try and provide design and technical assurance of what Pathway were producing, if you like to provide an oversight of what Pathway were doing to provide a good feeling back to the sponsors, to feed issues back to the sponsors and to make sure Pathway didn’t head off in the wrong direction for whatever reason.

What we found were that Pathway were very reticent to let us actually get hold of information as to how the system worked internally, in particular denied us access to design documentation. Now, that may have been because such documentation didn’t exist. At the time, we assumed it was because they were playing what I call later in the document the PFI card, they didn’t want our interference in it and didn’t want to share that documentation with it.

Because we couldn’t see how it was going to be produced and how it was going to work internally, we could that the then go back to the sponsors and say “Yes, what Pathway are doing on EPOSS or APS, or whatever, is good and meets our requirements”.

What I mean by later activities is we weren’t trying to trick Pathway, we were trying to make sure it was going in the right direction and then make it easier when we got to acceptance to make sure that what had been produced was going to get through acceptance.

Obviously, getting to acceptance and not knowing what was inside the box made it far harder to carry out acceptance properly.

Mr Beer: Looking back at the matrix that we viewed before the break in annex C, wouldn’t it make it very difficult or impossible to undertake any qualitative analysis of the type required by that exercise?

Mr Jeremy Folkes: It would but, bearing in mind what we are talking about here is the comments on PFI is what happened after award. During the evaluation process and during the demonstrator phase, in particular, the service providers had to produce their responses. We had a mechanism through the risk creditors to be able to say “Hey, we are worried about this or that”, and they had to produce documents. If they didn’t, it counted against them.

So they had a positive incentive to respond to us. Once we got to assurance they had a positive incentive to go as far as saying obstruct us in some cases.

Mr Beer: We would come onto what you say about ICL Pathway’s obstruction a little later.

Can we look at paragraph 38. You say:

“Put informally, the approach seemed to me a case of ‘Trust Me, I’m a Doctor’ – having told them at a high level what we wanted the Service to do, we were meant to trust them as the experts to create and run the Service. We would have Acceptance at the very end, but we would have no visibility of what was ‘in the box’ or how it had been built, and only be able to perform Acceptance based on those output-based specifications.”

You are obviously saying here that the “doctor” was ICL Pathway saying, “You need to trust us, we are doctors, we are experts in information technology”?

Mr Jeremy Folkes: Yes.

Mr Beer: Did you have this unease at the time or is this something that you have thought about on reflection 20 years later?

Mr Jeremy Folkes: We had unease during the programme that we were – our job was to do assurance and we couldn’t do the job. And I know we reported this up and it is documented in a number of places, all the way up to the top level decisions, that we had not been able to get assurance on the state of the project.

Mr Beer: When you say reported up to the top level decision, you mean to the POCL board?

Mr Jeremy Folkes: I can’t say it was to the POCL board. I haven’t had access to everything they did but, certainly, if you look at the documents from middle of 1999 around acceptance, there’s statements in there around the lack of assurance that we had been able to get and that’s the culmination of what we had been trying to do from 1996/7, all the way through.

Our intention was not to try and trick people. We all wanted this thing to get through. What we wanted to do was to get assurance as to the direction in which they were going and, in cases where we were allowed access, I think generally we came away with quite a good feeling on a number of them and some of that was around some of the deep, technical infrastructure. It was the areas where we didn’t have access that it appears that we may not have had access, essentially because there were problems in those areas.

Mr Beer: Is that why you explain them playing the PFI card?

Mr Jeremy Folkes: Yes.

Mr Beer: What do you mean by “playing the PFI card”?

Mr Jeremy Folkes: What I mean is that, in a number of cases where we tried to get access to documentation, the answer would always come back, “No, it is PFI, it is not appropriate for you to have that”, as we heard from Terry Austin. It wasn’t appropriate for the contract, or whatever the words he used. No, the contract – I think part of the problem here was the contract didn’t support us getting this level of visibility. The service provider could have given it to us but chose not to, which is why, in my statement, I do say I think the way the contract was put together was the cause of some of these problems.

Mr Beer: You have described it as –

Sorry, that can come down, that witness statement, now.

You have described it as “playing the PFI card”, which has a pejorative element to it, as opposed to “doing that which is required under the PFI contract”. Why do you say that they were “playing the PFI card?”

Mr Jeremy Folkes: I say that because it was blocking the task that we were trying to do and that we, by the nature of our roles, were tasked to do. I think Pathway would have made documentation available to us, could have involved us more, could have been more open and transparent with it but they, in a number of areas, you know, forcefully did block access. It didn’t just seem to be a passive thing, it seemed to be actively preventing access, which is why I used the language I did there.

Mr Beer: Can we go back to the evaluation stage and look at POL00028152, please.

Looking at the front page, this is the evaluation team’s final report, dated 28 April 1996. Did you see this at the time?

Mr Jeremy Folkes: I can’t remember if I did or not. There certainly are parts that our work went into but I can’t remember if I actually had a copy of this at the time.

Mr Beer: Can we turn to page 15, please, and look at the bottom of the page, please, under “The Value Assessment and Financial Results”. The “Process” is described:

“The treatment of Value Factors, including the weightings and sensitivity analyses to be applied to the scores in the evaluation is described in paper … This paper was agreed by the Procurement Board late last year and lodged [with] the programme lawyers prior to receipt of tenders.”

If we continue, please. If we look at paragraph 7.2, please, it is on page 17. Thank you:

“The scores resulting from the assessment … are shown below. The layout reflects the pre-tender agreement that the factors would be categorised as either ‘Characteristics’ or ‘Viability’. Viability would consider the soundness of the essential services in terms of the internals of the service delivery, while Characteristics would look more at the external factors affecting the potential success of the services.”

You didn’t give these scores; is that right?

Mr Jeremy Folkes: No, no, no. These scores came from an overall scoring process which the whole team produced and then they went through a process of weightings, et cetera, to actively ratchet up to this level.

Mr Beer: If we just quickly look down at the three service providers there, we can see, in relation to the ten value factors that we looked at, do you remember in annex C, the first of them customer acceptability, Pathway is joint lowest; Flexibility, Pathway is the middle; reliability and support, Pathway is the lowest; innovation, it is the middle of the three; as with staff/agent acceptability.

Then “Viability”: fraud free method of payment, Pathway is the lowest; credibility of delivery, Pathway is the lowest; management capability, Pathway is the lowest; start-up, Pathway is the lowest; stability and coherence, Pathway is the lowest.

Is that right? You remember that at the time, do you?

Mr Jeremy Folkes: I don’t remember the exact scores but I remember that shape of things, yes.

Mr Beer: Then over the page, please. We will skip over that figure and look at the table where weightings are applied to the scores that have been given. We can see that under “Characteristics”, Pathway comes bottom and under “Viability” Pathway becomes bottom, yes?

Mr Jeremy Folkes: That’s what it says, yes.

Mr Beer: Then can we go to page 21, please. This is analysis and conclusion. There is a list of people there who are said to have considered the results of the evaluation and reached a conclusion. I do not think you are one of them; is that right, that you didn’t participate in this?

Mr Jeremy Folkes: Correct, yes. This was considerably higher up the food chain than I was allowed to be.

Mr Beer: But you contributed data on which this group of people made their decision?

Mr Jeremy Folkes: Yes. The scores that we did and the risks that we produced went into that process and Tony Johnson, who is on that list there, he was, I believe, was managing – he was representing the Demonstrator Stream.

Mr Beer: Then if we look at 9.3:

“The group considered the results from the various streams of activity …

“the Contracts Assurance review ranked the suppliers in the order Pathway [I think, top] IBM, Cardlink …”

In the last sentence there in (a):

“Pathway should be preferred to IBM unless IBM’s bid offered a considerable price advantage.”

“the Financial Evaluation … had shown IBM with the lowest cost of service but Pathway sufficiently close for the two to be regarded as virtually equal …”

Then the value factor, that’s the thing we’ve just looked at:

“… a close much between the three suppliers in terms of the ‘external’ factors … the order within that being Cardlink, IBM and Pathway [that’s Pathway bottom]. On ‘internal’ factors covering the soundness in terms of service delivery (eg stability and coherence, fraud-free method of payment) the order was again Cardlink, IBM and Pathway, with the first two being significantly ahead of the third.”

Then over the page, please. If we just go to the conclusion at 9.9. So, in light of what’s been said, what we have just read, the group “unanimously” decided that the contract should be awarded to Pathway. If we go back to 9.7, please:

“The group recognised that an award to Pathway would imply a need for a proactive management stance by sponsors, notwithstanding the improvement noted by the Contracts Stream since the restructuring immediately prior to [invitation to tender] issue. It would also require sponsor staff to work closely with Pathway on fraud prevention measures, although given the changes on fraud risk made by the other two bidders in their re-tenders most of this work was likely to be required whichever supplier were chosen.

“Whilst acknowledging the complications of selecting Pathway, the group considered this a far preferrable prospect to the consequences of awarding to IBM (in the unlikely event of their being regarded as PFI-compliant) given IBM’s stance on fraud risk transfer and other factors, most notably limited liability.”

Do you think what the phrase “proactive management stance” means?

Mr Jeremy Folkes: I think it meant what we were trying to do and – within the assurance team and what we, I have to say, in some way, failed to do, because we weren’t allowed to and were blocked doing it.

Mr Beer: Was it possible to take a proactive management stance under a PFI when the service – excuse me – supplier said “Trust me, I’m a doctor, you can’t see what’s in the black box or how we’ve designed it”?

Mr Jeremy Folkes: I think it would be very difficult to. When I read this, and I don’t know whether I had previously seen this document or not, but it did strike me as ironic that the problems that we had and then, to be honest, suffered for at least two years in the period, sort of 1997 to 1999, in trying to do assurance, was kind of, I think, flagged up here as “Oh, you’re going to need to do more of this”.

And I think there was a – my view when I was working on this was – looking at this end of the statement, is there should have been more support from up on high within BA and POCL to make sure that we were able to do our task and whether that required a different contract or a better contract, something done to actually enable us to manage that the risk was in here.

Mr Beer: Was it communicated to you that, in the light of the award of the contract to Pathway, there needed to be a proactive management stance in the future?

Mr Jeremy Folkes: I have no recollection of that.

Mr Beer: By that, do you mean that it may have happened but you now do not remember or more positively –

Mr Jeremy Folkes: I am sure I would have remembered if there had been a meeting to say “We are going to give it to Pathway but, hey guys, we are going to need to set something special up to manage them”. My understanding was we got to the end of the evaluation phase, all this took place and then people transitioned onto the assurance phase. But I don’t remember any – I have got no record of any process, meetings, whatever, that said, “because it is Pathway, we need to do X”.

Mr Beer: Thank you. Can we look please at WITN05970100, your witness statement, at page 22, please. It is paragraph 66. You say:

“My understanding from reading document …”

You quote it, that is the document I have just shown you:

“… is that Pathway were the only one of three [Service Providers] who were considered PFI-compliant regarding fraud risk transfer for BA; the other two [Service Providers] were not PFI-compliant. Ironically of course, BA then withdrew from the project in 1998/1999 rendering this factor in the decision rather irrelevant.”

Now, I think what you are doing there, you are referring to the fact that an important factor in awarding ICL the contract was the non-compliance of the other two service providers, in particular in relation to fraud risk transfer?

Mr Jeremy Folkes: Yes.

Mr Beer: The irony that you are referring to when you say “ironically of course”, would this be right, a twofold irony: firstly, the Benefits Agency then withdrew in 1999, so the risk of fraud on the Benefits Agency was no longer a relevant consideration?

Mr Jeremy Folkes: Precisely yes.

Mr Beer: And, secondly, this was no longer a PFI contract in 1999 and, therefore, the extent to which either of the two failed bidders were PFI compliant was, in 1999, now irrelevant?

Mr Jeremy Folkes: I hadn’t, when I wrote paragraph 66, thought of that aspect, for the simple reason that, by the time we got to 1999, as I said before, the damage was done. We got to the system as it was at that point and deciding this wasn’t PFI any more wasn’t going to change the way in which Pathway had behaved over the previous three years.

Mr Beer: I want to ask you about that. Can you recall whether any thought was given in the spring of 1999, perhaps up until May 1999 after the Benefits Agency withdrew and these two points, that I have mentioned, carry no weight as to whether the process of letting the contract to Pathway should be undertaken again, given what we have read about of ICL Pathway’s weaknesses on technical risks?

Mr Jeremy Folkes: There were, I believe, many discussions that went on as to whether the removal of themselves by BA meant that the project should stop or go on or how it would go on. These were well above my level of discussion but they were, I believe – from what I have read, all the way up into government – discussions as to whether the project should go ahead or not.

Mr Beer: I will put it another way. In the documents that we have read, ICL Pathway at its bid, suffered from, over time, an assessment by POCL of serious and sustained technical risks. Was thought given to resetting – pressing the reset button to say “Look, you got over the line, Pathway, because of the strength of its contractual provisions, where the other two failed bidders failed? We now need to undertake a fundamental re-assessment, given what we know, albeit some of it is obscured by the black box, of the technical risks of the ICL Pathway programme”?

Mr Jeremy Folkes: I’m not aware that there were discussions of reassessing the Pathway solution at that point. There were certainly discussions as to whether the project should go ahead or not. But bearing in mind at this point whilst the Benefits Agency were extracting themselves, POCL and Pathway were heading towards trying to get towards acceptance and trialling, et cetera.

The efforts that were going on on the project, at that point, I think, were primarily towards that rather than a fundamental reappraisal. I believe that the Post Office missed a trick by not modifying the contract in some way that forced us to be able to get hold of everything that we hadn’t been able to before.

Mr Beer: We’ll come on to the possible missing of the trick a little later, possibly, this afternoon. Can I turn to your fourth role then. That’s your involvement in the development and assurance of the Horizon system after the award of the contract to Pathway in April and May 1996.

You explained in your witness statement, is this a fair summary, that this part of the project was, within POCL, arranged in a similar manner to the demonstrator phase, with teams being allocated to specific areas within the project and you were allocated the POCL infrastructure aspect, just as before?

Mr Jeremy Folkes: Correct. I’m sorry, the one difference is, at that point, is – at that point, the support services part, I think there was a separate group who were going to deal with implementation and rollout, and I think they took on issues – well, consideration of anything to do with the rollout side.

So, at that point, POCL infrastructure was the technical side of the infrastructure rather than including the support services.

Mr Beer: Thank you. Can we turn up WITN05970100. This is your witness statement. Can we turn to page 24, please. If we just look at paragraph 72 and 73. You say:

“As [you] remember it, [your] role in assurance was to try to monitor the development of the service to gain increasing confidence in the emerging Pathway solution, to assure its performance/security, whilst also trying to support them by providing access to resources in BA or POCL where needed (admittedly that was more relevant for the Applications teams).

“73. In addition to de-risking the project and facilitating the flow of information, we were also mindful of the fact that eventually there would need to be both a contractual acceptance of the solution/services and Release Authorisation decisions, and that gaining confidence and knowledge throughout the process should make this simpler – basically it was a means of avoiding surprises downstream.”

In relation to the activities that you describe there, is it right that you set up a technical assurance forum?

Mr Jeremy Folkes: We did. We tried a number of different approaches. The technical assurance forum was one of them. The intention of the technical assurance forum was to try and give some structure because we had been criticised by – I think, for wanting access to everything so we tried to have a more structured approach to it.

Mr Beer: Who was criticising you?

Mr Jeremy Folkes: That was criticism coming from people who were trying to access within Pathway.

Mr Beer: They were saying “You’re seeking too much information from us”?

Mr Jeremy Folkes: Yes.

Mr Beer: You say, elsewhere in your witness statement, that Pathway refused to disclose design documentation to you and that the Pathway management obstructed access to documentation and sometimes cancelled meetings.

Mr Jeremy Folkes: Yes.

Mr Beer: Did that happen at this stage?

Mr Jeremy Folkes: Yes.

Mr Beer: Is that why you used the word “obstruction” by ICL Pathway?

Mr Jeremy Folkes: Yes, but more generally in that we found that, at a working level, if we could get contact to individual engineers or individual managers of areas, they would generally be helpful. When we tried to get hold of, for instance, formal copies of documentation or access to – either it was denied to us – well, it was denied to us either because it was deemed not appropriate or in some cases – well, it probably didn’t exist.

Mr Beer: So was the technical assurance forum an attempt to find your way through this obstruction?

Mr Jeremy Folkes: Yes.

Mr Beer: Can we look, please, at WITN05970138. These are the terms of reference for the technical assurance forum and you can see they are dated 9 December 1998. I think this is a document that you co-authored with a Mr Long; is that right?

Mr Jeremy Folkes: Yes.

Mr Beer: Was he from ICL Pathway?

Mr Jeremy Folkes: He was from ICL Pathway and he was the sort of contact partner I had at that point for this work.

Mr Beer: I think it is right that the technical assurance forum had already met a number of times before these terms of reference were drawn up because I think we got some agendas for some previous meetings that pre-date 9 December 1998. Would that sound about right?

Mr Jeremy Folkes: As I said, we went through a number of different approaches to doing this, so quite possibly yes, we had met beforehand and, as part of that, it was “Okay, we want to formalise this”, December 1998 being quite late in the process. So that’s why I think this wasn’t – there were other papers, I think as I referred to in the witness statement, of slightly earlier approaches towards this.

Mr Beer: If we look, at the same time, at WITN05970129, we can see an agenda for a technical assurance forum, it is the second meeting, “Meeting 2”, and it is dated 30 September 1998, so a couple of months before the terms of reference document.

But you are, I think, saying there were a number of approaches that you tried to take to find a pathway through this?

Mr Jeremy Folkes: Correct.

Mr Beer: We can just look at the document on the left-hand side, please. Can we look at page 2 of the document, please, and read the “Background” at paragraph 2:

“One of the responsibilities of the Product Assurance Group within the POCL Horizon programme is to make a recommendation to the Release Authorisation Board … for each release of the Pathway service as to the fitness for purpose of that release for its intended environment. One of the viewpoints for this recommendation is from the Technical Assurance angle, and in particular covering the (as opposed to functionality) characteristics of the service in four key areas, [namely]:

“performance and scalability

“integrity

“service availability and resilience [and]

“security.”

What does “integrity” mean in this context?

Mr Jeremy Folkes: “Integrity” I would take in this case to basically mean that what data comes in is correctly processed and comes out without being modified, without being destroyed, and so and so.

Mr Beer: Reliability and credibility.

Mr Jeremy Folkes: I would say reliability of the service is does it work consistently over time? Integrity is, you know, is it – it is the sort of word I use all the time, I can’t think of a better way of describing it. Integrity: is there a clear trail from the data that goes in to the data that comes out at the other end? Is it immutable, is it reliably going to be processed? Sorry, I have a mental block on the wording around it.

Mr Beer: That is okay. Thank you. You say in your witness statement, the cross-reference is paragraphs 76(a), (b) and (c) and you cross refer us to documents that you wrote in July ‘97, January ‘98 and May ‘98. I’m not going to ask you about those but, instead, ask you some more general questions.

We can take this document down now. You were still operating under a PFI contract at this time?

Mr Jeremy Folkes: Correct.

Mr Beer: Given you were still operating under a PFI contract, where the supplier was saying that, so long as the outcomes would be delivered in accordance with the requirements of POCL, that POCL need not worry, why did you, nonetheless, engage in this technical assurance process?

Mr Jeremy Folkes: The trite answer to that is because it was my job to. The probably more useful answer to that is because, to try and assure the success of the project, we believed we needed visibility of what Pathway were doing and that included not just the functional characteristics but also the technical characteristics – the how it behaved – and to understand that, that we wanted and needed visibility of the design and that we needed visibility of things, like how they had analysed (unclear).

Mr Beer: I think you reference those kind of answers in a document that you wrote back in July 1997. I wonder whether we could look, please, at WITN05970113. This is written by you under the authority of Mr Meagher?

Mr Jeremy Folkes: John Meagher [pronunciation corrected] he is, not “Meeger”.

Mr Beer: Thank you very much. Dated 23, I think, or perhaps 22 July 1997.

Mr Jeremy Folkes: Yes.

Mr Beer: You will see the title of it, “The Level of Information Needed for Technical Assurance – A Discussion Paper”.

If we can go forward to page 3, please. Under the heading “The Need for (Technical) Assurance”, you set out some of the key reasons for assurance under five bullet points:

“to minimise [the] risk course to sponsors – major significant business/political risk are still owned by the Contracting Authorities [that is POCL and BA at that time], and contractual remedies are not sufficient to mitigate the effects of failure of the Pathway service.

“to ensure compatibility between various suppliers’ solutions – the ‘end to end solution’ includes services provided by both Pathway and a variety of other organisations …

“to control solution drift … “

I think a separate paper was written about that:

“to enable ‘acceptance’ – a number of requirements … relate to attributes of the service rather than business functionality.

“to inform the Release Authorisation Process – we need to have an adequate understanding of the solution to be able to make an informed decision on the fitness of a Release …”

Do those five points, in the way that I have summarised them at some speed, set out the reasons why you, nonetheless, engaged in a technical assurance process?

Mr Jeremy Folkes: Yes, I think those are good.

Mr Beer: To what extent was that process necessary as a part of the route to acceptance?

Mr Jeremy Folkes: Do you mean by that that, if we had gone away for two years and come back and waited for acceptance specifications and ticked them off?

Mr Beer: Yes.

Mr Jeremy Folkes: I think we – point 4 – we needed to understand the solution to be able to inform the acceptance process. ICL Pathway had to produce acceptance specifications, ie how they were going to meet a number of these requirements. Without knowledge of the solution we couldn’t really evaluate those acceptance criteria.

If they said requirement 1, 2, 3 was going to be met by it being green, what would that mean if we didn’t understand what was underneath it?

What we were trying to do here was get to the stage where we understood enough so that acceptance could be done and that acceptance could be done, not just with the functional characteristics, which are maybe fairly easy to do, but with some of these non-functional ones.

Mr Beer: The third point is how did what you were trying to achieve here sit with ICL Pathway, given the provisions of the PFI contract and their approach to carrying them into effect on the ground?

Mr Jeremy Folkes: Badly, I think is the answer to that. We tried through these various papers and various approaches to Pathway to engage with them, both this one in 1997 and then the paper you had at the end of 1998, but I think Pathway’s approach was they were head down trying to do the job and I think they viewed us as a distraction.

Mr Beer: Can we look at your witness statement, please, WITN05970100, at page 27. You say in paragraph 80:

“Rather perversely, we did make some progress on the POCL Infrastructure side (I say perversely as you might expect that the deeper into the software stack, the furthest from the application, the more reticent they might be, but the opposite seemed true) with Pathway people providing ‘informal’ access to a document known as the TED (Technical Environment Description). This technical infrastructure area was making progress and did not expose major problems, which might explain why the people here were more open. We also had more success in the underlying Security areas, as we had a specific requirement which required Pathway to create a Security Functional Specification (SFS).”

So there you are pointing out a perversity that you are diving deep into a software stack you might expect resistance but you didn’t get it?

Mr Jeremy Folkes: Correct.

Mr Beer: Can we contrast that with what you say in paragraph 82:

“In other areas however, in particular the POCL Applications side, there was explicit refusal to allow access to design documentation for much of the time. I suspect this was largely because such documentation did not exist at the time or that it was of such quality that opening it up to us would have exposed Pathway in this area.”

What do you mean by your reference to the POCL applications side?

Mr Jeremy Folkes: So POCL applications included EPOSS, APS – the automated payment service – included BES which was the Benefit Encashment Service, which was part of the overall benefit payment service but the bit that ran on the counter, so POCL applications were those three at the time and I think NFS was added to it.

Mr Beer: You say that “explicit refusal to allow access” was what we were met with.

Mr Jeremy Folkes: Yes.

Mr Beer: What was the reason that was given for this refusal to allow access?

Mr Jeremy Folkes: I believe it was the, you know, “not appropriate under the contract”. The, what I called, the “PFI card”.

Mr Beer: You say that you suspect that this was essentially a front, is that right, because the document did not exist or was of poor quality?

Mr Jeremy Folkes: That’s what I suggest there, yes.

Mr Beer: On what basis do you hold that belief – or did you hold that belief?

Mr Jeremy Folkes: Partly because it seemed very odd that in some areas we were getting access and was very good in the areas where – for instance, the document for TED, the applications, we had more resistance. I say this, I suspect is largely because what we have learnt since, in particular around EPOSS, and what I think is backed up by certain documents that the Inquiry gave me yesterday in appendix E, that says precisely this.

Mr Beer: That the documentation didn’t exist or that it was of low quality?

Mr Jeremy Folkes: Yes, what’s in the EPOSS task force document and the CSR audit, documents the Inquiry showed me yesterday seemed to say precisely this.

Mr Beer: We will come to that this afternoon, the EPOSS, but to summarise what you are saying, you have now been shown some internal ICL Pathway analysis of difficulties that they were encountering with the EPOSS system; is that right?

Mr Jeremy Folkes: Yes. But it does mention in those documents the absence of design documentation and the fact that some documentation had to be reverse engineered from what had been written after the event, therefore wouldn’t have existed at the time that you are referring to here.

Mr Beer: Can I turn to the effect of what all of this meant, the consequences and look at paragraph 84 of your witness statement please which is over the page. You say:

“The result was that, except in areas where we had an explicit right in the Contract to a document … we only had limited or partial visibility of the emerging Pathway systems, or of their design/developmental approach. This meant that we could not gain confidence of what Pathway were creating (or its suitability or fitness for purpose) or have confidence in how Pathway were developing (and therefore have quality mechanisms were in place).”

Summarising, you say you couldn’t see what they were creating and you couldn’t, therefore, have confidence in how they were developing the system; is that right?

Mr Jeremy Folkes: Correct.

Mr Beer: You obviously knew that that was a problem at the time; is that right?

Mr Jeremy Folkes: We suspected that the – we knew that the lack of visibility we were getting was impeding our work on assurance. We obviously didn’t know what kind of outcome that was going to be. If you take the view that it was Pathway’s responsibility and it was their responsibility to have the right controls in place, you could say the effect of all that would be zero because they should have got on and done it. What we came out with though, at the end of the process in 1999, was we didn’t have evidence to have confidence in the system at that point.

Mr Beer: Just before the break then. You, I think, recorded some of this at the time. Can we look, please, at WITN05970118.

I think this is a document you wrote at the time; is that right?

Mr Jeremy Folkes: Yes.

Mr Beer: In your statement you tell us that it dates from 1998. Can you be anymore precise than that?

Mr Jeremy Folkes: I can’t at the moment without – unless it is within the – can I just check what WITN number this is?

Mr Beer: 118.

Mr Jeremy Folkes: According to page 2 it was 1 October 1998.

Mr Beer: I saw that in the index. Where did that date come from?

Mr Jeremy Folkes: That I believe was the date on the file.

Mr Beer: So the properties of the document?

Mr Jeremy Folkes: Yes.

Mr Beer: Thank you. Who was this addressed to?

Mr Jeremy Folkes: I believe this was a document I produced for discussion within the product assurance team.

Mr Beer: So who would it have gone to within the product assurance team?

Mr Jeremy Folkes: The team was led by John Meagher and there were other members of the team and I presume it would have been circulated within that team.

Mr Beer: Do you know whether the document was ever escalated above Mr Meagher?

Mr Jeremy Folkes: I presume it was discussed but I don’t know.

Mr Beer: Looking at the first section, “Assurance vs issues management”, you say:

“Our role is assurance, but up to now we’ve had very little opportunity to do more than manage issues as they come up. In the absence of Pathway’s co-operation on assurance (across the board), and the ability to engage in proper review activities – the V&V …”

What do you mean by V&V?

Mr Jeremy Folkes: Validation and verification.

Mr Beer: “… we are not going to be able to provide the ‘assurance’ that sponsors expect.

“We end up giving Pathway false credibility and doing ourselves no favours if we give the impression of assurance. Pathway see little benefit in overall assurance, they choose to involve us when it suits them but consistently fail to provide long-term access. If they refuse access, what happens – do we have any leverage? In effect we have no clout – what does ‘no assurance’ mean in the end?

“So either we have to achieve the coverage/depth that we require to provide a credible level of assurance, or we stop pretending we can do it, and revert to ‘issues management’ as our prime role.

“[A] decent level of assurance is only going to come from high level (Dave Miller and above) pressure on Pathway, as a condition of signing up to yet-another-plan, as a risk-minimisation action – the little local agreement approach is doomed.”

Does that accurately reflect how you felt at the time as part of the assurance process?

Mr Jeremy Folkes: I think it does yes. And the comment at the end, “the local agreement approach”, I think, by that, I meant us trying to talk nicely to – I think it probably would have been Terry Austin or whatever at that point – wasn’t really getting anywhere. That’s the only way we were going to move this forward is if we had, actually, support from the top of the programme.

Mr Beer: That is referred to in some of the documentation and in your witness statement as “informal access to information” and “informal access to some documents”; is that right? The little local agreement?

Mr Jeremy Folkes: In some cases, and in particular on the more technical side, we did get, for instance, informal access to this document called the TED. What I would have wanted at that point was a controlled copy of the TED, so if it got updated that we saw those updates. There is not much point in assuring a document and it changing six months later.

What the little local agreement approach is saying is, that for some documents we just did not get access and that continuing to apply pressure doesn’t – wasn’t going to give us what we needed at that level.

Mr Beer: After lunch can we turn to what the little local agreement and the informal access was showing you.

Is that an appropriate moment, sir?

Sir Wyn Williams: 2.10 pm all right with everyone?

Mr Beer: Yes. Thank you very much, sir. You should give Mr Folkes the warning.

Sir Wyn Williams: I am sure you are aware of it but you shouldn’t discuss your evidence with anyone over lunch. I imagine it is the last thing you want to do anyway.

Mr Jeremy Folkes: Correct.

Sir Wyn Williams: I will see you at 2.10 pm.

Mr Jeremy Folkes: Thank you.

(1.08 pm)

(The short adjournment)

(2.07 pm)

Mr Beer: Good afternoon, Mr Folkes. We were, before lunch, looking at what you describe in your witness statement and in some of the contemporaneous documents as informal access to some information and some documents that ICL Pathway allowed you to see.

Can I look at some examples of that please. If we turn up, please, WITN05970143.

If we just look at the top of the page, we can see that this is a fortnightly report from you to Mr Meagher; is that right?

Mr Jeremy Folkes: Yes.

Mr Beer: Did you produce these on a fortnightly basis?

Mr Jeremy Folkes: Yes, or thereabouts.

Mr Beer: What was the purpose of them?

Mr Jeremy Folkes: John was leading the product assurance area, so it was fortnightly reporting of progress and issues. At this point, I was doing work for two people, for John and for Gareth Lewis, who headed up the fault and security group on the programme for BA, and so I was splitting my time between the two. So it was also just trying to justify, if you like, what time I was spending for each of the two bosses I had.

Mr Beer: At this stage, what was Mr Meagher’s position?

Mr Jeremy Folkes: I think the group at that point was called design assurance, and so he was, I think, manager of design assurance, it may not be quite the right name but that was the gist of his role.

Mr Beer: Was he next up the chain from you?

Mr Jeremy Folkes: Yes.

Mr Beer: Do you know what happened to these reports?

Mr Jeremy Folkes: I presume that key issues from them were then fed further up the chain.

Mr Beer: By “further up the chain”, where do you mean?

Mr Jeremy Folkes: I presume, I’m just trying to work out what the structure would have been at that point, but to either the programme director or the deputy programme director at that point.

Mr Beer: So Mr Miller?

Mr Jeremy Folkes: At that point in 1998 may have still been a Benefits Agency – Peter Crahan, I think, was the programme director at that point.

Mr Beer: Could we look at the foot of the page, please, under paragraph 3. You say:

“Current Issues and Concerns

“Testing/Acceptance: documentation from PDA Testing at Borough …”

Does that mean Borough, the place in London?

Mr Jeremy Folkes: Okay, the Post Office had a site, I think it was like an industrial unit or warehouse, that was used for test equipment and that was at Borough.

Mr Beer: Ie the place in London?

Mr Jeremy Folkes: Yes.

Mr Beer: “… re Model Office and End to End …”

Can you explain briefly what “Model Office” and what “End to End” are?

Mr Jeremy Folkes: These were two different test phases or test activities. “Model Office” was actually trying to operate a post office, presumably you would have had two or three terminals and tried to do real transactions and look at the processing within the operating environment. “End to End” would have been trying to look at the process from transactions being performed in the office and then feeding all the way up through the central systems and onwards to, I presume, TIP or to the relevant Benefits Agency systems.

Mr Beer: But:

“… still steadfastly ignoring anything to do with Acceptance. Hopefully will be some change of direction following the ‘week long workshop’ this week, given Mary’s involvement.”

Who was Mary?

Mr Jeremy Folkes: Mary was a – I can’t remember her surname – but I believe she was a contractor, probably from PA, who was working for the programme and I think she was working at testing. What this is, is actually probably more of a, sort of, internal issue, regarding – those two test scripts done at Borough were trying to put together tests.

My concern was these may have been valid tests to test the functionality of the system but they weren’t tied in, in any way, with what was going to need to happen with regards to acceptance. Given the big hurdle we knew was going to happen – obviously at this point we thought it was going to happen sooner than 1999 – but the big hurdle that the programme needed to get through would be acceptance, we were looking at how testing and acceptance would work together.

Mr Beer: Thank you. The next bullet point:

“Release 2 and Acceptance: Given the nature of the hangouts for Nile 2, a significant number of acceptance criteria (eg for security) are likely to be ‘unacceptable’ until a subsequent release. Are we content that we understand the contractual and other implications (eg re OP Trial, Rollout, etc) of ‘partial acceptance’.”

Can you explain to us what you meant by that bullet point?

Mr Jeremy Folkes: Nile 2 was the name of release, in the same way that we had releases called Congo, which I think were – the initial trial was a release called Congo. I am not quite sure what the release called Nile was but it was obviously the release that was coming up at about that time of a wider system. The concern there was that a number of the acceptance criteria that we had around security, weren’t actually going to be satisfied by Nile or Nile release 2, because Nile release 2 had been pared down.

Therefore, the question I’m asking is, if we go ahead and do Nile 2, that may be a sensible process to go through to iteratively get some functionality going but, if it didn’t prove the acceptance criteria, we would not be able to give them acceptance. So we needed to, as a programme, have a joined-up approach as to whether we were giving them partial acceptance, whether we were giving some sort of acceptance that it needed to be then rerun or, for the purposes of Nile, we were not giving acceptance at all.

Mr Beer: I understand. Then if we scroll down there are three bullet points that are all to do with EPOSS. I want to concentrate on those, please.

The first of them:

“EPOSS – application: Evidence emerging from the EPOSS workshops that the emerging product is likely to be non-conformant in a number of areas, and will miss the (possibly unwritten) business rules in a large number of areas. The product does not appear to be at the stage one would expect given the closeness to its entry to a testing phase – Pathway admitted to several ‘holes’ where they don’t yet have a solution (eg Cash Account).”

Just dealing with that first bullet point. How serious an issue was that?

Mr Jeremy Folkes: Well, I would view that extremely serious because EPOSS is one of the core parts of the system. As background to this, at about this time we did attend a series of workshops that were put together by the POCL applications team with Pathway. I attended those from a technical perspective. These were workshops to take the programme people through the emerging EPOSS application. This was kind of being done, “Given we didn’t get any documentation at this point, then show us the thing and let us work through it”.

It is obviously not a particularly good way of reviewing it but it was an important thing to do. We went through it and found there was some functionality that the relevant experts we got in there from POCL basically thought was non-conformant and, in some cases, didn’t appear to meet the business rules they were expecting.

I think in the possibly unwritten bit I put in there is there was an issue with the detail of the requirements, partly, I think, because of the whole issue we talked about before lunch, about the level of requirements. POCL did put in experts to try and help Pathway with some of the business functionality around EPOSS, in particular. So they may have helped them in sort of joint working but they may not necessarily have been written down business rules at that point.

Mr Beer: What does the reference to the “cash account” mean?

Mr Jeremy Folkes: Okay. So, the core – the key output that every office produced every week was a document called the cash account. It was a fairly complex document every office had to produce. I have got one here if you want to see it but it was a key financial report that went off to the centre, got keyed by Chesterfield and then was used for a whole series of purposes by the centre.

EPOSS was meant to effectively replace the cash account by initially electronically producing the cash account. I think, originally, it was going to electronically produce and feed to TIP but also print for signature and then, eventually, they would dispense with the paper copy.

So the cash account was the key financial report coming out of the office. It had a whole series of steps that were needed to create the cash account that was done manually that every – you know, 20,000 subpostmasters knew how to do manually, and this had to be replicated by EPOSS.

Mr Beer: You were saying that Pathway were admitting that they didn’t have a solution to the creation of the replacement for the cash account document?

Mr Jeremy Folkes: Yes.

Mr Beer: Was that issue resolved subsequently to your satisfaction?

Mr Jeremy Folkes: It was an issue that was resolved in that, yes, they did move on and were able to produce a cash account and the system couldn’t have gone live if we couldn’t. To my satisfaction? Because this was in the application area, I was sort of trying to pull together the things we were finding. That wasn’t actually one that I was responsible for chasing through. So I can’t say I went back and spent the next six months working on the cash account.

Yes, I believe it did get resolved but what was of concern to us, at the date of this document, which was –

Mr Beer: January 1998.

Mr Jeremy Folkes: Which was meant to be fairly near to when we were getting into detailed testing, but not be able to create the core accounting document out of the system, at that point, didn’t bode well.

Mr Beer: The next bullet point on EPOSS:

“EPOSS – design approach: Very concerned about Pathway’s (apparent) design approach for EPOSS, which is totally inappropriate for an application of this complexity – appears to be based on reverse engineering a product which has been cobbled together first by someone who is no longer with Pathway (and left little documentation) and since by Escher. This is a very dangerous approach for a product of this nature and importance, and I do not believe that the risk can be adequately mitigated through testing alone.”

First of all, some of the words that you use there, “very concerned”, “totally inappropriate” and “very dangerous”; that’s quite strong language.

Mr Jeremy Folkes: It is.

Mr Beer: Why did you use such strong language?

Mr Jeremy Folkes: So EPOSS was the core part of the system that was providing the accounting, providing the creation of the cash account and everything that went before it in that process, and was the key document where a subpostmaster or branch manager would report to the centre what they had. So it was fundamental to POCL operating and being able to account for the business and the money in its network.

EPOSS is fairly complicated. I saw Mr Cipione’s report and I felt is kind of underplayed a bit the complexity. It is more than just a POS system. Because of the sheer complexity, there are 170/180 different products that you could transact – different product types you could transact at a post office, each one has subtly different ways of being accounted for, the cash account form is complicated.

It is a complex piece of software and, in my view, it needed to be properly analysed and designed. It wasn’t something that should be just, sort of, put together from the user interface side or – I see the use of RAD, rapid application development, was talked about. There were some bits of software which are suitable for that kind of approach and others which aren’t.

Mr Beer: Which was this?

Mr Jeremy Folkes: Totally unsuitable for the – emotive language, “cobbled together” – but totally unsuitable to try and put it together and write up design documentation afterwards. Can I just say, I had, in a previous life, been technical manager on the ECCO projects, which was to create the – effectively, the EPOSS project which was used in branch offices for a number of years. So I was aware – I’m talking with some knowledge of the complexity of actually trying to automate that process.

Mr Beer: Is what you are describing in this bullet point the kind of run-of-the-mill issue that one might reasonably expect to see in the development of any large IT system?

Mr Jeremy Folkes: I would certainly hope not, because I would hope that anybody developing a large IT system would use the appropriate design approach for the complexity and importance of the piece of software they are producing.

Mr Beer: Are you raising here a fundamental issue about the competence and ability of your contractors?

Mr Jeremy Folkes: I probably can’t answer no to that. I think I am, yes.

Mr Beer: What was done about it?

Mr Jeremy Folkes: There were various approaches that we – that were taken within the programme, as far as joint working with them, as far as trying to get hold of design documentation, et cetera. I think our concern was that we were finding this stuff out, finding out the stage of the product, by doing this review very late in the day, not through reading their own design documentation. Some of what we were finding out here was from, if you like, rumour or what people said in unguarded moments, rather than by official channels.

But, you know, this was reported up. I think it is now – seems to be backed up by other evidence that I have seen in the past 24 hours that I hadn’t seen at the time. I don’t personally know what pressure was applied to Pathway or what was taken forward to Pathway at this point.

Mr Beer: When you refer to having seen documents backing this up in the past 24 hours, are you referring in particular – we will come to the document in a moment – to ICL Pathway’s internal report on the EPOSS PinICL Task Force?

Mr Jeremy Folkes: Yes, and also on the CSR+ audit, which echos some of the findings from it.

Mr Beer: You refer in this document, in the second bullet point, to the application appearing to be based on reverse engineering. You say “appears to be based”; on what was that founded?

Mr Jeremy Folkes: I think it was founded on formal questioning of the team during these workshops. So these workshops were held, I was one of the people attending these workshops. We had obviously up to then trying to get hold of design documentation. We had been denied it possibly because it didn’t exist. We then went into these meetings. There were questions that we would have asked through these two or three workshops and we would have been asking them these questions of some of the staff who were there on the ground, who would have given us possibly less guarded answers than management.

Mr Beer: What’s the problem with reverse engineering this product?

Mr Jeremy Folkes: Well, what you have got here is a complex requirement. It’s got strong requirements for integrity and reliability, obviously because it is handling the accounting in the office. It’s got to be able to function reliably under hostile conditions, et cetera.

What we found out, I think, by talking to people there, was that they had started putting a product together, they had had – it was unsuccessful. We knew, I think, that one of their developers who worked on it had left. They then tried to do further work on it. They shipped it over to Escher in Boston to, we were told, complete it. I think “complete” probably meant a lot of rewriting. It had then come back again and then, from what it says here, it appears that then they tried to do more major work on it, reverse engineering what they had already got.

It is just not the way that you would want/expect a product that is this mission critical to be produced.

Mr Beer: Can we turn to the third bullet point, please:

“EPOSS – failure conditions: Significant concerns re operation of EPOSS – and the office platform in general – during ‘everyday’ failure conditions, such as loss of a terminal or LAN …”

Local Area Network?

Mr Jeremy Folkes: Yes.

Mr Beer: “… connectivity, but similar issues likely to emerge in non-failure conditions with shared stock units. Pathway’s problem is basically that Riposte gives high integrity for data held on a ‘per terminal’ basis – whereas the business requirement is for data to be accounted for on a ‘per SU …”

Stock Unit?

Mr Jeremy Folkes: Yes.

Mr Beer: “… basis; they need to build the integrity for the latter using the facilities provided by the former. Trying to meet this need without a rigorous design method, and without proper failure analysis, is unlikely to succeed. Pathway appear not to understand the business impacts of failure of the accounting process (as opposed to failure of a transaction) and appear to want to rely on the ‘it’s not going to happen’ philosophy (Same may be true of other applications, given Release 1c experience, but have less visibility).”

Can you explain what you meant by the distinction that’s drawn in this paragraph between a per terminal and a per stock unit accounting approach?

Mr Jeremy Folkes: Okay. So, per terminal, each counter position in the office had its own counter terminal, which has its own, in Pathway’s solution, software with Riposte, a message server, which – message storage – holds the data. That’s fairly easy.

However, what happened in post offices is post offices are organised on a per stock unit basis where “stock unit” generally meant the till drawer. The best way of thinking of a stock unit is a till drawer. So, if you were working in a post office and you were working on position 1 in the morning, you would go and get your till drawer out of the safe, go to position 1, work on it there. That’s what you are responsible for. Your stock unit.

If, in the afternoon, you are in position 3, you take the same drawer to position 3 and work on it there. At the end of the day or the end of the week, you want to account for and balance your stock unit and some of your stock units would have been done on terminal 1, some on terminal 3, some somewhere else.

So the challenge here was to come up with an ability to reliably – and there may be failures, for instance the network, et cetera – come up with a reliable way in which you could actually balance stock units and account for stock unit data where somebody has moved around within the office.

If everybody sat on the same terminal all the time, it would be much easier. But they don’t because post offices need the flexibility, multiple positional offices need the flexibility of staff to be able to move around.

Mr Beer: Thank you. You say:

“Pathway appear not to understand the business impact of failure of the accounting process … and appear to want to rely on the ‘it’s not going to happen’ philosophy.”

You say in your witness statement that, by this, you meant that ICL Pathway didn’t demonstrate an understanding of the importance of the accounting role of EPOSS, including the balancing of cash and stock in each Post Office; is that right?

Mr Jeremy Folkes: That’s what I meant, yes. If I can just say, the distinction here is, when we spoke to them they understood the problems if a single transaction failed. So if you were in the middle of paying a bill and that bill – say the power went off or something went wrong during that particular transaction, they were – seemed to be understanding that they needed to tidy up that situation. But less concerned around failure of the underlying accounting.

For instance if somebody had, say, worked on this position then that position then this position and then something had gone down. When we tried to challenge them, the impression that I got, what I wrote here, is they were keener to do the, “it’s not going to happen”, rather than to provide us with an explanation of how it was going to be solved.

Mr Beer: In writing this had you got in mind any difficulties being caused for subpostmasters being able, accurately, to account for their stock and cash at the end of an accounting period?

Mr Jeremy Folkes: Well, yes because that’s the whole purpose of EPOSS is for subpostmasters and managers to be able to account for the business and then report that back to the centre.

Mr Beer: So in a sense describing one of the very issues that this Inquiry is inquiring into?

Mr Jeremy Folkes: Yes, at this point Pathway did not demonstrate, to us, an understanding of this kind of failure condition or how they were going to solve it. Other people may have solved it but certainly, to us as part of this piece of work, they hadn’t demonstrated it to us. I don’t know whether this particular example is one of the problems which has hit downstream or not but the point I’m making here is they didn’t – we wanted to be able to have proof that they had considered these failure conditions and – because we knew that such failure conditions were going to happen.

Mr Beer: You refer to a preference to relying on the “it’s not going to happen” philosophy; how was that expressed to you?

Mr Jeremy Folkes: I can’t remember the exact words but it would be – I think what I meant by that was – if we said “what happens if, for instance, the network breaks into two halves?” Say you have a large office, depending on how the local area network in the office is configured, you could end up with two half networks. That depends on how the networks are put together. That may not happen very often, it may only happen in a large number of offices but it still could happen. Therefore, we wanted to ensure that they had taken these things into account or shown us why they weren’t going to happen, what we were seeing here – and it mirrors, to a certain extent, what we found during the demonstrator that they were – rather than showing they had addressed it they preferred to deny it was going to happen.

Mr Beer: You expressed a view there that you wanted your concerns listened to and acted upon by ICL Pathway. In fact, at this time, was there a proposal that contractual acceptance be changed and tied to authorisation being given for NR2, new release 2?

Mr Jeremy Folkes: Yes, I believe there was.

Mr Beer: Can you just explain to us what “contractual acceptance” meant?

Mr Jeremy Folkes: Contractual acceptance was important because it basically would have said we were happy with the system and I think it was important to Pathway because it unlocked a major payment. I can’t quite remember what it was. But it was important from a financial point of view. Maybe at this point, because it was still PFI, it didn’t do that. Acceptance was basically …

Mr Beer: I think there were a series of stage payments?

Mr Jeremy Folkes: It was important for Fujitsu to be able to achieve acceptance and then acceptance would then be able to initiate the rollout and obviously then the rollout of the system and that moved us to the next stage and income stream.

What there appeared to be –

Mr Beer: Sorry to interrupt you. This document can come down.

Mr Jeremy Folkes: What I believe you are referring to, if there was a proposal that rather than having a formal acceptance activity, that they would tie it, acceptance, to the authorisation of a specific release which I think was then called NR2.

Mr Beer: What was NR2?

Mr Jeremy Folkes: It was another – it wasn’t a full – it wasn’t the final release. I guess the key point here is, if you wanted to accept you might want to accept on the final thing you had and the proposal that came forward was that we would actually – acceptance would be tied to the release authorisation of new release 2, which was a not-final release.

Mr Beer: I think you wrote a note setting out your opposition to that or outlining the dangers of ICL Pathway’s proposal to tie contractual acceptance and the payment of money to them, to a release of NR2?

Mr Jeremy Folkes: I did.

Mr Beer: Can we look at that, please, at WITN05970119.

This is a single page document authored by you. You say in your witness statement that you thought ICL Pathway’s proposal was not a good idea and then you reduce your thoughts to writing. This was in 1998. Can you again assist us with the date on this.

Mr Jeremy Folkes: Have I dated it at the bottom of the –

Mr Beer: No, it is a single-page document. If we scroll to the bottom you can’t see a date.

Document 119?

Mr Jeremy Folkes: Acceptance. It seems to be 12 October 1998.

Mr Beer: Thank you. Again, was that taken from the properties?

Mr Jeremy Folkes: That was taken from the properties, yes.

Mr Beer: Thank you. If we just read it. You wrote:

“A suggestion has emerged that Contractual Acceptance could be given at New Release 2 Release Authorisation, rather than waiting [for] the completion of the formal acceptance process. This note seeks to outline likely dangers in this approach.”

In the first bullet point you say:

“The only contractual right that the sponsors have to obtain any assurance that the ICL Pathway service will [meet] the contract is via the Acceptance process. Assurance [without] acceptance is not supported by the contract and has, to date, been only of limited effectiveness due to the reluctance of ICL Pathway to provide access to the detail of their solution. This situation has only been sustainable on the basis that the Acceptance process would provide a backstop for assurance.

Then skipping over the next one.

“Although a number of the tests used in the Acceptance trials may already have been run in some form … many of the Acceptance Reviews will not have taken place before the Release Authorisation Board has sat. A large number of deliverables cited for Acceptance Review have yet been made available to Horizon, as these are scheduled to be produced during the Operational Trial.

Then:

“The current approach will provide assurance to the Release Authorisation Board that the associated ‘functionality’ will work however it will not prove the service deliverability.”

Then:

“Conclusion. The current Acceptance Process acts as a safety net for the Contracting Authorities, offering a level of protection from having to accept and rollout an inadequate service. We believe it would be very dangerous to accept any proposal which would remove the protection offered by the Acceptance process.”

Can you help us who this document was addressed to and seen by?

Mr Jeremy Folkes: I obviously wrote it in a hurry because there are a couple of typos in it. I can’t remember who I was asked to produce it for. But the same document has been disclosed back to me by the Inquiry with a handwritten draft in the top right-hand corner so I know it reached somewhere up in the echelons of the PDA as it would have been at that point.

Mr Beer: The programme delivery authority?

Mr Jeremy Folkes: Yes. I presume it would have gone into the contracts team or those who were negotiating around the contract with Pathway at that point. I presume it would have been at the level of the programme director or immediately below.

Mr Beer: Can you recall what happened as a result of submitting this paper?

Mr Jeremy Folkes: I’m a little confused when I go and look at what was then agreed.

Mr Beer: Ie, in the acceptance board minutes?

Mr Jeremy Folkes: Yes, as to how it came out. I believe this paper reached the right people but from what I understood the toned down version – the acceptance board minutes may have been – the process may have been changed contrary to this advice.

Mr Beer: Can I turn to a new topic then please. The Project Mentors’ report, can we turn up page 39 of your witness statement please. WITN05970100 at page 39. You say in 114:

“There was a review performed of the programme by Bird & Bird … “

I’m going to skip what’s in brackets given your correction earlier:

“… and a consultancy called ‘Project Mentors’ in March 1998, for which I believe I was interviewed.”

You refer to an exhibit which you exhibit as your 32nd document.

Then in 115, you say:

“I can’t remember seeing the report at the time it was produced, but was invited to comment on it by POCL management in January 1999 and largely supported its findings. My notes from reviewing the report are presented as … “

Then you describe them and exhibit those as your 33rd exhibit.

Can we just look at your note to start with then, please. WITN95970121, thank you.

If you just look at your notes. They are said to be prepared in contemplation of litigation at the top right?

Mr Jeremy Folkes: I put that on there just because the document I had been sent had that on and I –

Mr Beer: I was going to ask you why?

Mr Jeremy Folkes: I was probably being lazy with the same marking, as it were.

Mr Beer: If we scroll down, I don’t think there is a date on them but I think in your statement you date them as being from January 1999?

Mr Jeremy Folkes: Yes.

Mr Beer: Then if we just scroll back up again please at the notes and look at the first bullet point, there is a quotation in italics:

“‘Effective business requirement analysis is required to achieve …’”

Was that a quote from the report?

Mr Jeremy Folkes: Yes.

Mr Beer: And then you are commenting on it underneath?

Mr Jeremy Folkes: Yes.

Mr Beer: We can see the way that it continues in the second and third bullet point with an italicised quote and then some comments by you.

None of those italicised comments appear in the March 98-version of the Project Mentors’ report. I wonder whether we could instead look, at the same time as looking at this document, at POL 00038829 and then skip to page 9.

If you just scroll down a little bit. We can see this is a 17 December 1998 version of the Project Mentors’ report. Then if we scroll forwards please to page 11.

Then scroll to 1.3 on the right-hand side. Can you see a sentence under “Scope”:

“Effective business requirements analysis is needed to achieve a satisfactory, comprehensive business design. This can then be used as the basis for …”

Now, give or take a word or two, that matches what you have written on the left-hand side?

Mr Jeremy Folkes: My apologies, I may be referencing the wrong document.

Mr Beer: I wanted to establish whether that was so. Drawing those threads together, it looks like your notes on the left are a commentary on or a response to the December 1998 Project Mentors’ report, rather than the earlier March 1998 version; would that appear to be correct?

Mr Jeremy Folkes: It does appear like that, yes. I don’t think I was necessarily aware there were two Project Mentors’ reports. I seem to have got them muddled up.

Mr Beer: Can we get to the substance of what Project Mentors said then, and go to page 13 in the document on the right-hand side, and look at the conclusions. We can lose the document on the left-hand side to make it easier to read please:

“It must be remembered that so far we have only performed the requirements analysis for BPS …”

BPS is?

Mr Jeremy Folkes: Benefit Payment Service, which was the overall name for both the BA and the POCL parts of the benefit payment.

Mr Beer: “… which is predominantly a BA system element. However, from our analysis we conclude that Pathway made no attempt to undertake requirements analysis in accordance with normal industry practice. This [is] despite their having access to the SSR and subsequent requirements since April 1996. Much of this work could, and should, have been done during the demonstrator period.”

I think that’s a conclusion that you agree with.

Mr Jeremy Folkes: This is referring to the BPS and I didn’t have a great deal of involvement with the BPS but I think the general point about doing requirements analysis I agree with. The only point I might disagree with is how much of that work they should have done during the demonstrator period because at that point, of course, there was still three service providers and so I think you would only expect them to go to a certain point before award of contract. Having got an award of contract you then expect them to go in heavy to do the main detailed requirement work.

Mr Beer: Thank you, and then over the page, please. Then, under 2.3.4, “Other Elements of the System”, they say:

“While we have so far only completed work on the BPS system element, we have grave concerns that the same lack of professional analysis will be apparent in other areas as we come to review them. This concern is supported by a number of interviews with Authorities’ staff, from which it is apparent that Pathway are loath to release design documents to BA/POCL. While they have on occasion cited Intellectual Property Rights as a reason for refusal, we are becoming increasingly suspicious that the real reason is that the right level of documentation simply has not been developed.”

Was that a conclusion that you agreed with?

Mr Jeremy Folkes: I would, yes.

Mr Beer: Were you one of the people that were interviewed that said that to Project Mentors?

Mr Jeremy Folkes: I can’t remember whether I was interviewed for this specific report. As I say, I’m confused between the fact that there were two different Project Mentors activities. So I couldn’t be certain I was interviewed for this one.

Mr Beer: The next paragraph:

“Of particular concern is the EPOSS system. We are informed that at a relatively early stage Pathway wanted the Authorities, principally POCL, to be involved with the design of this element. The plan was to use the Rapid Application Development (‘RAD’) methodology to design this system. This approach was started, but discontinued after some months, when the Pathway staff member involved left the project. The suggestion to use RAD leads us to believe that more traditional methods have not been used, and since the RAD experiment was abandoned, we have doubts whether any proper requirements analysis has been performed.”

Did you know about what’s described in that paragraph?

Mr Jeremy Folkes: Yes, in that we knew that they had – they wanted to take this RAD approach and we knew the Pathway staff member leaving. That was in my report that we saw a few minutes ago.

Mr Beer: Lastly, “Impacts on the Programme in the Future”. They say:

“Our experience of systems where requirements have not been analysed satisfactorily is that the system fails to meet the users’ needs. An effective acceptance test will identify many such failings necessitating considerable rework. The result is a significant extension of time and cost required to complete the system and roll it out. The alternative is to allow unacceptable processing in the operational environment, with unpredictable and potentially damaging results.

“In our opinion the failure to satisfactorily analyse the requirements for the Benefits Agency makes it unlikely that the users’ needs will be met by the current and Pathway system.”

Was that a conclusion with which you agreed at the time?

Mr Jeremy Folkes: Yes.

Mr Beer: Can we look at your notes please, WITN05970121. You say at the top:

“We have no evidence to disagree with the underlying message in this report.”

Who is the “we” in that sentence?

Mr Jeremy Folkes: I believe I discussed this with other members of the assurance team, that may have included John Meagher, it may have included a couple of the Benefits Agency people who were involved at the time as well.

Mr Beer: Can we look, please, at a couple of the points that you made. The second bullet point from the bottom:

“Our view over the past 2+ years of experiencing Pathway development has been:

“Horizon denied visibility, especially of application design (oddly, we have managed to get some visibility of the ‘risk areas’ such as the Riposte middleware).

“no opportunity for Horizon to perform independent [verification and valuation]

“no evidence that Pathway have performed a [verification and validation].”

Those two points there, do you, by putting the symbol to the left of them, mean that the result of what you describe is that?

Mr Jeremy Folkes: Yes.

Mr Beer: What do you mean by this bullet point as a whole?

Mr Jeremy Folkes: Basically the same message as discussed earlier that we, Horizon, as in the BA/POCL team had been denied visibility of the application design. When I say we had some visibility of the risk areas, what I mean by that is the areas where we had raised formal risks to the service provider risk creditor at the start, such as Riposte.

In those cases, we did get more information but as far as the application design, in particular for EPOSS, we had been denied visibility. Therefore, we had no opportunity for the programme staff to independently go through the design and validate it against the requirements.

What was maybe of more concern there is that, if they didn’t have design documentation at that point, then how could they have done it? Bearing in mind it wasn’t our job to do it, if you like; it was their job to do it and us to try and get content that they had done it. That’s not, in any way attempting to duck it but they were the people in the PFI contract who were doing this. If they didn’t have the design documentation, then, how could they assure the integrity and correct operation of components such as EPOSS.

Mr Beer: Can we go over the page, please, and look at the first full bullet point:

“Pathway adopting a ‘end of pipe’ approach to quality and performance – a ‘fix on fail’ in testing approach, rather than putting in the effort to get it right first time.”

“End of pipe” approach?

Mr Jeremy Folkes: By that I meant – that’s a term I’ve used elsewhere in IT. It means rather than trying to do it right all the way through the process, through a formal process of requirements, and then design, and then having all the quality processes in place; it was more getting to the end and then –

Mr Beer: See what flows out of the pipe?

Mr Jeremy Folkes: Yes, and the “fix on fail” is something that we actually commented on during the acceptance process as well, where our concern was that there was a process of “Oh, here’s another bug, we will go and fix it”, rather than going back and looking at the fundamental problems that led to that point.

Mr Beer: I understand an “end of pipe” approach to be an approach to the treatment of waste that concentrates on treating or filtering the effluent, I will call it, that flows from a pipe, as opposed to making changes to the processes that give rise to the effluent; is that a fair way of describing it?

Mr Jeremy Folkes: It is not one I have heard of before but I can see the analogy, yes.

Mr Beer: Does that fit with what you were describing here as Pathway’s “end of pipe” approach?

Mr Jeremy Folkes: It fits from the point of view that what we were seeing from what they had exposed to us, they weren’t – the effort wasn’t being successfully deployed to get quality performance, and whatever, right during the development process. It was a matter, at the end of the pipe, when the product came out of the end of the pipe, of then if there were problems, then fixing it – fixing the individual problems.

Mr Beer: I understand, thank you very much.

Then can we look at the last bullet point on the page, please:

“Pathway [you say] have generally shown an inability or unwillingness to understand or recognise the complete requirements set – [see] the failure to follow the (contracted) security standards, some whole requirements missed (eg timeout back at R1c) etc. Have tended to think they can develop a system without being bothered by the detailed requirements or their meaning. Failure to use the ‘clarification’ [methods].”

What did you mean by that last bullet point?

Mr Jeremy Folkes: We had in place processes so that Pathway could bounce questions back to the PDA or back to Horizon, in particular on the application side, we had, at one point, teams actually working in Feltham with Pathway, team not of technical people but of business people, so that people could be asked and they could have real access to the business experts.

And certainly, at certain points in the process, there didn’t seem to be the level of clarifications or questions coming. They wanted to get on and, in the aforementioned black box, get on with developing it.

Mr Beer: In this document and some of the ones we have looked at before, there has been mention of the EPOSS and you told us a moment ago how critical the EPOSS was to this system. Did you have any knowledge of the EPOSS task force created or appointed by Terry Austin?

Mr Jeremy Folkes: At the time, no, I don’t believe I did. That is not to say that there may not have been people working in Feltham who did. Subsequently to leaving Post Office and moving on, I have spoken to people who were involved with Pathway at the time who – on an informal, over a pint basis – who did indicate there was a time when Pathway did pile almost as many people as they could get into EPOSS to try and fix issues and the feedback I got on that it wasn’t that successful, they seem to be introducing as many issues as they were fixing because of the state of the code and because of the absence of design.

So you can pile – you can put people who may be good but don’t understand an area of code, they will maybe fix one bug and introduce another one. I didn’t know it as a task force, less complimentary terms have been used to describe it. I knew they had – subsequently, I had known they had piled people onto it.

Mr Beer: I think it follows that you weren’t told of the work of or the conclusions of the task force at the time that it was undertaking its work?

Mr Jeremy Folkes: Correct.

Mr Beer: Were you aware of any recommendations in 1998, 1999 or, indeed, 2000 circulating within ICL that a rewrite or redesign of EPOSS should be undertaken?

Mr Jeremy Folkes: No.

Mr Beer: I think, as you have told us already, you have recently been shown by the Inquiry a report on the EPOSS task force. I wonder whether we could look at that, please. It’s FUJ00080690.

Is this the document that you referred to before and after lunch –

Mr Jeremy Folkes: Yes.

Mr Beer: – as having seen recently – yesterday in fact. Does it follow that you were not informed of the existence or the contents of this 20-page report back in 1998, 1999 or 2000?

Mr Jeremy Folkes: Correct.

Mr Beer: Ignore the date on the top right-hand side, 14/05/01, we think that is an artifact of unknown origin. You will see the abstract describes the report as describing the activities of the EPOSS PinICL task force “which was in place between 19 August and 18 September 1998 to reduce to manageable levels the EPOSS PinICLs outstanding at that time”.

In terms of the individuals that are mentioned on the distribution list there, can you help us as to your understanding of the roles they were performing at, say, September 1998, and Mr Austin?

Mr Jeremy Folkes: Terry Austin was, I think, development director or development manager. He was, I believe, responsible overall for the software development. “M Bennett” would have been Martyn Bennett, who was the director of risk and security. Jan Holmes –

Mr Beer: Just before you move on, D McDonnell, did you know – we know him to be David McDonnell.

Mr Jeremy Folkes: No, I didn’t come across him.

Mr Beer: Library, obviously, is not a person but either a physical or an electronic repository. “Author: Jan Holmes”?

Mr Jeremy Folkes: I don’t know if I ever met Jan but I believe he was the audit manager or some quality and audit role, I think probably working to Martyn Bennett.

Mr Beer: Thank you. Before we look into a couple of parts of the report, what was your overall reaction when this report was revealed to you?

Mr Jeremy Folkes: Kind of annoyance and frustration because, if we had understood everything that was in here, both from the background and from what they did and what didn’t happen, I think it would have changed my attitude to what we were doing.

EPOSS wasn’t mine as such but if I had seen this, I would imagine it would have been a subject of major discussion in the PDA and the Horizon programme and I think it would have had a major effect to what happened one year later.

Mr Beer: What major effect may it have had a year later?

Mr Jeremy Folkes: I think it may have made it far harder for acceptance to have gone through. I think we would have – I think if we had known this, there would have been more pressure on – potentially to either do something to understand better the state of the products at the point that it moved from PFI to non-PFI and the BA left. I do think that was maybe a missed opportunity. But I think if we had known the state here, then, it would have been much more evidence to a more cautious approach to what happened in 1999.

Mr Beer: Can I take you to a couple of passages just before the break, please. Look at page 6, please. You have read this recently if there are any other parts you want to draw to the Chair’s attention, then do tell us, but if we scroll down to “EPOSS Documentation (Section 7.1)”:

“The document suite supporting the EPOSS product consists of there main elements …”

They are listed:

“All of these were developed by reverse engineering the EPOSS product code at that time. What’s the effect or meaning of that passage in the report to you?

Mr Jeremy Folkes: That tells me that design documents, high level and low level design documents, could not have existed, otherwise you wouldn’t go and reverse engineer documents after you had written the code. So that tells me that the EPOSS product code had been written before there was design documentation.

Mr Beer: So the suspicion that you had about withholding material was correct?

Mr Jeremy Folkes: This backs up the fact that it was withheld in this area because it either didn’t exist or didn’t exist in a good enough form to give us and if they said “Oh, we haven’t got any – we have got to go up and re-engineer it”, it would have raised alarm bells.

Mr Beer: Over the page to page 7, please. Under “EPOSS Code (Section 7.2)”:

“It is clear that senior members of the Task Force are extremely concerned about the quality of code in the EPOSS product.”

Just stopping there. Senior members of the task force, do you understand that to be referring to ICL itself?

Mr Jeremy Folkes: Yes, I presume those were the most senior members of the group of half a dozen, or whatever, that they brought in for this task force.

Mr Beer: “Earlier this year the EPOSS code was re-engineered by Escher and the expectation is that the work carried out in Boston was to a high standard and of good quality. Since then many hundreds of PinICL fixes have been applied to the code and the fear is that code decay will, assuming it hasn’t already, cause the product to become unstable. This presents a situation where there is no guarantee that a PinICL fix or additional functionality can be made without adversely affecting another part of the system.”

Was that something that you knew about at the time?

Mr Jeremy Folkes: We knew that the EPOSS code had had a trip to Boston, we were told, for completion. The rest of that, about the state of the code and fears around code decay or whatever, no. Again, if we had known the EPOSS product was in that state, I think the project would have taken a totally different path.

Mr Beer: Page 15, please. Scroll down, please. 7.1.1, under “Documentation Suite”.

“The EPOSS product was originally developed using RAD techniques as part of the Joint Working Agreement in force during Release 1. This approach carries a number of attendant risks, not least of which is the lack of formal specification. During 1997 the product was sent to Escher for significant rework as the solution arrived at via RAD was deemed not to provide sufficient integrity.”

Is that the same point?

Mr Jeremy Folkes: That is the point that if you don’t go through the design process then, for something that is as complex and critical as this, it is unlikely to have the integrity it requires, which seems to be the case.

Mr Beer: Then, lastly, page 17, please. At the foot of the page under “Existing Code”:

“Although parts of the EPOSS code are well written, significant sections are a combination of poor technical design, bad programming and ill thought out bug fixes. The negative impact of these factors will continue and spread as long as the PinICL fixing culture continues. This is partly due to the nature/size of the bug-fixing task and partly due to the quality and professionalism of certain individuals within the team.”

If you had known about that at the time what, if any, would the consequences have been?

Mr Jeremy Folkes: I think if we had known about it at the time it would have been suddenly escalated up to the highest level. I think if we had known that this much existed, I am sure the project would have potentially been canned, come the point that the BA withdrew and the decision had been taken of what was going to happen. I think this would have tipped the balance.

Mr Beer: Thank you.

Sir, is that an appropriate moment for the afternoon break?

Sir Wyn Williams: Yes, certainly. What’s the likely progress this afternoon, Mr Beer?

Mr Beer: I’m likely to finish at about 4.30 pm or dribble over into tomorrow morning and then some other core participants will ask their questions tomorrow morning, I suspect.

Sir Wyn Williams: So there is no realistic prospect of Mr Folkes finishing this afternoon?

Mr Beer: I don’t think so.

Sir Wyn Williams: That being so, I think we should finish at about 4.15 pm/4.20 pm, unless you really would like 10 minutes to finish, put it like that.

Mr Beer: No, thank you, sir.

Sir Wyn Williams: So 10 minutes now?

Mr Beer: Yes, thank you very much, sir.

(3.16 pm)

(A short break)

(3.26 pm)

Mr Beer: Good afternoon, sir, can you see and hear me?

Sir Wyn Williams: Yes, I can.

Mr Beer: Mr Folkes, can we turn to the position after or in the run up to the new contract being signed between POCL and ICL Pathway.

In your witness statement, you refer us to a paper written by the late Keith Baines who was POCL’s head of commercial.

That summarises the contractual position in relation to the new agreement that was due to be signed at the end of July 1999. Can we look at that paper please. It is WITN05970136.

You will see that it is a briefing paper on the new Horizon contract. It is dated at the top in the box and at the bottom right – at the top, 27 July 1999, and at the bottom, 27 July 2022.

Did you see this at the time back in July 1999?

Mr Jeremy Folkes: Yes. This was a document that Keith produced and circulated to the programme as it then was. I presume the date on the bottom right-hand is just because that’s when I printed it off.

Mr Beer: When you printed it off. And it was just a coincidence that it was 23 years later?

Mr Jeremy Folkes: Yes. These things happen yes.

Mr Beer: I’m sorry. I’m told, sir, that the transcript is down. Thank you very much. (Pause)

We just have to pause for the moment because the transcript has ceased to work.

(Pause).

Sir, I’m told that we need to break for five minutes whilst a fix occurs.

Sir Wyn Williams: Fine. I will go off screen but I will still be in the room so just speak to me when it is ready, all right?

Mr Beer: Yes, thank you very much, sir.

(Pause for technical reasons)

Mr Beer: Sir, I understand we are back up and running.

Sir Wyn Williams: So I understand, Mr Beer. I was just responding to an email, to the effect that I was ready as well.

Mr Beer: Thank you very much. Good to hear it.

Can we look please at the introduction of this document at the foot of the page which describes its purpose:

“This paper is prepared as a summary of the main differences between the old and new contracts between POCL and ICL Pathway, following the cancellation of the benefit payment card, and the new commercial terms agreed by the Post Office board on 24 May 1999. The intended audience is POCL managers who need to understand the main provisions of the contract either because they have working contacts with Pathway or because they have an interest in the services Pathway will be delivering under the new contract.”

You fell within that description?

Mr Jeremy Folkes: Yes.

Mr Beer: Over the page please:

“On 24 May … [POCL] and ICL Pathway signed a letter agreement that made major changes to the previous contracts between POCL and Pathway. At the same time, DSS and ICL Pathway agreed to terminate their contract for the benefit payment card services and DSS withdrew from the tripartite Authorities Agreement.

“The letter agreement specified that POCL and Pathway should produce a ‘codified’ contract that incorporated the changes into a new contract by 16 July. The codification process has now been completed, and the new contract is due to be signed on 28 July.”

That was the next day, after this document:

“There are significant changes to many aspects of the contract, summarised in the following sections.”

Would you, as a team leader or as a manager, have used this document rather than the underlying contracts – contract itself to understand the relative contractual obligations of each of the parties to it?

Mr Jeremy Folkes: Certainly. But you would not have gone line-by-line through the new contract. We would have used Keith’s summary.

Mr Beer: We can see in the rest of the document, I’m not going to go through it now because it speaks for itself. If we just scroll through it, differences in service scope, difference in prices, it is modeled on a standard turnkey build and operate contract, rather than a PFI based usage charging structure, risk transfer:

“The new contract significantly reduces the risk that Pathway was previously taking under the PFI. In particular, risks in relation to achievability by POCL of the roll-out timescales and in relation to future business volumes are now largely with POCL.”

Then, over the page please to “acceptance”. About five lines from the bottom of the first paragraph:

“The thresholds for medium severity Acceptance faults have been increased from 10 faults in total, to 20 faults overall, or 10 in any one Acceptance Specification. The threshold of any 1 high severity Acceptance fault still applies.”

So that amounts to a relaxation, is that right, the increase in number of permissible medium severity acceptance faults?

Mr Jeremy Folkes: Yes, relaxation from the point of view of Pathway.

Mr Beer: Say again?

Mr Jeremy Folkes: From the point of view of Pathway.

Mr Beer: Yes. Now, the product was designed and the system was designed and developed under a PFI contract when, as you have explained to us, you had limited visibility of what was inside the black box and that was explained by ICL Pathway on the basis that that was the nature of the PFI contract and they were taking the risk under the PFI contract. That’s fair?

Mr Jeremy Folkes: Yes.

Mr Beer: Now the relationship had fundamentally changed hadn’t it?

Mr Jeremy Folkes: It had but we of course got to this stage with the products, in theory, we were told, completed and almost ready to go into acceptance. So it ceased to be a PFI but it was starting from a very strange place to a conventional contract.

Mr Beer: But the paragraph we looked at about the transfer of risk to Pathway that existed under the PFI, that had gone?

Mr Jeremy Folkes: Yes.

Mr Beer: And now achievability by POCL of the rollout timescales and future business volumes. Those risks now rested solely with POCL?

Mr Jeremy Folkes: Yes.

Mr Beer: To your knowledge, were the concerns, that you, in the documents that we have seen, had been persistently raising about technical aspects of Pathway’s system, brought into account in the renegotiation of the contract?

Mr Jeremy Folkes: I don’t think they were, no.

Mr Beer: Do you know why?

Mr Jeremy Folkes: I don’t but I could hazard a guess but I don’t know – I have no evidence on which to base it.

Mr Beer: If we look at your witness statement please at WITN05970100 at page 42, you say at paragraph 124:

“The new Contract was based on the same set of Requirements and sadly did not improve our ability to perform Assurance on the solution. By the time that the new contract was finally signed in mid-1999, the system was already claimed to be fully developed …”

That is the point you just made a moment ago?

Mr Jeremy Folkes: Yes.

Mr Beer: “… and in many ways therefore ‘the damage was done’ regarding assurance (and I fear Quality). The Contract was signed as Acceptance activities were taking place and the contract had no facility for us to go back and revisit the problems of the previous few years, nor, as far as I can remember, did it give us any further access to detailed documentation.”

To your knowledge, was any attempt made to stop this from happening: either a failure to improve your ability to perform assurance on solution, revisiting the problems of the previous few years, or giving you further access to detailed documentation?

Mr Jeremy Folkes: I have no memory of any visibility of that. The contract negotiation was going on – off at a totally different level and I don’t think we were consulted as to what, if anything, we wanted to get in there. I think it was being done at some speed and went through some external pressures as we have seen and I don’t think – it was never seen to be on the table, you know. Nobody coming round and saying “Now, what else should we put in here”.

Mr Beer: It might be suggested that there was an unholy rush, amongst some, to get Horizon done. What would you say to that?

Mr Jeremy Folkes: There was a lot of pressure to get Horizon done. Obviously the programme had been going for five years. There was a big expectation out in the network, the network of offices. There were lots of – no, he’s not here – a glacier being held back from coming down the valley.

Everything was poised from the point of view of the big rollout of 20,000 offices. So there was a lot of pressure on POCL management for it to be done. I think, from what we see around acceptance, there was an attempt during the acceptance period to put the brakes on when the number of Acceptance Incidents came out and some of the issues came out. I think at the point view of – point of time of signing the contract I think there was probably a lot of pressure to get the contract signed for political and commercial reasons and probably no desire to, sort of, reopen the box by changing the rules as it were, however beneficial that might have been.

Mr Beer: In paragraph 126 of your statement, if we just scroll down please, you say:

“In hindsight, POCL missed an opportunity to force an in-depth review of the emerging system, including examining all aspects of how the system had been created, to mitigate the gap caused by the earlier PFI approach, and to require Pathway to open up to POCL.”

You say that in hindsight POCL missed an opportunity. Was hindsight, in fact, necessary in order to reach that conclusion or was it obvious at the time?

Mr Jeremy Folkes: I think – I’m just trying to give you the most honest answer I can to that. I think after three or four years of – at times it has felt like fighting with Pathway, from the point of view of assurance etc – that, to me, it was obvious that we should have done something but there was an incredible amount going on at that point, from the point of view of the new contract and whatever. I don’t know whether we would have got anywhere if we pushed harder. If [coughing] and myself had pushed harder to get an in-depth review. I think it was, a sort of, unstoppable super tanker at that point.

There was a view I think, that, okay, we have got through all this period, the assurance process hasn’t been a great success for all the reasons we have spoken about for several hours but now we are coming up to acceptance and people were going to rely upon the acceptance process and the acceptance testing and Acceptance Incidents to try and ensure the quality of the system.

I don’t know if that answered the question or not.

Mr Beer: Well, you had been identifying and reporting in writing, serious concerns and we have seen some of them today. We don’t have a record of what you were saying orally or via email. Sometimes they are even stronger in expression. But we have seen the formal documents that you created. Was this issue overlooked, ie we have not been able to undertake an in depth review of the emerging system, including examining all aspects of how the system had been created or was it known about but there was a rush to get the system rolled out?

Mr Jeremy Folkes: I don’t think anybody could claim that it wasn’t known about. You know, from the number of documents, given the amount that myself and others on the team had said, and they probably got rather bored with us saying it, but we had been very clear on the message, so I do not think it was not known about.

I can’t really explain why people didn’t go out and say “Okay, what else should we be doing at this stage”. The contracts team – renegotiating the contract and their brief, I guess, was to take the contract and codify it down to the single contract. You say, was there an almighty rush? From what I have seen understood, there was considerable pressure being put on POCL to be able to move this forward, which probably would have not encouraged, “Yes, reopen the contract and see what other quality and access requirements we wanted”.

Mr Beer: Thank you. Can I turn to a new topic. Audit, the provision of information and data by ICL Pathway and prosecutions. Can we look please at your witness statement WITN05970100, at page 67, please. This is within a section of your witness statement when you are looking back at fitness for purpose at rollout and at paragraph 207, in the third line you say:

“I think a key question for the Inquiry to ask is what gave POCL such confidence in Horizon to start using it for prosecutions of Subpostmasters, especially after the rather chequered history of the system from 1996-2000 and in particular the experiences of 1999.”

Can we look please, in addressing that question, at Fujitsu, FUJ00000071. This is the codified agreement of July 1999. Can we turn to page 97, please. Can we look, please, at 4.1.8 and 4.1.9. 4.1.8:

“The Contractor shall ensure that all relevant information produced by the POCL Service Infrastructure at the request of POCL shall be evidentially admissible and capable of certification in accordance with the Police and Criminal Evidence ACT … 1984. The Police and Criminal Evidence (Northern Ireland) Order 1989 and equivalent legislation covering Scotland. (R829 para 1).”

What do you understand the reference to “R829 para 1” is?

Mr Jeremy Folkes: That was a requirement in the requirements catalogue, 829.1.

Mr Beer: It is part of the specification in the requirements yes?

Mr Jeremy Folkes: Yes.

Mr Beer: A cross-reference, if you like, to that?

Mr Jeremy Folkes: Yes.

Mr Beer: 4.1.9:

“At the direction of POCL, audit trail and other information necessary to support live investigations and prosecutions shall be retained for the duration of the investigation and prosecution irrespective of normal retention period of that information”, and then a cross-reference to R829.2?

Mr Jeremy Folkes: Yes.

Mr Beer: Now, I think it is right that you were probably aware of these two provisions at the time, ie back in 1989 – sorry, 1999?

Mr Jeremy Folkes: Yes. In the same way I was aware of most of the provisions in the requirements.

Mr Beer: The reason I say that is we are going to come in a moment to a report that you wrote in the late summer, early autumn of 1999, about the subject of compliance with these two provisions.

Before we get there, can we look please at POL00029165. Thank you.

Can you see this is a document described as the Horizon system audit manual?

Mr Jeremy Folkes: Yes.

Mr Beer: Can you please summarise at a high level what it is, please?

Mr Jeremy Folkes: A document created by Pathway and it was shared with – this version – with Post Office Internal Audit, who is POIA. It had previously been – an earlier version that I had referred to the Inquiry to was shared with other members of POCL and BA Audit and it basically describes in some detail the methods of access to audit material by various different groups of auditors, including Pathway internal auditors, POCL auditors, BA auditors and some other categories of auditors and, in one particular part of it, it does attempt to address the requirements of 829, which is the one that you just referred to –

Mr Beer: Thank you, we will come to that in a moment. But I think this is the first time we have looked at this, so I just want to introduce it slowly. You see the reference in the top right, “IA/MAN/004”. Does that refer to “Internal Audit/Manual”?

Mr Jeremy Folkes: I believe that was Pathway’s naming convention, yes.

Mr Beer: The version we are showing you is 1.3, dated 17 January 2000, so shortly before you left in February 2000. That’s why we have picked this one to show you.

Mr Jeremy Folkes: It was a much earlier version, 0.3, which is the only one I believe I had ever seen and that was one that still had reference to BA on it because it was pre the split.

Mr Beer: Just looking at the abstract:

“[The] manual describes the Horizon Operational, Operational Support and Commercial systems and data flows in sufficient detail to enable members of the Horizon Audit Community to understand then for audit purposes.

“It also addresses the appropriate Criteria of Requirements”, and then some numbers given, including 829. That’s the cross-reference we looked at earlier.

“… insofar as it provides information relating to the composition of and access to the ‘audit trail’ as defined in those Requirements and its admissibility for PACE certification.”

So the abstract – the second part of it is probably the most important part for us – is saying that this document addresses requirement 829?

Mr Jeremy Folkes: Yes.

Mr Beer: If we scroll down the distribution list. Can you just tell us where within each organisation people came from, on the distribution list?

Mr Jeremy Folkes: Martyn Bennett was the Pathway director of risk and security. Chris Paynter was from Post Office Internal Audit.

Mr Beer: So POIA?

Mr Jeremy Folkes: I think it is Post Office Internal Audit.

Mr Beer: What did Post Office Internal Audit do?

Mr Jeremy Folkes: They were the internal audit function of the Post Office. I didn’t have any detailed contact with them but they would have been considered to be the sort of expert domain. The programme sat in a role of almost a dating agency, if you like, bringing in the relevant expert domains from around the organisation, together with the expert domains in Pathway. So, in this case, Chris Paynter, as POIA, was – I don’t know where he sat in internal audit but he would have been their nominated contact and the nominated representative of the audit community in Post Office who would have needed access to the system.

Mr Beer: What relationship did Post Office Internal Audit have within the Post Office or Royal Mail, indeed, for the conduct of investigations and prosecutions?

Mr Jeremy Folkes: I can’t answer that one.

Mr Beer: Were POIA responsible in any way for investigation or the conduct of criminal investigations?

Mr Jeremy Folkes: I can’t answer that one, I’m afraid.

Mr Beer: Then library, do you know whose library that is?

Mr Jeremy Folkes: In all these documents, “library” means the Pathway library.

Mr Beer: So a joint library?

Mr Jeremy Folkes: No, I believe that is the library run by Pathway.

Mr Beer: ICL Pathway.

Mr Jeremy Folkes: I don’t know whether this were agents to share certain documents but, certainly, there are plenty of documents that say “Library” that weren’t shared.

The other name on there, Paul Redwood –

Mr Beer: Yes.

Mr Jeremy Folkes: – was a member of the POCL Horizon team.

Mr Beer: What position did he hold?

Mr Jeremy Folkes: The name doesn’t really ring a bell. I presume it may have been within – I couldn’t really make a good guess.

Mr Beer: So it is an ICL Pathway document.

Mr Jeremy Folkes: Yes.

Mr Beer: What do you know about POCL’s contribution to it or review of it?

Mr Jeremy Folkes: There was an earlier version of it and there were two POCL people on it, two other names. One, I think, was a Hilary Stewart and the other was a Jason Carter(?). I don’t personally know or didn’t know either of them but I presume they represented the audit community and I believe Hilary Stewart contributed comments in this document in that there is reference to comments from “HS” further down in the change history.

Mr Beer: Yes, if you go over to page 3, please. At the foot of the page, I think we can see, under “Changes v1.2 to 1.3”, for some reason Hilary Stewart and a lady called Ruth Stinchcombe were removed from the distribution. In any event, this is a 68-page document, and I’m only going to draw your attention to some of it.

Can we turn, please, to page 53. We should just look at the previous page – I’m sorry – to get the heading, “Retrieving and Extracting Audit Data”, 10.3 and then scroll back to where we were.

“Overview”, I’m going to ask you to translate this in a moment:

“This is where audit data is retrieved from the DLT, based on Request(s) For Information made by Post Office Internal Audit, and presented for further extraction or placed on CD-ROM or other suitable media for dispatch to the [Request For Information] originator.

“The following paragraphs are ordered to reflect the actual processing of a Request For Information (RFI) by ICL Pathway Internal Audit.”

Can you just translate what that’s saying, please?

Mr Jeremy Folkes: DLT stands for digital something-or-other tape. It is a storage medium. So my understanding is that audit data would – if you go up to the previous diagram, if we can just go up one page, I believe we should see there are tapes on the left-hand side.

So data gets written to tapes. I believe, Pathway had an infrastructure that pulled data from a number of points in the system, including of interest to us here, what’s called the TMS journal, which is the transaction management service journal, the data coming up from offices. That data was stored on DLT, from what I remember, probably on a daily basis, and what the Pathway internal audit can do is retrieve that data as per request and copy the data onto CD-ROM, compact disk, to give to an authorised Post Office Internal Audit person.

Mr Beer: Back to the next page, please. 10.3.2:

“POIA [Post Office Internal Audit] will request audit data via Request For Information form. This will contain a description in business terms of the times outlets, events, items and activities that the Auditors are interested in. This request has to be interpreted by Pathway Internal Audit and mapped onto the Audit Points and Files described earlier in this manual.”

I’m not going to take you to those.

Can we go over the page, please, to 10.4.2, which may be an important paragraph, “Investigation Support”:

“The term ‘investigation’ is used in its broadest sense and does not limit itself to fraud. Any RFI is likely to be associated with a specific business event, eg an encashment, a bill payment, an outlet, a beneficiary. It is anticipated that the majority of this type will be based on the TMS journal or will use it as a start point. See section (11.2) [which we can look at] for details of how to raise a RFI.”

Can you translate what that’s saying for us, please?

Mr Jeremy Folkes: The statement is basically just saying that investigation doesn’t necessarily mean fraud investigation but anything that POCL need to investigate. Typically, that would be – you would be able to start by – it may be a specific event, such as a specific transaction or in a specific outlet that would trigger it, and it’s saying the majority of this type of retrieval would be based on the TMS journal.

The TMS journal is, I believe, the term they use for the message store centrally which is, by nature of Riposte, the image of the message store in the office. So that’s, if you like, the raw data that EPOSS would have written in the office, once it is replicated up to the centre, it is then, I believe, archived onto tape from there and it is bringing back that data from tape to give the journal that would then be available for the investigation.

Mr Beer: Thank you. Over the page, please. “Obtaining Access to Operational Audit Data”, this is under the heading “Requirement 699”. As far as I can see, there isn’t a specific heading dealing with requirement 829, which is the one that we were interested in.

But under requirement 699, if we scroll down, please, to the bottom of the page, there is something that may be of interest, at the last part on the page:

“Access to POCL audit trails, particularly the TMS Journal, is seen as a strict POCL preserve. If any third parties require access to it, for evidential purposes or fraud investigation, then the access will be via Post Office Internal Audit.”

Mr Jeremy Folkes: If I can just explain what’s behind that paragraph.

Mr Beer: Yes, please.

Mr Jeremy Folkes: Apart from, if you like, the obvious, which is that PO Internal Audit is the conduit into Pathway, when it was still a joint contract, there were many joyous debates between BA and POCL regarding access to information and, if you had a potential – mostly around benefit encashment fraud. If there had been benefit encashment fraud down on a counter terminal, the question then came up is that data BA’s data or POCL’s data, because it is sitting within the POCL data but it may relate to the a BA transaction.

I think all this was actually saying is that, if it was data down on the POCL counter terminal, then access to that data, even if it referred to a BA transaction, would need to go via POCL.

Mr Beer: Looking at the document as a whole – and I think you had a chance to read it and I think I have drawn your attention to those parts of it that could or could possibly be a reference to carrying requirement 829 into effect – what’s your view as to whether this document adequately addresses, from an operational and practical level, the translation of 829 into reality?

Mr Jeremy Folkes: Obviously, the document doesn’t make any reference to any form of certification or any form of – doesn’t cover anything apart from direct access to the data.

Mr Beer: Sorry, just stopping there. You are making the point, I think, that the document is focused on obtaining access to data, rather than the provision of a statement or a report that certifies accuracy or integrity; is that right?

Mr Jeremy Folkes: Yes, and I think this is very much looking at it from an operational/technical point of view, so it goes into great detail on, if you like, the integrity of the audit trail, how it is pulled off, et cetera, but not around anything other than, say, the provision of statements or whatever, as may be required by PACE.

I don’t know where that would have been – other part would have been covered.

Mr Beer: Is it right that you took some steps to try and get that other part, ie compliance with PACE, covered?

Mr Jeremy Folkes: So, I believe in the original contract, there were the same – those two requirements but, as applied in the BA contract, they were slightly different.

Mr Beer: We are going to come to that in a moment. Just, generally, did you make some effort to try and ensure that requirement 829 was translated into practical effect so that systems and processes were created at a practical level to ensure that it could occur?

Mr Jeremy Folkes: I didn’t personally, but, without dodging the question, requirement 829 and audit wasn’t part of my remit.

Mr Beer: Did you write a paper suggesting it be done?

Mr Jeremy Folkes: We did – there was one piece of work I was asked to look at in the middle of – September 1999, where I was passed, I think by possibly Dave Miller or Bruce McNiven, a document that Post Office Internal Audit had written that made various comments about audit and investigation access, and I did respond back to either David Miller or Bruce McNiven around that and it did cover the fact that, in particular, there seemed to be a gap regarding the provision of a PACE – I don’t want to use the term loosely – but witness statement and that that seemed to be something that had been dropped out in the contract and would need to be taken forward.

Mr Beer: Thank you.

Mr Jeremy Folkes: So I was trying to flag I’m not an expert in this area but this is something that should need to be resolved.

Mr Beer: Sir, as we are on this topic, would you mind if I just spent 10 minutes finishing it off?

Sir Wyn Williams: No, you carry on, Mr Beer.

Mr Beer: Can we look, please, at that paper, WITN05970134. If we can just blow it up a little bit, thank you.

Just scrolling down to start with – if you can scroll down, please?

Mr Jeremy Folkes: Can I say, the bits that are in boxes are my comments.

Mr Beer: That is what I was about to ask.

Mr Jeremy Folkes: The bits that are in boxes are my comments. I was passed this paper by either, I think, Dave Miller or Bruce McNiven and asked to comment on it and I – my comments are here in the boxes.

Mr Beer: So bits in the boxes are your writing, bits outside the boxes are part of the pre-existing content of the document?

Mr Jeremy Folkes: Yes, which was, I believe, written by somebody in Post Office Internal Audit but I don’t have their name.

Mr Beer: Can we go up to the top of the page, please. Under the “Introduction”:

“A review of the Horizon Cash Account System was undertaken following a request from the Horizon Programme Director. The objectives of the audit were reflected in the terms of reference which were agreed with him on 15 July 1999.”

At about that time, July 1999, who was the Horizon programme director within POCL?

Mr Jeremy Folkes: I presume that was still Dave Miller but it would either have been Dave Miller or Bruce McNiven.

Mr Beer: “It was agreed that this review would be undertaken in two stages and this report reflects the findings from the second stage.

“Management Summary

“POSIS Investigations at Outlets.”

Does “POSIS” stand for Post Office Security and Investigation Services?

Mr Jeremy Folkes: I believe so, yes.

Mr Beer: “We are extremely concerned to be informed during the review that POSIS currently do not have access to archived data from the system. Data on the system is compressed and archived after 35 days. It was originally intended that access would be gained via the Fraud Risk Management Server, which formed part of the benefits payment system and has now been withdrawn. This means the business could be in a position where it is unable to investigate potential frauds or prosecute cases due to the unavailability of critical data.”

Stopping there. You explain in your witness statement the inclusion of the FRMS, the fraud risk management server, in the original contract, the tripartite arrangement, and its withdrawal when the new contract was signed in July 1999?

Mr Jeremy Folkes: Yes.

Mr Beer: Have you any comment to make on that paragraph there?

Mr Jeremy Folkes: Well, the paragraph shows a degree of confusion amongst the writer. The fraud risk management service was one of the components that was contracted for by BA. It was created specifically for the Benefit Encashment Service or Benefit Payment Service and the idea was that, as far as introducing the payment by plastic card to coming on for 20 million benefit recipients, there would need to be potentially control of encashment fraud.

And the FRMS was a service that I think was in the requirements and that Pathway posed a solution for, to have specific reports and mechanisms to flag up potential fraud within the encashment process.

As examples of this, I went back and checked. One of the examples was, for instance, if an office did more than its expected number of foreign encashments – a foreign encashment being where somebody was away from home – you might get an office if it – suddenly find that its normal list of number of foreigns was 5 per cent, it was actually 80 per cent, it may indicate fraud.

There was also something called casual agents, where people could go in without a card and if an office got a higher number on that, it might indicate fraud.

The FRMS was very much intended not for prosecution support, not to get audit data, but as a means of managing benefit encashment risk and identifying high risk activities.

When BA withdrew, FRMS ceased to exist because it was a BA service. It also wouldn’t have been relevant. I think there was only one report, which something about out of hours transactions, but everything else was benefit encashment specific and, therefore, it would have had nothing to do. It was never intended that POSIS or any of the Post Office audit or investigating people would go in via FRMS to get this kind of data.

Mr Beer: Over the page, please. Do you explain that – I’m not going to go through it – in paragraphs 4, 5 and 6, where you begin “There appears to be some confusion”?

Mr Jeremy Folkes: I do, yes. And just to say, the only thing I would say is on para 5, what I’m saying is there were quite reasonable arrangements between POCL Security and Investigations and the BA equivalent, who were called Organised Fraud, to share data because, if there was fraud regarding benefit encashment, it may be appropriate to share it. But it was never intended that POCL would have to go to BA Organised Fraud to get information on an office having a problem with its cash account or doing a bill payment transaction.

Mr Beer: Thank you. If we just move down to paragraph 7, please. You say:

“A documented process has been established between POCL and ICL Pathway for access to historical audit information from Pathway’s central systems, under the auspices of the requirements on Audit (Requirements 699 and 829), using an [RFI] procedure. This process involves the exchange of the RFI and data between nominated individuals in the audit domain, believed to be (originally) Hilary Stewart and (now) Chris Paynter of POCL National Audit, and Jan Holmes of ICL Pathway’s Audit team. All requests from POCL would therefore need to be fed through the nominated POCL audit contact. This process is documented within the Horizon System Audit Manual (IA/MAN/004).”

That is the audit manual we just looked at?

Mr Jeremy Folkes: Correct.

Mr Beer: Over the page, please. The original authors wrote that:

“Bob Martin also advised us that Security and Investigation Executive (S&IE) had requested an expert witness statement from Pathway to support a prosecution and that this had been refused on the grounds that there was no contractual requirement. John Cook advised us that there is a contractual requirement for Pathway to ensure that the system meets the requirement of the Police and Criminal Evidence Act. There is a need for Pathway to agree with the [Security and Investigation Executive] and Internal Audit how this requirement will be met, as well as the procedures for obtaining this evidence when needed for prosecutions.”

Then you, in your box, say:

“The requirement (R829.1) is actually”, and you set it out, yes?

Mr Jeremy Folkes: Yes.

Mr Beer: “An outstanding [AI] Acceptance Incident (370 Low) – exists against the POCL requirement, on the assertion by POCL that Pathway should produce a witness statement to support prosection. This AI revolves around the interpretation of ‘ensure that all relevant information is evidentially admissible’ – POCL’s view is that to be admissible it will need to be supported by witness statements etc; Pathway have stated that they will ‘provide PACE statements as necessary to support a fraud prosecution’, but that ‘the work required to produce draft witness statements’ is not within the scope of the requirement and will be done once POCL raise a Change Request.

“This issue has been handled with Pathway by Bob Martin and Paul Harvey of SIE. The Acceptance Incident is still open, and its resolution would appear to be primarily a commercial issue”, ie to do with money?

Mr Jeremy Folkes: Yes.

Mr Beer: Then you say this in square brackets and I think this is what you are alluding to earlier:

“Note the Benefits Agency has similar requirements (R741 and 780) covering their aspects of the service mirroring the above section, however these had an additional clause reading: ‘The contractor shall provide certification in accordance with … PACE, and PACE(NI) … (and equivalent Scottish legislation) when necessary for a proposed prosecution …’”

Then this:

“’… to demonstrate that the Service Infrastructure was operating within normal parameters at time of an alleged offence’. This additional clarifying clause was lost at the time of withdrawal of BA (at contract codification), but in any effect it (strictly) only referred to PAS and CMS, both BA services, even prior to BA withdrawal. Attempts were made to get this cause inserted into the codified agreement to apply to POCL but without success.

“Clearly, a process does need to be agreed between POCL, SIE and ICL Pathway for the commissioning of PACE certification, statements and court appearances.”

Firstly, how do you know that attempts were made to get the previously worded clause inserted into the codified agreement as it applied between POCL and ICL Pathway but without success?

Mr Jeremy Folkes: I do not know for certain but I imagine I went up and spoke to John Cook – John Cook, I believe we mentioned earlier on – John Cook worked within Keith Bates’ team on the contract.

Mr Beer: The last sentence:

“Clearly a process does need to be agreed … for the commissioning of PACE certification, statements and court appearances.”

To your knowledge what happened?

Mr Jeremy Folkes: I don’t know what happened to this, in that I was asked to comment on this by, I think, Dave Miller and I returned this back to Dave Miller, I believe.

Mr Beer: Lastly if we can look at page 5 please under conclusion. The original author/s say:

“There is a need to ensure that the problems relating to the audit trail for S&IE investigations and demonstrating that the system meets the requirements of [PACE] have been impact assessed as incidents and are considered by the Acceptance and Release Authorisation Boards if not satisfactorily resolved. In addition, it will be necessary to consider whether the current level of cash account errors will affect the accuracy of settlement with clients, when considering the rate at which the system should roll-out.”

What is Mr Miller or whoever wrote this saying in the last paragraph?

Mr Jeremy Folkes: It wouldn’t have been Mr Miller, it would have been the auditor.

Mr Beer: Sorry. What is the auditor saying –

Mr Jeremy Folkes: The auditor in that paragraph is making the statement that, with the level of errors that were being reported at this point, which was September I think, I can’t remember the date at the top – but that has been reported in late summer of 1999, that it would – that that level of errors would affect the ability of the POCL back end to manage settlement with clients.

Clients in this case means the companies for whom POCL does work, such as, you know, BT or water companies or British Gas or whatever.

Mr Beer: To your knowledge was anything done with the recommendations made by this paper whether – as originally authored by the auditor or as amended or commented on by you?

Mr Jeremy Folkes: I didn’t have any visibility of anything being done with it, but I believe it would have been. I believe something was put in place – for better or worse, there was a process put in place for the production of expert witness statements, and I presume there was also – processes were better exercised as far as retrieval of audit data, but I – at that point, this is one of these jobs that I was set the task by I believe Dave Miller: comment on this paper. I comment on the paper and went back.

This was about the time when a number of tasks were being passed away from people on the programme, like myself, who eventually would disappear, into Business Service Management and I think a number of the activities, as far as communication with Fujitsu or with Pathway, as far as access etc, would have then moved to being managed by Business Service Management. But a likely place it might have ended up may have been in BSM.

Mr Beer: Thank you, Mr Folkes. It is 4.30 pm. I have about 10 minutes more which I would propose to pick up tomorrow morning.

Sir Wyn Williams: Yes, fine. All right. We will start again at 10.00 tomorrow morning then.

No doubt, Mr Folkes, you will be equally glad not to speak about your evidence overnight.

Mr Jeremy Folkes: I will go and find a restaurant where nobody knows me.

Sir Wyn Williams: Fine. See you in the morning.

Mr Beer: Thank you very much, sir.

(4.29 pm)

(The Inquiry adjourned until 10.00 am on Thursday, 3 November 2022)