27 October 2022 – Terence Austin and John Bennett
Hide video Show video
(10.17 am)
Mr Blake: Good morning, sir.
Sir Wyn Williams: Good morning.
Mr Blake: Today’s first witness is Terence Austin.
Sir Wyn Williams: Yes.
Terence Austin
TERENCE AUSTIN (affirmed).
Questioned by Mr Blake
Mr Blake: Thank you very much. Could you give your full name, please.
Terence Austin: Terence Paul Austin.
Mr Blake: Mr Austin, in front of you should have a witness statement?
Terence Austin: Yes, I do.
Mr Blake: Could I ask you to turn to the final page, that’s page 19. Can you confirm that that is your signature?
Terence Austin: Yes, it is.
Mr Blake: It’s dated 13 September of this year; is that right?
Terence Austin: That’s correct.
Mr Blake: Is that statement true to the best of your knowledge and belief?
Terence Austin: It is.
Mr Blake: Thank you, Mr Austin.
For the purpose of the transcript the statement is WITN04190100. Mr Austin, that statement and its exhibits will go into evidence, so I’m not going to repeat lots of matters that are contained therein. We’re going to spend about half a day going through various matters. I’m going to start with your background.
You spent 40 years in the IT sector; is that right?
Terence Austin: That’s correct.
Mr Blake: You joined ICL as a programme director in 1995?
Terence Austin: Correct.
Mr Blake: You were employed specifically to deliver the benefit card and the Electronic Point of Sale System; is that right?
Terence Austin: The whole solution with regard to the ITT.
Mr Blake: So I think you said you were responsible for delivering the IT Pathways solution; is that right?
Terence Austin: Yes, correct.
Mr Blake: You became systems director at some point.
Terence Austin: Yes, there was a period of time, several months after we started, after award of contract, where it was obvious that the requirement was expanding tremendously and it was felt that we should reorganise the team so that I would then take responsibility for the solution and that one of my colleagues would come in and take over the position as a programme director, so I relinquished areas such as implementation, training, business requirements, et cetera, so that they went elsewhere within the ICL Pathway organisation.
Mr Blake: You left in October 2000?
Terence Austin: I did.
Mr Blake: Would it be right to say that you were the senior technical director of the Horizon programme?
Terence Austin: No, it wouldn’t.
Mr Blake: Were you the most senior individual who had responsibility for the IT Pathway solution within ICL?
Terence Austin: Yes.
Mr Blake: Were you part of the management structure?
Terence Austin: I was.
Mr Blake: Were you happy with how ICL was being managed at the time?
Terence Austin: Yes. I was recruited specifically for the ICL Pathway project.
Mr Blake: Did you have faith in its internal controls and internal processes as a company?
Terence Austin: I was not familiar with the internal processes because I was brought on specifically to look at the ITT for the ICL Pathway programme.
Mr Blake: But as your career developed, did you have faith in the –
Terence Austin: Within the ICL Pathway?
Mr Blake: Yes.
Terence Austin: Yes.
Mr Blake: Did you think it was a good company at scrutinising itself?
Terence Austin: Yes.
Mr Blake: Did it have an effective audit process, for example?
Terence Austin: ICL itself?
Mr Blake: Yes.
Terence Austin: I wasn’t aware of it, but I assume there was. We introduced our own within ICL Pathway.
Mr Blake: So within ICL Pathway, were you happy with the audit process?
Terence Austin: Yes.
Mr Blake: Can we look at FUJ00080690. This is the EPOSS PinICL task force report. You can ignore, I think, the date on the top right-hand corner because the EPOSS PinICL task force was, as it says on the front page, in place between 19 August and 18 September 1998. Do you remember this document?
Terence Austin: I do.
Mr Blake: Do you remember seeing the document at the time?
Terence Austin: I do.
Mr Blake: It has your name on the distribution. Can you tell us about the authors – the author, if we just look below that, it has J Holmes and D McDonnell. J Holmes is, I think, Jan Holmes, I think we have been pronouncing it Jan but it is Jan Holmes?
Terence Austin: It is.
Mr Blake: He was the audit manager; is that right?
Terence Austin: He was.
Mr Blake: Who was D McDonnell?
Terence Austin: That was another person within the audit team, as far as I can recall.
Mr Blake: Do you think he was the deputy development manager? Is that a title you remember?
Terence Austin: I remember the title, but I don’t remember the name, I’m afraid.
Mr Blake: From what you have said about the audit process at ICL Pathway, presumably you had faith in them in carrying out that task?
Terence Austin: Well, I was the instigator of the task force.
Mr Blake: Yes, so you appointed the right individuals to carry out that task?
Terence Austin: Yes, which was Jan.
Mr Blake: Of drafting the report.
Terence Austin: Yes.
Mr Blake: Did you have any reason not to believe what they said in the report?
Terence Austin: The reason I hesitate is that auditors are not technical people. They interview people and they draw conclusions and they then summarise those conclusions and their recommendations.
Mr Blake: But I think Jan Holmes was the auditor but Mr McDonnell was –
Terence Austin: A deputy development –
Mr Blake: – a technical man. Can we look at page 4 of that document, please. This is the introduction and I’m going to just read from the second paragraph for the purpose of the transcript. It says:
“This report presents the outcome of the Task Force activity and identifies factors which prevented the original target (zero or near to zero residual PinICLs) being met.”
Now, PinICLs are error logs or –
Terence Austin: Defects, yes.
Mr Blake: “During the course of the Task Force it became clear that there are significant deficiencies in the EPOSS product, its code and design, and these are also presented in this report. Finally the report contains recommendations from the authors which we believe should be implemented by the programme to address the shortcomings identified.”
So that’s the very first section of this 20-page document and it is highlighting there that there were, in their view, significant deficiencies in the EPOSS product, its code and design; do you agree with that?
Terence Austin: Absolutely, yes.
Mr Blake: Can we turn over the page to page 5, please, and the top half of that page. In summary, it says there that they had spent five weeks trying to get the PinICLs down to zero and it is the second paragraph there:
“The position at 1300 hours on 18th September is that 166 PinICLs have been fixed and closed and 165 remain in WIP.”
Is that “work in progress”?
Terence Austin: Yes.
Mr Blake: “This indicates that the Task Force has failed to meet its primary objective.”
So they closed 166, but 155 (sic) remained, presumably that indicates a significant remaining problem, despite the task force having –
Terence Austin: It does.
Mr Blake: – closed a number of PinICLs?
Terence Austin: It does.
Mr Blake: Moving over to page 7 of this report, there is a section on EPOSS code and, again, for the purpose of the transcript, I appreciate it’s a relatively long passage, but I’m going to read it, it says:
“It is clear that senior members of the Task Force are extremely concerned about the quality of code in the EPOSS product. 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 present [I think that means ‘presents’] a situation where there is no guarantee that a PinICL fix or additional functionality can be made without adversely affect [I think it means ‘affecting’] another part of the system.
“However, a more worrying concern from the Programme’s perspective should be the reliance on the EPOSS product in its current state as a basis for planning and delivery. During the Task Force there was relatively little testing that directly impacted EPOSS and yet [over] 200 PinICLs, roughly 50 per week, were raised. Immediately following the conclusion of the Task Force it is intended to re-run System Test Main Pass and various other test streams. While I am confident that the fixes delivered by the Task Force will prove to be reliable, I fully expect the PinICL rate to increase as further testing is carried out.”
Now, concerns that were expressed there include that the code will decay; do you remember that?
Terence Austin: I do.
Mr Blake: That’s, I think, a term that’s used to describe where there’s a reduction in reliability and effectiveness –
Terence Austin: That’s what it is implying, yes.
Mr Blake: – over time and that could, for example, affect things like the cash and counter performance, potentially.
Terence Austin: Potentially, yes.
Mr Blake: Can we look at page 17 of the same document please, paragraph 7.3, “Existing Code”:
“NB: This section has been produced with the assistance of Dave McDonnell and Martin Smith and their combined experience of structured programming.”
Do you remember who Martin Smith was at all?
Terence Austin: He would be one of the team, one of the programmers.
Mr Blake: So, again, two technical experts?
Terence Austin: Yes.
Mr Blake: They say:
“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.”
Then over the page:
“Whoever wrote this code clearly has no understanding of elementary mathematics or the most basic rules of programming.”
That’s all pretty damning, isn’t it?
Terence Austin: Very much so.
Mr Blake: Presumably, that would have been quite well-known amongst the team at the time?
Terence Austin: Maybe amongst the team but not amongst the management part of the team.
Mr Blake: So I think if we turn to the first page of this document it shows the distribution. There is yourself there, Mr Bennett, Mr McDonnell and then it says “Library”. Do you know what that was a reference to?
Terence Austin: It will be stored in the library of the audit team, I believe.
Mr Blake: Would the information from this report have been – you say it was known to the team. Who would have known about –
Terence Austin: Well, the reason for me asking for the task force in the first place was that I wasn’t very happy with the way the product was, so I felt let down by the people who had developed it, who were supposed to be experts in their field. So because I was getting reports that the product was not stable and that it was not behaving in a way that we would expect, I called the task force.
So I called the task force together and brought in the people who I thought were the most competent people within my team to be able to look into this and see what was going on, and it was as a result of that that Jan writes a report at the end of their activity and when I received this report, which was, as you quite rightly say, “very damning”, and a massive worry to me and the rest of ICL Pathway, we had to take every part of it extremely seriously.
So we took – I called in all the members of the task force and my lead designer and we went through every element of it to find out what we could do and what options we had to do.
We identified who the people were that were responsible for producing the product in its particular state and they were removed from the team, so that we were starting off with a different team that was looking at it and designing it and managing it.
Mr Blake: Do you remember who was removed from the team at all?
Terence Austin: No, I’m sorry, I can’t. I genuinely can’t.
Mr Blake: So this was 1998?
Terence Austin: Yes.
Mr Blake: We then have another report in 1999 that I would like to take you to, that’s –
Terence Austin: First of all – sorry to interrupt, I would just like to say that, as a result of the various meetings following this, we went into a corrective action plan. So we decided what actions we needed to take in order to get the product into the state that we were happy with.
Mr Blake: So let’s look what happened a year later, 1999, and that is FUJ00079782. This is the “CSR+ Development Audit”. Very briefly, can you tell us what CSR+ was?
Terence Austin: Core System Release, I believe.
Mr Blake: That was also conducted by Jan Holmes, if we scroll down a little bit; so the audit manager conducted this audit.
Terence Austin: Yes.
Mr Blake: Can we look at page 6, please, and scroll down to the bottom of the page. There’s a section on “Audit Conduct” and how the audit was conducted. It explains there that there were some 35 interviews over a four-week period between September and October 1999, so quite a comprehensive audit?
Terence Austin: Absolutely, yes.
Mr Blake: As I said, this is a year on from the Holmes/McDonnell report that we just saw.
Terence Austin: But this is an audit of the entire release, so it’s the entire product, not just the EPOSS product.
Mr Blake: Yes. Can we look at page 7, please, and 2.5. This addresses “Next Steps”, and it says there, in the first paragraph, that there was an opportunity during the week of 8 November to challenge any recommendations that were made in that report.
It is page 19 – as you say, there are plenty of pages that address other aspects of CSR+, and it is page 19 that addresses EPOSS. Again, I’m going to read a fair bit out, I’m afraid. It says:
“From the CSR+ perspective the development of the EPOSS product has been successful with software drops being made according to planned schedules and confidence in the team that future drops will also be achieved on time.
“Unfortunately EPOSS continues to be resource hungry in dealing with live problems associated with CSR and in ensuring that these fixes are brought forward and incorporated into the CSR+ product.
“The EPOSS task force report [which we have already seen] raised the question of the maintainability and resilience of the EPOSS code following the 6 week PinICL blitz where some 550 PinICLs were processed. Since then [so a year later] a further [approximately] 996 PinICLs have been raised – using the ‘Product = EPOSS and Target Release = IR-CSR or PDR-CSR’ search criteria – and these can only have had a detrimental effect on the quality of the code. In particular the maintainability, resilience and potential for change aspects must be subject to doubt. The report also identified many instances of poor programming technique and application of coding standards and while CSR+ changes have been reviewed by the Team Leader, no attempts have been made to address the significant body of code not affected. There is also anecdotal evidence that EPOSS components used by other applications are fragile and cause problems for the calling application, Print Server was mentioned by both LFS and APS Counter teams.”
So “resource hungry”, it sounds as though it required a lot of attention; is that right?
Terence Austin: That’s correct.
Mr Blake: It has been – well, there are 996 more PinICLs that have been raised, so it’s got worse since that EPOSS task force were carrying out their job, in terms of the number of PinICLs at least; would you agree with that?
Terence Austin: That’s correct.
Mr Blake: “PinICL fixes can only have a detrimental effect on the code”, presumably, again, that’s a reference to code decay or something similar to that?
Terence Austin: Correct.
Mr Blake: It says:
“… CSR+ changes have been reviewed by the Team Leader …”
Who was that “Team Leader” a reference to, do you know?
Terence Austin: I would imagine that would be Steve Warwick.
Mr Blake: Can we go over the page, please:
“The figures indicate that the problems facing EPOSS during the Task Force period have not diminished. Of greater concern are the non-EPOSS PinICLs within the group suggesting that there are still serious quality problems in this vital, customer facing element of the system.”
Then there’s a box there and the box says:
“The EPOSS Solutions Report made specific recommendations to consider the redesign and rewrite of EPOSS, in part or in whole, to address the then known shortcomings. In light of the continued evidence of poor product quality these recommendations should be reconsidered.”
Now, is that box a recommendation?
Terence Austin: It’s saying that we should reconsider the rewrite option.
Mr Blake: But I think we saw at the beginning of this report that there was an opportunity to object to particular recommendations by 8 November. I think it was talking about those kinds of things, wasn’t it, as a recommendation?
Terence Austin: Yes. Actually, the fact – what I’m finding – yes, I’m struggling because this was a massive issue for me and I discussed it with all my technical team in-depth.
Rewriting a product is not necessarily a solution in itself because you can reintroduce problems, or you can have people who don’t understand the requirement as well, and you can actually end up with a product that’s even maybe a little better but not necessarily any better.
My preferred solution at the time, having spoken to all the people, is that the decay was in certain parts of the product and we should focus our efforts and see if we can stabilise those parts that were causing the majority of the PinICL. In fact, this was a view strongly felt by Steve Warwick, who I had a lot of respect for.
Mr Blake: We will come to see how your view was that you weren’t in favour of a rewrite?
Terence Austin: Well, not initially. It was still an option on the table. I hadn’t dismissed it. I just felt it wasn’t necessarily – we should explore other avenues first before taking that pretty drastic course of action.
Mr Blake: But it was a recommendation from ICL Pathway’s auditor Jan Holmes?
Terence Austin: It was a recommendation.
Mr Blake: Yes. Can we look at page 47 of this document, please. These are the terms of reference of the audit and can we look over the page to “Reporting”. It says there:
“A final report will be produced and distributed to the Director and Senior Managers of the Development Directorate, as well as the Managing, Deputy Managing and QRM directors.”
Then it has a list of the distribution – at least of the terms of reference and you are listed there first. Now, it’s not in alphabetical order but you’re first. Is that because you were the most senior or that it was most appropriate to you?
Terence Austin: No, Mike Coombs was the most senior. It was because it was most appropriate to me.
Mr Blake: Thank you. Can we please go to FUJ00079783, please. This was a month later and, following the audit, there were a list of corrective actions that needed to take place and this sets those out. So I think, effectively, it sets out the recommendations and what’s being done about them.
You are listed as a recipient and throughout this report you are, I think, TPA; is that right?
Terence Austin: That’s correct.
Mr Blake: Can we look at page 3, please, and down to the “Key to plan”. Now, there are various shorthand terms throughout this document and one of them is “Owner”, which is “The identified owner of the corrective action”, and the other is “MTM”, “Management Team Member to whom the CA Owner reports”. So there’s a distinction between somebody who effectively takes ownership of the recommendation and the person that manages the relevant team or relevant person; is that right?
Terence Austin: Yes, yes.
Mr Blake: Could we scroll down, is that possible, over to the next page. So these are various recommendations. We see there 3.2, 3.3, I think 3.4, also, were recommendations relating to various documentation that needed to be actioned and you are there as the MTM, so there you’re taking the management responsibility for those issues.
Terence Austin: Yes.
Mr Blake: Can we keep on scrolling to page 6, please. That’s 4.2.1, thank you very much. There you are the owner of this particular issue; is that right?
Terence Austin: That’s correct.
Mr Blake: Can we just look at the left-hand side. It says:
“The audit identified that EPOSS continues to be unstable. PinICL evidence illustrated the numbers of PinICLs raised since the 1998 Task Force and the rate of their being raised.
“The EPOSS Solutions Report made specific recommendations to consider the redesign and rewrite of EPOSS, in part or in whole, to address the then known shortcomings. In light of the continued evidence of poor product quality these recommendations should be reconsidered.”
So that’s effectively what we saw in that audit from Jan Holmes and you are down there as the owner of that particular recommendation.
Terence Austin: The recommendation was to consider a rewrite.
Mr Blake: Yes. Can we look on the right-hand side. Is it possible to blow up that right-hand side? There are certain things there that I think I’m going to need your help with because I don’t quite understand. Let’s see where we get to. 17 November:
“This action falls within Development but requires higher level drive. Has links with CS and BD.”
Do you remember what that means at all?
Terence Austin: “CS”, I think, is customer services and “BD” is business development.
Mr Blake: Thank you:
“MJBC to speak with TPA direct.”
Is that –
Terence Austin: Mike Coombs.
Mr Blake: Mike Coombs, thank you very much. 25 November:
“Work on AI298 identified that majority of problems ([approximately] 80%) were to do with error and printer error handling. Daily meetings had been instigated. TPA of view that while original code had not been good it would be difficult to justify the case for rewriting now.”
So I think it’s right to say that in November, towards the end of November, you were of the view that a rewrite wasn’t your preference?
Terence Austin: It was a very risky thing to do and if the judgement was that 80 per cent of the errors were down to error handling and printer handling, printer error handling, then we should attack that part of the Code and probably rewrite that.
Mr Blake: I mean, that would still leave 20 per cent, of course?
Terence Austin: Yes, it would.
Mr Blake: There’s an email issued by yourself, I think, and that says:
“We have not formally closed down the recommendation that we re-engineer the EPOSS application due to its inherent instability. Since this recommendation was made, a number of events/actions have taken place. We embarked upon a major maintenance exercise for LT2 which targeted several known stability issues. In parallel, we carried out a defensive testing activity which identified a number of faults which were addressed. The intensive exercise designed to remove Acceptance Incident 298 resulted in many substantial improvements to the error handling, messaging and printing aspects of this product.”
That’s the 80 per cent that we talked about just now:
“We finally introduced improved unit and link testing and more disciplined configuration control. Finally, the maintainability and enhanceability of the product has been proven by the speed and quality of the SIP16 and EPOSS reconciliation developments.
“We will of course continue to monitor the PinICL stack for the next few months and if necessary re-evaluate this decision. Would Jan please close this issue formally using the rationale described.”
So what you are doing there is asking Jan Holmes to close the recommendation because, in your view, it effectively didn’t need to be written at that time?
Terence Austin: At that stage, I was suggesting that the evidence was showing us that it was stabilising and that the number of problems we were experiencing was reducing and I didn’t believe that it justified a rewrite, but it’s not my decision alone. That would have been discussed with Mike Coombs and the board in general – not the board in general, the ICL Pathway management team.
Mr Blake: Who would that be?
Terence Austin: That would be Mike Coombs, John Bennett and the other people in the room: Tony Oppenheim, Mike Bennett, all the people in the ICL Pathway management team.
Mr Blake: Can we go back to the page itself. So we have the management team members there but you are down as the owner there?
Terence Austin: I was down as the owner but that’s not a decision I could have made alone.
Mr Blake: If we keep on scrolling on this particular document there are more tasks there, more recommendations, but you will see that your name is in the management level there rather than the owner, so that’s – I think it’s fair to say the key corrective action or recommendation that you were the owner of was that one about the PinICL, the EPOSS system?
Terence Austin: Yes, without doubt. There were others – there’s one at the bottom of that page which was down to me.
Mr Blake: Yes. Can we look at WITN04600104 please. This is the same report but a bit later. It is version 2.0 and it is dated 10 May 2000, so it’s six months later. Can we go to page 6 and do precisely what we did on the last document, which was scroll through. You will see there, 3.2, for example, by that stage had been closed. We can scroll to the next page. Those early documentation ones, I think they were all closed.
Then it is page 9 where the 4.2.1 appears, and that’s what we saw last time, but if we scroll over the page, it has been updated. Thank you very much. Again, I’m going to need your help with a bit of interpreting here, I think. If we could look at the right-hand side of the screen, perhaps we could blow that side up.
8 December:
“JH [that’s Jan Holmes] requested statistics on fixes delivered to live from RM.”
Who was “RM”? Might that have been Royal Mail, I wasn’t sure?
Terence Austin: No, no. It could be release management.
Mr Blake: “Also informed [yourself] that requires agreement of [Mr Coombs] before this can be closed.”
Terence Austin: Absolutely.
Mr Blake: So Jan Holmes there is asking for statistics on fixes before he can be satisfied that it should be closed.
Terence Austin: Yes.
Mr Blake: Then we look at 8 December:
“[Mr Coombs] confirmed that unless [maybe release management] statistics contradicted reports provided by PJ …”
Is that Mr Jeram?
Terence Austin: Peter Jeram, yes.
Mr Blake: “… the recommendation could be closed.”
Nothing is disclosed in December and nothing is closed in January, February, March and we’re in April now, 7 April. There’s, again, an email to Mr Coombs, yourself and Mr Jeram:
“… providing details of [release management] EPOSS fixes to live. Asked for confirmation that matched PJ reports. If does then will close.”
So was confirmation given before 10 May of the sort that Jan Holmes was requesting?
Terence Austin: If Mike closed it, then yes.
Mr Blake: Well, we will see the basis on which it was closed but it does seem like quite a few months have passed and the kinds of statistics that were being asked for there weren’t produced, or there seems to be some sort of issue because we go through, as I say, December, January, February, March, April –
Terence Austin: No, I don’t think it’s – excuse me, it’s not – I don’t think it’s suggesting that. I think it’s suggesting that, through the observation period, while further testing was going on, that the statistics didn’t – demonstrated that the product had stabilised and was no longer producing the kind of problems it was before. So it’s a case of saying that – Mike’s saying that “If I can see statistics from release management that support the recommendation, then I will authorise the action to be closed”.
Mr Blake: It certainly seems as though, throughout early 2000, at least, he wasn’t getting those statistics, would you agree with that?
Terence Austin: I – there is an inference of that, but I can’t recall that.
Mr Blake: We’re going to return though document but perhaps we can just go to FUJ00058190, please. This is the ICL Pathway Monthly Progress Report for February 2000. Is this the kind of document that you would have seen at the time?
Terence Austin: I used to write one of the sections of it.
Mr Blake: Can we look at page 5 of that report. Thank you very much. So rollout is on track by that stage:
“We have now exceeded 4,000 post offices and are achieving the targeted 300+ implementations per week. This is a tremendous performance …”
So at that point, February 2000, quite rapid acceleration of the rollout.
Can we look at page 6, please. There is a heading “New Business”:
“Now that Acceptance has been achieved and National Rollout and Customer Service are seen by [Post Office] as going well, there are positive engagements now starting on new business.”
So it seems as though there is movement towards focusing on new business, by that stage. Would you agree with that?
Terence Austin: That’s what it implies, yes.
Mr Blake: Can we look at page 24 of this report, and please do tell me if there’s something that you recognise that you wrote – if this page 24, for example, is something that you wrote, then please do let us know?
Terence Austin: No, it’s not. My section is the one headed “Development”.
Mr Blake: Okay, so this is “Acceptance Loose Ends”. Do I take it from that that those are certain things that haven’t yet been resolved?
Terence Austin: It would appear that way, yes.
Mr Blake: Can I read to you that second bullet point. It says:
“We have dealt with queries from POCL concerning AI376.”
That was the lack of data integrity AI:
“One formal letter has been responded to attempting to avoid the conclusion that we had not found EPOSS reconciliation incidents that we should have found or that we have not reported those we did find. In reality CS are greatly hampered in ‘spotting the incident’ because the reports have not had fixes implemented and report large amounts of do-nothing information. We have attended the Release Management Forum and proposed some reordering of the fix backlog, but it will be at least until the first week of March before this situation improves.”
So, I mean, the impression that you get there is that, despite the rollout going and progressing rapidly, there is some dispute about under-reporting from ICL. Do you remember that, or is that a fair observation in relation to that paragraph?
Terence Austin: “CS” is customer service and what we were doing at this stage was it was moving from a development kind of project into a customer service project, so it was a transformation. This is what often happens in IT programmes. Once they have gone through an intensive development phase they have to move into a system support service management kind of environment.
To do that, you need a completely different organisational structure and you need different skills and such-like, and Stephen Muchow who was the service manager, this is his report, and it’s – it would appear to be doing – he is reporting against the helpdesk and the flow from the helpdesk through and how fixes are being identified.
I was right at the end of the chain, if you like, so when you get the helpdesk, which was a mixture of experts on both POCL and ICL Pathway, and that’s where some of my team ended up moving towards second line and third line within that, and we would also work on the helpdesk occasionally, so they were no longer reporting into me, they had moved across into a service management environment. So what this is doing, it seems to be suggesting that Stephen at that point is not happy with that process.
Mr Blake: But does it seem that in early 2000 there were some allegations from the Post Office that ICL Pathway weren’t reporting as many incidents as perhaps they should have?
Terence Austin: I don’t believe that to be true. We reported everything.
Mr Blake: But do you remember an allegation of that sort?
Terence Austin: No, I don’t, actually.
Mr Blake: “CS [customer service] are greatly hampered in ‘spotting the incident’ …”
I mean, were there issues in early 2000 with really spotting incidents amongst your team?
Terence Austin: Well, that’s written in a way – it says customer services “are greatly hampered in ‘spotting the incident’”, and I don’t understand that statement. I genuinely don’t understand it. I can only guess and speculate that it is to do with – well, it’s saying “spotting the incident”. The incident would be reported to the helpdesk, so I think it could be saying that the team that was in place at the time were struggling to identify where the problem is.
Mr Blake: Can we go back to WITN04600104 and to page 10, please. Thank you very much. Sorry, could we go to one page before that – and over the page. Sorry, other way. Perfect, thank you very much.
So I put to you earlier about late 1999/early 2000 is seems as though – the inference, as you agree, from that document is that there’s some sort of problem in producing the statistics that have been asked for by Jan Holmes and, set against what I have just shown you, I mean, would you accept that it looks as though there’s some sort of issue going on in early 2000 about providing accurate information about the number of incidents?
Terence Austin: Yes, they should – there was, there was. It would definitely imply that there was an issue there. I can’t recall what the issue was, no I can’t.
Mr Blake: Then there was a reminder on 3 May and then 10 May you have this, and this is a response received from Mr Coombs:
“As discussed this should be closed. Effectively as a management team we have accepted the ongoing cost of maintenance rather than the cost of a rewrite. Rewrites of the product will only be considered if we need to reopen the code to introduce significant changes in functionality. We will continue to monitor the code quality (based on product defects) as we progress through the final passes of testing and the introduction of the modified …”
Is it C14 or CI4? It’s a fix of some sort?
Terence Austin: It’s a release of some kind, yes.
Mr Blake: Yes. Let’s say CI4:
“… codeset into live usage in the network. PJ can we make sure this is specifically covered in our reviews of the B&TC test cycles.”
Then it is closed on the 10th. So it says “Effectively as a management team” you have decided – who was the management team?
Terence Austin: Well, the management team was the people in ICL Pathway. That would be people like Peter Jeram, myself, Mike Coombs and Stephen Muchow and various other people.
Mr Blake: Now, by referencing the management team there, by the sound of it the decision of management might have been taken contrary to those lower down the chain. Would you accept that? Were there, for example, people within the team who were really saying at that stage “We really need to rewrite this product”?
Terence Austin: There could be some programmers, yes. Yes, there was – there was a difference of opinion, without doubt.
Mr Blake: That was a different of opinion between management and those –
Terence Austin: No, there was a difference of opinion within the technicians, so the problem I had as a manager is I was getting contradictory information. I was getting a view that was – from the PinICL viewpoint I could see the product was unstable and when I’m trying to identify what the issue is and what we’re going to do about it and talking to the various people, there was two different views: there was those in the team that felt it should be rewritten and those in the team that felt that we should focus our efforts in certain aspects of the products.
Mr Blake: Do you think those who felt it should be rewritten were in the majority?
Terence Austin: I don’t know, but they were just equal on the people I spoke to.
Mr Blake: I mean, the reference there to management team suggests at least that it was management who thought it shouldn’t be, but perhaps those below thought it should be?
Terence Austin: As I said originally, there would have been people, programmers, who may have felt that it was the right thing to do.
Mr Blake: Can we look at your witness statement, that’s WITN04190100. Side by side if we can, but if we can’t that’s not a problem. It is page 12 of your witness statement, paragraph 26. Thank you. So it’s about halfway down that paragraph you say:
“The option was debated at length by senior members of the ICL Pathway management and technical teams and the outcome was that we should embark upon a major exercise to target the specific areas known to be the source of most (circa 80%) of the issues identified which were error handling and printing. If this approach was unsuccessful, then a rewrite would be the only option available. However, the product did become stable and the number of outstanding defects did fall within the levels defined in the acceptance criteria.”
It may be suggested that that is slightly inconsistent with what’s being communicated by Mr Coombs. I will run you through where those inconsistencies may or may not lie.
You have said in your statement, for example, it was debated by members of management and technical teams and, as I say, Mr Coombs seems to focus on the management team. Again, do you think it is possible there that it was the technical teams who were in favour of the rewrite and management who weren’t?
Terence Austin: No, no. The technical teams means the people in my development and design – architectural design and development, who I had the most confidence in and we would thrash, looking at the facts and decide what was the best option forward. So they were the – comprised of people like Alan Ward who was my chief architect. They would comprise of people like John Hunt who was one of the consultants on the team. Steve Warwick who was the expert in EPOSS and Pete Jeram who was the development manager at the time. So that’s what I mean by the “technical team” is that we would have pulled in people that we had confidence in and we would thrash out what we thought was the best way forward.
Mr Blake: Amongst those names that you have mentioned, were they all in favour of a rewrite?
Terence Austin: No, none of them were.
Mr Blake: Your explanation in the witness statement seems to focus on what we know as AI298, that’s the overall stability Acceptance Incident. Would you accept that there were other issues, such as cash account imbalances, whether caused by what we know as AI376 or something else at that time, which were still occurring and still related to the EPOSS product?
Terence Austin: That’s right. What I’m implying in my witness statement is that, if you like, we were judged on acceptance and acceptance was whether the product, the overall product met the business requirements as stated in the functional specifications, the business requirements specifications, and whether it met the criteria for the number of defects and errors that were still available in the product.
If we achieved that, which was – if I recall was zero As and ten Bs or – and no restriction on Cs at that point, then from that perspective we have met the criteria on two fronts.
Now, if the decision we had made was – wasn’t the right one, then it would have shown up in that and we would have failed acceptance, so that’s what I’m implying in my witness statement, is that we wouldn’t have achieved acceptance.
Mr Blake: So would you accept – and I think others such as Tony Oppenheim have said this – that there would still be some circumstances where it wouldn’t be possible to identify what has gone wrong?
Terence Austin: One of the biggest difficulties with the instability issues was, in the 1990s, that you – some of you, forgive me, may recall in the ’90s if you had a PC that actually it was very subjected to blue screens and lock ups.
I mean, nowadays you never see a blue screen, but Windows NT in the ’90s, you would get a blue screen and trying to track down what had caused that in such a complex system as Pathway was extremely difficult because a lot of the blue screens we were experiencing were at the counter, frustrating the postmasters considerably, understandably, but trying to understand what was happening at the time – because the blue screen would then – you would reboot it and it would go away and, as most of you know now, even a common solution to a printer or a PC or a laptop is just to switch it off and switch it back on again, but when you’re in a distribution system, switching it off and switching it back on again, which is a reboot, we want to find out what the problem is.
We have no way of seeing the counter. We can’t get onto the counter to have a look at it and we can’t take what we used to call “dumps” or “print-outs” of the store, the message store to try and see what caused that issue.
So that was a constant thorn for us to try and – we would get a lock-up or a freeze and all you could suggest to the people was that “We will try and find” – and we did find quite a few of them and it was down to two or three very, very clever individuals that managed to track down what some of these were and they were quite obscure. So that’s what I’m referring to is that the stability one was to do mainly with blue screens and freeze – and lock ups and the AI376 was to do with balancing the cash account.
Mr Blake: Absolutely, so your focus in that particular passage as well is on AI – what we know as AI298, that’s the overall –
Terence Austin: It’s on the stability one, yes.
Mr Blake: But you clearly accept at that stage there were other issues, especially with the EPOSS product, that were continuing, even if, as you say, it may have been circa 80 per cent that was the overall stability issue?
Terence Austin: Yes, but we – during the period from there onwards we focused on PinICLs. I called – I introduced a – during the – when these PinICLs were being raised and the problems on reconciliation and freezes and lock ups were being identified, we had what we called “morning prayers” and every morning at 8.30 am all the top people in my team would meet and we would go through the latest incidents and the ones that we had – previous incidents, find out what progress we had made on the ones that we had identified previously, and any new ones overnight – the previous day and then we would decide, during that meeting, the course of action and then we would meet the next day. We did that day after day after day for many weeks.
Mr Blake: Absolutely. I mean we’re here in – this is May 2000 so –
Terence Austin: This is closing down something in May 2000. It’s not – and it’s as a result of what’s been going on and what Michael is saying there is that there was no evidence to suggest that it shouldn’t be closed.
Mr Blake: Your evidence is that, after closure, there were still a number of incidents still continuing and you had dedicated –
Terence Austin: No, no, no, that was before that.
Mr Blake: So after May 2000 there weren’t incidents?
Terence Austin: No, there would still be incidents, there’s always incidents in a system of that size but they were being monitored through the helpdesk and down through the support channels.
Mr Blake: But by May 2000 your focus had been on AI298 in particular?
Terence Austin: And – well, 376 as well.
Mr Blake: But 376 you would accept continued?
Terence Austin: We were looking at all issues identified by – coming down through all PinICLs, all incidents that had been raised on the EPOSS product at that point and we were focusing on every one of them. So we didn’t leave these to one side, or – every one that appeared like it looked like it was EPOSS – and quite often it wasn’t EPOSS, it was either to do with the TIP interface or it was to do with the processes or it was to do with reference data, or it was to do with migration or some kind. Just because it was identified, that was where the source of the problem existed, that didn’t necessarily – that’s where the source of the fix existed.
So I would bring everybody into my office and every morning, witnessed by senior Fujitsu test and diagnostic experts that came over from Japan and were allocated by Fujitsu who sat in my meetings to watch me and decide whether they were happy with the process. So I was under a lot of scrutiny there and I personally wanted to see and get this sorted out. It mattered an awful lot to me to get it sorted out.
Mr Blake: So are you saying that throughout the year 2000 it was well-known in Fujitsu, including people who came over from Japan, that there were –
Terence Austin: We’ve got a timescale problem here. May 2000 is at the end of that period not the beginning. I’m talking about the period prior to that when we were doing model office testing, end to end testing, acceptance testing and live trial.
Mr Blake: So by May 2000 it all suddenly stopped?
Terence Austin: No, it – EPOSS was not providing the kind of problems that would justify rewriting the code. That’s what Mike’s saying.
Mr Blake: So it wasn’t providing sufficient problems to justify rewriting the code?
Terence Austin: Correct.
Mr Blake: But it was still providing problems?
Terence Austin: As were other parts of the system, yes.
Mr Blake: But you would accept that the EPOSS was still an issue post May 2000?
Terence Austin: Well, it depends what you mean by an issue. There were problems, defects which were being dealt with in the normal support way.
Mr Blake: I mean given all the information that you received over those two years, so starting from that Holmes/McDonnell report in 1998 and then the report in 1999 and the issues in early 2000, didn’t you think that it might have been the time to start thinking about rewriting EPOSS?
Terence Austin: I did, I did, several times think about it and I was persuaded by the technicians working on the product that they felt they could sort it out.
Mr Blake: Were there any particular technicians who you felt persuaded you?
Terence Austin: Steve Warwick, in particular, because he knew the product better than anybody else.
Mr Blake: Let’s look at FUJ00079333, please. Now this – the top email, the top two emails, are emails of 10 May 2000 in the evening, 6.36 pm, 6.28 pm in the evening of 10 May, so it looks, certainly from this – from the time, that that was after the issue had been closed; would you agree with that? Do you remember was there a meeting in the daytime, or discussions in the daytime, on the 10th to close the recommendation?
Terence Austin: I can’t recall, but it – this seems to be after that, yes.
Mr Blake: Now, let’s look at that second email on the screen, so this is an email from you. In fact can we go over the page. We will start with the original request, so this is actually before the closure, so this starts in April, 27 April. Do you remember who Pat Lywood was at all?
Terence Austin: No.
Mr Blake: So these are current issues –
Terence Austin: Oh, I think Pat Lywood was someone that went – that was in the customer services support line.
Mr Blake: It says “Current issues on”, and that’s I think either C14 or CI4 EPOSS, and can we look – halfway down the screen we can see there “Balancing process overheads”:
“After migration to CI4 a new process is introduced to the cash account process. Every office will be required to declare non-value stock. If the office fails to do this process he will not be able to balance or complete the cash account.”
Then it says that:
“Paul Westfield and I will ensure this is included in the backfill training provided to the existing offices.”
Then further down there’s reference to “Risk of code regression”, that’s another heading:
“There may be fixes that have been produced and delivered into CI3 that have been missed from CI4.
“I will take this up with Dave Royle and ask for assurance that all clone PinICLs have been tested. I will supply a list of the PinICLs that we have tested in CI3R release.”
So that’s the start of the chain and, if we go to page 1, Stephen – is it Muchow or?
Terence Austin: Muchow.
Mr Blake: At the bottom of the page, sorry. He sends you an email, again on 27 April, so before the closure of the EPOSS issue, and he says:
“I am particularly concerned with the risks of degraded counter and cash account performance and of code regression between CI3 and CI4.”
Then you respond in the email above that – and one thing that may become relevant in due course, Gareth Jenkins is copied into that email – and you say at 6.36 on 10 May, so presumably after the recommendation has been closed:
“Steve, I share your concerns regarding counter performance and code regression. To that end we are focusing on those areas of functionality where we appear to be experiencing performance degradation and attempting to establish where the problem lies. I have been personally aware of these problems for several weeks and would not expect CS to authorise CI4 unless these issues were resolved. I have raised the issue of extra work during weekly balancing with Mike who will be discussing it with Dave Smith. This has been introduced by POCL to support LFS.
“I cannot give you a 100% guarantee that code regression will not occur at CI4 because, by its very nature, it is not fully automated and never will be. However, our end to end processes are designed to reduce the possibility of this occurring to an absolute minimum and I have recently requested a reconciliation where it is possible to do so.”
So you have said there that there’s a problem that you have been aware of for several weeks and you cannot give 100 per cent guarantee that code regression won’t occur, keep it to a minimum. Code regression, that’s similar to code decay, is it, but it means, I think, that by fixing one thing, it could break something else that was working before?
Terence Austin: Yes. It’s not decay, no. Code regression – we used to have a testing sequence called regression testing and whenever you put a fix into a product of any kind you will subject it to regression testing to see that you haven’t undermined or introduced another problem, or affected something you had already done, hence the reason it is called “regression testing”, to ensure that you have not regressed the problem.
So the problem is that, when you’re fixing faults, you cannot guarantee that you haven’t caused a regression because it’s technically – if a programmer puts the fix in, he does it, he tests it to his ability, it then goes into regression testing and regression testing says it’s okay. It then goes into the live environment and because you have assembled far more of the system at that point, there’s so many more moving parts, then you may – another error may crop up. So some regression may – that may well happen and that will be – that is the case with every IT system I’m aware of.
Mr Blake: Is it a bit like Whack A Mole, where one problem comes up, you try and fix it and then something else pops up somewhere else?
Terence Austin: You may have inadvertently – by fixing the problem you may have re-introduced something else or you may have knocked on to some other part of the programme that the programmer didn’t release.
Mr Blake: As I say, the evening that that recommendation about EPOSS was closed, I mean, there may be some people asking how could you close that recommendation knowing all that is contained within that email?
Terence Austin: This is to do with performance. This is to do with performance degradation. This is not to do with EPOSS degradation. It’s another issue. What’s happening is that we’re noticing that the time it’s taking on – the counter performance on its response times and the time it’s taking to do the cash account is degrading and that is a performance issue. What – we don’t know and we’re trying to find out what’s causing that, so that’s why I was aware of it, is because I had been aware that it was happening but we were finding it extremely difficult to reproduce it in the laboratories.
Mr Blake: But if we look at the subject, it’s – C14 was a particular fix on EPOSS, so it was a problem that was fundamentally on EPOSS?
Terence Austin: It was on EPOSS but it was a performance element. What it says is regarding counter performance and code regression so was there something happening where the code was regressing which was causing the performance to get worse? So that’s the question that I couldn’t guarantee and what Steve is asking the question.
Mr Blake: Presumably, those issues could have real life implications for those who were trying to balance, for example?
Terence Austin: Yes, yes. I mean, I was very concerned that we – it was taking longer to do the account balancing at the end of the day than it should.
Mr Blake: But do you think that these kinds of issues should have been raised with Jan Holmes before closing that incident on that day?
Terence Austin: We didn’t have – we didn’t have any PinICLs. It was something that I was aware of that what appeared to be happening – there was no proof, there was no evidence. All that we were getting was a feeling that the counter seemed to be degrading in performance while we were going through this work, and this is – Steve’s making the same point, so it – I get where you’re coming from, but we would have seen these as two different issues.
In hindsight, maybe – I can accept the point you’re making is that maybe the fact that these were starting to occur, we should have perhaps raised them during that, but we weren’t – at the time that Jan wrote the original report and the time that Mike – we had no evidence that it was – I’m not being very clear here.
What I’m trying to say is we couldn’t – we didn’t know what was causing the problem and we didn’t know what extent the problem was either.
Mr Blake: Do you think that might have been something to tell Jan Holmes?
Terence Austin: (Pause) The reason I’m hesitating is I think you’re probably right. In hindsight, you’re probably right, but counter performance and the time it was taking to do something we used to look at in a different way. We didn’t – it could have been for a variety of reasons. It may not have been anything to do with the EPOSS product. It may have been to do with the way that the counter was booting in the morning. It could have been all sorts of things that may have been causing that to happen, so it wouldn’t – it wouldn’t necessarily be pointing at EPOSS.
Mr Blake: But you’re talking there of code regression as well as counter performance so –
Terence Austin: Yes, but that could be code regression anywhere in the counter. He is talking – he is saying EPOSS – and Steve wasn’t a technical guy, so what – it’s terminology being used there. I have responded in saying – because I know what he is referring to – that it was to do with counter performance and potential code regression, but that’s not necessarily just EPOSS.
Mr Blake: One of your solutions to the EPOSS problem though was to implement fixes along the way, rather than rewriting, so presumably every fix, there’s potential for code regression?
Terence Austin: Yes, see, I know that we found out what was causing this and it wasn’t EPOSS. So that’s the point I’m trying to make is there’s several elements – if – you may have already seen, if you have seen a technical environment description of the system, there are several elements that sit within the counter and one of the issues in the ’90s was trying to get any system to boot up with all the mass of software that had to initialise in there, and things like the counter slowing down could have been – as I said, it could have been to do with any product within the counter that was causing that, not necessarily EPOSS, and we did resolve this problem. As far as I can remember, we did resolve the problem.
Mr Blake: I want to take you to a PinICL. It will only take 10 to 15 minutes. Would you like to break now or can we break after I have taken you to that, because that’s the end of my questioning on EPOSS issues?
Terence Austin: No, we can carry on.
Mr Blake: Thank you very much. Can we look at FUJ00067416, please. It’s a PEAK rather than a PinICL. For those who have been following this Inquiry, this also appears within the expert report at page 157.
Now, I’m going to need your help quite a lot with this because it’s not very easy to understand, but can we look at 16 May, so the first entry. This is six days after that EPOSS issue was closed. It says:
“The host generated cash account line comparisons report dated [15 May] where post office 169207 has a difference in the receipts and payments total for cap [that’s cash accounting period] 06. Please investigate.”
Now, the third entry there, can we just scroll down slightly, so it’s 19 May – actually it’s the fifth entry, sorry:
“This office has had big problems with its receipts and payments. [Cash account periods] 5, 6 and 7 did not match. The differences are …”
It gives the difference:
“The office has already reported problems balancing which are being investigated by development …”
So big problems being identified and I think if you look at two entries down there’s another report on 19 May, receipts and payments issue in CAP7.
Can we go to 24 May, that’s over the page, page 2. You so it says there:
“The cause of the problems in all three [Cash Accounting Periods] at this outlet was the fact that Stock Unit DD’s rollover records from CAP5 to CAP6 represented a ‘nil’ balance (the total stock holding was nil, no receipts or payment transactions were recorded) despite the fact that the stock unit had been trading normally during this period. This issue was raised in PinICL 43811 and is still under investigation within the EPOSS development team.”
Was that your team, the EPOSS development team?
Terence Austin: No, not at that stage. As I said to you, it had moved over into a support environment and I wasn’t responsible for the team at that point.
Mr Blake: But there was a specific team dealing with problems with EPOSS on 24 May –
Terence Austin: Yes.
Mr Blake: – and they dealt with issues to do with –
Terence Austin: Absolutely.
Mr Blake: – balancing issues.
Terence Austin: Absolutely.
Mr Blake: Can we look at the entry on 30 May, that’s one entry down. There’s more information there about further investigation. I’m not going to read that out. Perhaps if you could just take a short period just to have a quick look at what it says there.
(Pause)
Mr Blake: Then if we go down to the bottom of the page there’s an entry of 4 July. Can we just scroll over to the next page. At the top of the next page seems to be an explanation:
“This problem is the same that already resolved in PinICLs 37884 & 37663, namely that of DataServer not tree building & populating correctly. A diagnostic has been put into DataServer to detect any such problems.”
That’s the explanation.
Can we look at 12 July. This is where it becomes difficult to understand and I’m going to need your help if you’re able to, on page 4, the entries from 12 July. Can I ask you just to read to yourself those entries briefly.
(Pause)
Mr Blake: If you’re able – if we could carry on scrolling perhaps, because there’s another entry on 12 July at 12.29. Can I ask you to read that final entry.
(Pause)
Terence Austin: Right, okay.
Mr Blake: Can you help us, it seems as though what they are trying to do is work out how to reproduce the cash account as it should have been prior to an error; is that right?
Terence Austin: That’s true, but they also believed that they understand what has caused the problem, which is pretty obscure.
Mr Blake: Yes. Can we have a look at the next page, 8 August, halfway down the page 2.35 in the afternoon on 8 August:
“I have spoken to Martin McConnell who advised call to be routed to EPOSS …”
That’s, again, that EPOSS team, is it?
Terence Austin: I don’t know what FP stands for because, at that point, as I said, it’s not within my chain.
Mr Blake: Can we go over the page to 13 September, please. There are two entries on the 13th. If that first one could be – perfect, thank you very much. Again, I’m going to ask you to read those to yourself. I mean, I will read just very briefly the first one. It says:
“It proved to be very difficult to resurrect the cash account data for week 5. Steve Warwick’s analysis tool showed that not only was stock unit DD corrupt but also stock unit XXX. EPOSS nodes … were missing and had to be resurrected.”
If I could ask you just to have a quick look at that and then also the one below that.
(Pause)
Terence Austin: Yes.
Mr Blake: And the one below, sorry.
(Pause)
Terence Austin: Yes.
Mr Blake: Are you able to briefly describe what you think is going on there?
Terence Austin: There was – it would appear that they have come to the conclusion that something had kicked in on archiving from the counter, which caused the problem, and it is that – as I said before, that’s obscure for that to have happened and, as a result of that, it’s caused this impact and then it would appear that they are struggling to be able to reproduce the cash accounts and the figures that would balance them off and they’re suggesting the way in which they can move forward on it.
Mr Blake: Can we go to the final entry on that page, and it goes over the page, so this is 14 September 2000. I will read this one. This is an entry that says:
“Thanks for all the effort. For the time being I have agreed that reconstructed cash accounts will not be needed all the time, but only by special request of POCL.
“I have already issued the final BIM report.
“As such please close this call, and hope for the best with the CI4 code which should make this type of incident very rare.”
So, I mean, here we are in September 2000 and the approach is “Let’s hope for the best”. I mean, is “hope for the best”, is that what you decided to do in terms of the rewrite of –
Terence Austin: I was not responsible for this –
Mr Blake: No, but “hope for the best” was that the kind of attitude that was taken in respect of the EPOSS product back in May: hope for the best, hopefully it will be very rare?
Terence Austin: No, no. The data that had been received prior to May, which resulted in Mike suggesting that it should be closed, didn’t suggest – it suggested that we had resolved the issue. There were still going to be problems because of the sheer nature and scale and complexity of the project, but the original issue which was to do with error and printer handling and cash account balancing, we believed that in the majority of instances, 99 per cent of the – we had managed to sort it. That’s what Mike was referring to.
We knew – well, we didn’t know but, as a result of this, which I had no involvement with whatsoever, but a very obscure incidence of where an archiving programme kicked in, which caused this problem – it shouldn’t do, but it did and it seems to be something to do – between Riposte and the archiving suite that caused this. And these are the kind of problems you get in large systems and the idea is to try and track it down.
It would appear that what they’re saying is this shouldn’t happen and it may happen again, but if it does it would be another PinICL. We would have to look straight into it straightaway, if it happened, is what they’re saying. “Hope for the best” is it should sort itself out in C14, is what he is suggesting. It’s not terminology I would have used but –
Mr Blake: “It should sort itself out” is, in fact, a phrase we have heard quite a lot of, especially during the human impact stages. Was the general feeling that things will sort themselves out?
Terence Austin: No, no. Okay, my terminology wasn’t very helpful there, but what I’m trying to say is somebody – I wasn’t responsible for C14 or – I don’t know what it was, sorry, so I can’t be helpful on that. I don’t know what it involved. I don’t know what was in there. There may have been a lot of fixes put in there.
Mr Blake: Can we look – and this is the final thing before the break – at FUJ00080690. It is the first document that I took you to today. Can we look at page 7, please, and at the top of page 7.
So in 1998 you were being told that there were hundreds of fixes, code decay, the system was unstable, no guarantee it won’t adversely affect another part of the system. I mean, looking back at that paragraph and knowing what you know now, do you think you should have agreed to rewrite EPOSS back in 1998 or 1999?
Terence Austin: The best advice I was getting at the time was that, if we were to rewrite, did we have the – did we have the people to do it, did we have the expertise to do it and, by doing so, would we run the risk of just creating another problem because one of the reasons why this got into this situation is that we were forced to do rapid application development and, by doing that, you haven’t got a functional specification, you’ve got what we call – you’re talking to people and you’re trying to get EPOSS to sit along – POCL people to sit alongside you and the problem was that we had people who were working in that environment that weren’t very professional and weren’t very good at their job.
So I was convinced by the people that were giving me the evidence that it was a certain part of the EPOSS product that was responsible for a very large per cent – we say 80 per cent but it could have been 90 per cent. I was measuring whether that was a good decision by the number and type of PinICLs that we were getting, come the live trial, and that’s how I measured, personally, whether that was the right decision to do.
If the product had been as bad and Steve, for example, and others had been wrong, then we would never have got to that stage. We would never have got to the acceptance situation and number of PinICLs. We would have had a product that we would have had to have rewritten.
Mr Blake: Do you think that you listened enough to the members of the team who were urging a rewrite?
Terence Austin: The reason I’m hesitating is that I believed I did. I believed – to their argument. I listened to their argument and so did some of the people who were more technical than I was. I believed that everybody was given an opportunity to give their view of what should happen. They believed that we should rewrite it and there were other people that thought that we shouldn’t.
Mr Blake: Once you had taken the decision not to rewrite, did you sideline those who were urging a rewrite?
Terence Austin: Not as far as I’m aware. No, not – I don’t believe so.
Mr Blake: By May 2000, so that was the date when the recommendation was finally closed, presumably that was far too late then to start thinking about a rewrite, given the number of Post Offices that already had the system in place?
Terence Austin: No, it wasn’t too late. I mean, you could rewrite a product over a period of time to match the user interface that the postmasters were used to. You could replicate that functionality in parallel and then release it at a later date if you felt that was the right thing to do.
Mr Blake: At no point did you feel that that was the right thing to do?
Terence Austin: Not during my time. I didn’t have – I’d have sufficient evidence to suggest that that was the right thing to do. The ones that you pointed out that were picked up later were very obscure situations. There was nothing there to suggest it was a rewrite.
Mr Blake: Thank you.
Sir, I think that’s an appropriate time for a ten-minute break.
Sir Wyn Williams: Yes, fine. What time shall we resume?
Mr Blake: I think we can actually – we can come back at midday.
Sir Wyn Williams: Midday, all right. Have a break, Mr Austin, and don’t talk about your evidence, although I’m sure you won’t think of it at any rate.
Terence Austin: Thank you.
(11.40 am)
(Short Break)
(12.00 pm)
Mr Blake: Sir, we can see you now.
Sir Wyn Williams: Good.
Mr Blake: Mr Austin, I only have about 15 more minutes and then I’m going to hand over to Mr Stein and Mr Henry to ask you a few further questions.
Briefly, while we’re on EPOSS, I want to ask you about RAD, rapid application development.
We know from a report that was sent to the Post Office by project mentors – the reference there is POL00038829 but we don’t need to bring the document up – that Pathway started with rapid application development methodology, but that appears to have been discontinued after a staff member left the project. Do you know anything about that at all?
Terence Austin: Yes. Yes. It was not proving to be very successful. Not only was – one of the staff members left but also it did depend – it was very dependent – had dependence on POCL providing experts that to define their requirement, so – and that was very time-consuming for POCL and POCL didn’t feel that they had enough people to fulfil that role. So we decided to reverse engineer and produce a document that then could be used to use a traditional waterfall approach.
Mr Blake: So I was going to ask, an advantage of RAD is that it can get something working as quickly as possible, but it relies on later iterating and replacing –
Terence Austin: Absolutely, and that – it was also obvious that POCL, as a customer, were not comfortable with that because it meant that it wouldn’t be fully functional. So you would be putting out a series of releases over a period of time and they wanted a fully functional system and RAD was not the right way to do that.
Mr Blake: I think the basic prototype framework in an RAD isn’t used, ultimately, in the main build of the system; is that right?
Terence Austin: Well, nowadays it is, but I can’t recall – because RAD, at that time, was quite an immature methodology, I was uncomfortable with it as an individual, as a development person, but I felt that it was still immature and I didn’t really understand how you got from A to B and how you got a system that represented what the user wanted.
I understood the mechanics but I didn’t understand how you achieved a product that would deliver to the customers what they wanted.
Mr Blake: Am I right to infer from some of your earlier evidence that you didn’t have some faith in some of the technical members of the team?
Terence Austin: That’s how it – when I saw – after requesting the task force, I was extremely disappointed and upset that we had ended up with a product which, on the face of it, looked like it was pretty bad. So yes, that – I was then put into a very, very difficult position because, going back to what we said earlier, it’s easy to say “rewrite the product”, that’s the easy option because you can just stand back and say “rewrite it”. That doesn’t necessarily mean you’re going to end up with something that’s better, it just means that you have said that’s the right thing to do.
Actually trying to get a product and fix it and make sure that it’s stable – and I genuinely believed that we had done that, and so I think that I was comfortable that the fact that we had taken that approach and we succeeded in getting the product – it had been a very rocky ride, but we had achieved that objective, I believed, genuinely, at the time.
Mr Blake: So what had happened to that original RAD product?
Terence Austin: Well, that RAD product was then enhanced. It was quite some way off what the functional requirement was needed to be, so we took it on from that viewpoint onwards and used it internally within the team.
Mr Blake: Did you have a final signed off design?
Terence Austin: Yes, in the end, yes. We had to, as I said, reverse engineer and we had to get some business requirements that were signed off by POCL, and a design that was signed off by POCL.
Mr Blake: I want to ask you about Post Office’s awareness of various issues. You have said at paragraph 32 of your witness statement that POCL were made aware of every defect in the ICL Pathway’s solution?
Terence Austin: As far as I was aware, they were.
Mr Blake: When you say “defect”, do you mean Acceptance Incident or do you mean more than that?
Terence Austin: No, I mean more than that. Every PinICL that we were going through that we had received, my understanding was – and I have no reason to think otherwise – is that we went through every one with POCL representatives.
Mr Blake: So every PinICL was –
Terence Austin: Except for the Cs, a lot of the Cs, but even some of those we went through as well, because every one the category had to be agreed.
Mr Blake: The PinICLs or the Acceptance issues? I mean, PinICLs are –
Terence Austin: PinICLs –
Mr Blake: – every incident –
Terence Austin: Yes, if it’s agreed that it’s an error, then the category of that error needs to be agreed with POCL.
Mr Blake: I mean, the kind of document that we saw, the PEAK, was your impression that those were being seen by POCL?
Terence Austin: Well, they were POCL people that were represented within the helpdesk, is my understanding.
Mr Blake: So it was through the helpdesk that you understood POCL obtained their information on problems with the system?
Terence Austin: Well, yes, being raised by the postmasters and any incident – and by POCL. Any incident raised by POCL, whether it be the postmasters or the managers elsewhere within POCL, would come and be raised as a PinICL through the helpdesk.
Mr Blake: Was there some sort of policy in place between POCL and ICL Pathway as to what level of information should be formally shared or informally shared?
Terence Austin: I’m not sure.
Mr Blake: Did you have any concerns about the sharing of information with POCL?
Terence Austin: In the early days, yes, because it was a PFI and, therefore, we had our solution and, therefore, we were there to deliver the solution in line with our – the requirements, so we wouldn’t necessarily share that information at that point.
Mr Blake: I will ask you about that stage shortly but, in terms of when it was all up and running, it was your belief that POCL had the level of detail that was contained in, for example, the PinICLs?
Terence Austin: Yes, yes. That was my understanding, yes. I had no worries about them seeing the breakdown of the helpdesk and the comments, and I believed that POCL were involved in that process.
Mr Blake: What about the other way round? You have said that Pathway wasn’t aware of POCL’s own systems?
Terence Austin: No, not at all.
Mr Blake: Did that cause you difficulty?
Terence Austin: I wouldn’t say it caused me difficulty. It was a bit like that – if we had a problem with the TIP interface, we – we didn’t know whether there were any issues with TIP that was causing that. We could see – when it was our side, we could see what it was saying and we would have to investigate and, quite often, we would find it was an error with TIP. The same would apply to CAP in the Benefits Agency, that we could see through the interface that there was an issue. We didn’t know what the issue was, we just see we’re having problems with the interface.
Mr Blake: I mean, you were designing an end-to-end product so, presumably, that was pretty crucial?
Terence Austin: Agreed.
Mr Blake: Where did that failure lie then?
Terence Austin: With the customers.
Mr Blake: Did you ask?
Terence Austin: Many times.
Mr Blake: And what was their response?
Terence Austin: They didn’t feel that it was appropriate.
Mr Blake: Let’s look at the invitation to tender. Your role in the procurement process, I think you have said in your statement, was to evaluate the system’s requirements in the invitation to tender to determine the resources that were required; is that right?
Terence Austin: That’s correct.
Mr Blake: Part of that was presumably working out how that end-to-end system could be achieved?
Terence Austin: Yes. So I would have to look at the business requirements, as defined in the ITT, and, again, it was a PFI, so we had already developed a solution and were the process of developing the solution to meet those business requirements, and so my task was to make sure that the product that we had was – the solution that Pathway had would be delivered within that time. That was what my job was.
Mr Blake: We have seen – I will give the reference but we don’t need to bring it up on screen, it is POL00031117 – Keith Todd produced a position paper in 1998, which said that POCL couldn’t reasonably have believed that the Post Office’s premises were fit for automation. Was that your view?
Terence Austin: Yes. It wasn’t just my view, but it was a view that I shared.
Mr Blake: Wasn’t it part of your job at that stage, that invitation to tender stage, to check things like that?
Terence Austin: Well, that’s how we found out, is by going in and then – with the implementation to go into the post offices and do the surveys and it was as a result of doing the surveys that we found that out.
Mr Blake: Wouldn’t it have been obvious from quite an early stage in the 1990s that many Post Office branches wouldn’t have had even computers?
Terence Austin: No, it wasn’t that, it was to do with things like power points, it was to do with desks that were suitable, it was to do with all the aspects of – as far as the surveys, the surveys were showing that a lot of the premises were not fit to be able to automate in the state they were in and required quite a lot of work in order to make them such.
Mr Blake: So some blame has been placed on the Post Office for that but it sounds as though you, ICL, were, in fact, carrying out your own investigations as to the state of fitness of the post offices?
Terence Austin: Well, we had to do surveys, that was part of – because if there was any additional work to be done in the post office, we were obliged to do it, so we went in to survey and then we commissioned the work that was necessary.
Mr Blake: Was that before the agreements had been signed with the Post Office?
Terence Austin: No, that was after.
Mr Blake: So wouldn’t it have made sense to do them before?
Terence Austin: We weren’t allowed to.
Mr Blake: Were you involved in preparing readiness before the contracts were signed and establishing what requirements might be required?
Terence Austin: We were – we had no reason to suspect that where the ITT wanted the system developed would be capable of accepting that. We didn’t find out until after the award of contract when we started to commit resources to the surveys and then the surveys were showing that quite a few of the premises needed a lot of work doing to them.
Mr Blake: Were surveys really – I mean, couldn’t you have looked at some post offices yourselves before signing the contract?
Terence Austin: Well, we did, but there were 19,500 of them, so you could only do a snapshot, if you were allowed to do so.
Mr Blake: And did you do a snapshot?
Terence Austin: We didn’t, no. As far as I know, we didn’t, but I can’t recall.
Mr Blake: Why not?
Terence Austin: I’m pretty sure we weren’t allowed to.
Mr Blake: Could they have prevented you from going into post offices?
Terence Austin: No, they couldn’t have done but they wouldn’t have been very happy if we had gone there. We would have had to have sought permission from POCL to do that.
Mr Blake: Keith Todd said that there would have been a view taken of the suitability of the post offices and he referred repeatedly to a full-time team that ICL had. Were you part of that team?
Terence Austin: Well, the implementation, yes – the implementation team would have been the team that was looking at that, yes.
Mr Blake: Who was head of that team?
Terence Austin: I can’t recall his name because they changed two or three times.
Mr Blake: At that stage, were you a senior member of that team?
Terence Austin: I was the Programme Manager, of which that team was part.
Mr Blake: Did you give thought at that stage to the fact that many post offices would use a telephone line connection?
Terence Austin: Yes, we – that wasn’t – if that was the case, we knew that wouldn’t work. We had to find alternative solutions to that.
Mr Blake: So did you foresee issues with ordinary phone lines being used, such as interference, et cetera?
Terence Austin: Absolutely.
Mr Blake: Did you raise those –
Terence Austin: Yes, we did, yes. We had to come up with different solutions for those post offices where that was the case.
Mr Blake: Can you tell us a little bit just what you recall of consideration being given to those kinds of issues at an early stage?
Terence Austin: Well, we had to come up with a satellite option. We had to come up with a different – we had to get ISDN lines into those post offices and we were given the impression by BT that we could get ISDN lines into any of the locations we needed to. It was only much later on that we found that BT were struggling to do that.
Mr Blake: Were you concerned about those that didn’t have ISDN lines?
Terence Austin: Absolutely, yes, and we had to find a way of trying to automate them.
Mr Blake: Because what kind of problems would it cause if they weren’t?
Terence Austin: Well, the connection wouldn’t be a good one. It would be – it just wasn’t suitable for a distributed IT system.
Mr Blake: Peter Copping told us that ICL had told PA Consulting that they had seriously underestimated the amount of work that was involved. Would you agree with that?
Terence Austin: Yes.
Mr Blake: Some witnesses have said that training was also underestimated by ICL. Is that something you would agree with?
Terence Austin: I would.
Mr Blake: Again, I mean, training was something that presumably you were considering at that invitation to tender stage?
Terence Austin: Yes, it was.
Mr Blake: What steps did you take at the invitation to tender and procurement stage to consider the level of training that was required?
Terence Austin: Well, we put forward our training. One of the issues that we had with training was that – and it remained a problem – personal problem, even though I wasn’t responsible for it in the latter part of the programme, but I couldn’t – I couldn’t see how you could roll out a system at the pace that we were rolling it out and also train people that had such a wide-ranging capability and I could appreciate that some of the postmasters and postmistresses would be horrified by the implementation of an IT system, especially that one day you’re manual and the next day you’re fully automated.
And I know that we looked at training these people for a long period of time to give them as much information as we could, but the issue was that, by the time they were scheduled to be rolled out, they may have forgotten it, which is quite reasonable. So we had to bring the training so that it got very close to their implementation, within a week or two, as my understanding because I wasn’t really into it – responsible for it, in order to overcome that issue.
But there was still the problem of basic training of IT, never mind the system which was quite sophisticated in what it did, and so how that was overcome and whether it actually was overcome, I don’t know.
Mr Blake: Do you think that training was underestimated at the invitation to tender and procurement stages by ICL?
Terence Austin: Yes.
Mr Blake: You have said in your statement at paragraph 5 that DSS and the Post Office were blissfully unaware of how unrealistic the timetable was.
Terence Austin: Well, they put an indicative timeframe and the only way that could be met was if the solution that we had got and we had defined and we wrote it up and we put it in a fully functional – functional specification and said “That’s the system that we’re going to deliver in that timeframe”. At that time there were 280 something agreements to agree and we believed that CAPS was ready to go and on that basis we demonstrated what our system was capable of doing and we defined it in a functional requirement.
What transpired was that that functional requirement was never approved by BA or POCL.
Mr Blake: It has been alleged that you obstructed the PDA in getting hold of certain information. It has been said that you had said that the contract prevented you from providing them with certain information.
Terence Austin: Well, that was the PFI. I mean I was – I was, if you like – not instructed but certainly advised by my peers and by my managers and seniors that a PFI contract meant that we were to be left to develop the system, that was our risk, our responsibility and whether we were successful or not would be proved by acceptance.
Mr Blake: And you have said at paragraph 10 of your statement that DSS and POCL were not ready, managerially or technically. Why do you think that?
Terence Austin: Because they couldn’t answer the questions we were asking. So if they had been ready, technically – they knew that we were interfacing with their systems so they should have people in place ready to front those questions and answer them and if we were having difficulties in saying – we needed to define an interface specification between ourselves and several other systems that we were interfacing with. With the ones with TIP and the ones with CAP we never got that specification to the level of detail that we needed and when we had issues we didn’t have people that could help us to resolve them.
Mr Blake: Do you think it would have helped to have shared more information with the Post Office?
Terence Austin: That was not in the nature of the contract, with respect. You don’t – when you’re carrying the risk then the customer is taking a view that they wish to transfer the risk to a supplier and that supplier then defines the system in the way that they want to define and therefore it’s not a waterfall approach, it’s not a standard contract.
You needed a fully functional requirement in order to do that.
Mr Blake: It may not have been part of the contract, but knowing now what we know presumably more information sharing at an earlier stage would have been beneficial, wouldn’t it?
Terence Austin: Whether I believed it or not, it’s not the nature of the contract and I did have to adhere to my peers in that way. It was not something that I could choose to do.
Mr Blake: Finally, you have also spoken about tensions between the DSS and Post Office. Where were you getting that information from and how did that impact on the work that you were doing?
Terence Austin: It was in meetings where they were – both parties were present and in memos and letters, if you like, in terms of emails and such. You could detect that there was a difference in their objectives and I suspected that was because the Benefits Agency were looking for alternative ways other than the Post Office for solving their problems and I think the Post Office were aware that that was a possibility.
Mr Blake: How did that impact the work that was going on at ICL?
Terence Austin: At my level it probably didn’t. It meant that I was being pushed in a certain direction by BA, if you like, as the senior partner, even though that may not have been in the best interests of POCL and I had to try and balance the two because as far as I was concerned I’m there to try and satisfy both parties.
Mr Blake: Thank you, Mr Austin. I am going to hand over now to Mr Stein and Mr Henry.
Sir, do you have any questions before I do that?
Sir Wyn Williams: No, no thank you.
Questioned by Mr Stein
Mr Stein: Mr Austin, I have a number of questions for you that relates to the operation of the system and the start up for it. My name is Sam Stein. I represent a large number of subpostmasters, mistresses and managers.
You were asked a number of questions by Mr Blake that touched on the question of whether the branch offices were going to be ready for automation. Forgive me for perhaps being rather direct about this: wasn’t it blindingly obvious that some rural branch offices would be totally incapable of automation from the beginning of all of this?
Terence Austin: Not to the extent that they were.
Mr Stein: Well, have you ever been to a countryside branch Post Office in your entire life before you started working on this project?
Terence Austin: Well, they have a counter, don’t they?
Mr Stein: Yes, but did you ever actually think about what the implications were for small rural places that are going to need to go from paper based into an automated base?
Terence Austin: Absolutely.
Mr Stein: Right, so why was that not brought into the thinking in relation to this project?
Terence Austin: Well, it was as far as I was concerned. It was a major issue.
Mr Stein: There appears to have been surprise from ICL that POCL weren’t aware of the possible demands of automation. If you were aware of it and you were not surprised by it and this was a matter that was concerning you, why didn’t you tell them to start off with?
Terence Austin: We did.
Mr Stein: Right, so you’re saying that you pointed out that some of these offices were not going to be suitable and you are saying that POCL just didn’t listen; is that right?
Terence Austin: No, sorry, I’m saying that training – I thought you were on training.
Mr Stein: No, I was asking about automation, I thought that was clear.
Well, what’s the answer? Are you saying that you were perfectly aware of potential problems with branch offices but you didn’t bring it to the attention of POCL or are you saying –
Terence Austin: Oh, yes, we did. Yes, we did.
Mr Stein: Right, so was that before contract was signed or after contract was signed?
Terence Austin: After the contract was signed.
Mr Stein: Right, why not before?
Terence Austin: Because I wasn’t given – we weren’t given the opportunity to do that, as far as I can recall, and I have to say we may well have done, I can’t recall that. I have to be honest –
Mr Stein: This is a major issue, Mr Austin, isn’t it? The question of trying to put automation into small branch offices in the middle of the countryside: a major issue and a potential problem, yes?
Terence Austin: Yes.
Mr Stein: Later on, it cost something like 40 million to fix the problem, yes?
Terence Austin: Yes.
Mr Stein: Why didn’t your company point this out and say, “Look, it’s going to be obvious that this is going to be difficult”?
Terence Austin: We may have done but it wouldn’t have been for me to have done that. I can’t recall, to be honest. I’m being – I’m sorry, I can’t recall.
Mr Stein: You mentioned to Mr Blake the question of the difficulties sometimes with the telephone line and then the other types of lines that might be required to assist with automation, yes?
Terence Austin: Yes.
Mr Stein: Now, as we understand it, if the branch computer goes offline within the Horizon System, there then needs to be a reconciliation between the central servers and the branch computer so that, essentially, they match; is that right?
Terence Austin: That’s correct.
Mr Stein: So that this becomes vaguely comprehensible for everyone, that means that one part of the system must overwrite the other, so that there’s consistency of information between the two; is that correct?
Terence Austin: The – when the system comes back, the counter comes back, it can be replicated from the centre. So it can be brought back up to where it was when it failed.
Mr Stein: Right. So what happens is that, if the system goes offline, and it could go offline because its been turned off, correct?
Terence Austin: Yes.
Mr Stein: It could go offline because environmental factors have caused an interruption in power supply?
Terence Austin: Yes.
Mr Stein: It could go offline because of problems with the cabling or something similar, yes?
Terence Austin: Yes.
Mr Stein: So a variety of reasons could cause it to go offline, yes. Now, that doesn’t mean that, necessarily, when it does get back in contact, that the two parts of the system are going to have the same information by that point, does it?
Terence Austin: Not necessarily but it was designed to do so.
Mr Stein: In fact, it was designed, as we understand it, so that the computer in the branch could, even if it was offline, continue to provide service to customers; is that correct?
Terence Austin: If it was up and running, yes.
Mr Stein: If it was up and running. So, despite the fact that it may not still be connected to the Horizon main system, it can still provide customer support; is that correct?
Terence Austin: Correct.
Mr Stein: So when back online the plan was that the systems would then reconcile one to the other?
Terence Austin: Yes. The counter would reconcile back to the correspondence servers, yes.
Mr Stein: Right, for obvious reasons, so that actually, in the end, both sides of the system would end up with the same information about transactions?
Terence Austin: Yes, yes.
Mr Stein: Correct, right. How much of the code or the technical specification for the software for the Horizon System was available to you and your team?
Terence Austin: Because the – okay, you are referring to the Riposte software that was responsible for keeping those message stores in –
Mr Stein: Yes.
Terence Austin: We were not allowed to see the code.
Mr Stein: Were your team capable of rewriting the code if it was required?
Terence Austin: Yes, if – our team wouldn’t have been, but we would have had to commission someone to do so.
Mr Stein: So in order to deal with any Riposte system difficulties with communication and communication errors, you had to go to the Riposte system people; is that right?
Terence Austin: Yes, my chief architect would do that.
Mr Stein: What was the cost to the Post Office of doing so, if you went back to Riposte?
Terence Austin: None, as far as I’m aware.
Mr Stein: What about the cost to ICL: was there a cost there?
Terence Austin: Sorry, I’m not sure about the question.
Mr Stein: Financial cost, was there a financial cost?
Terence Austin: In going back to?
Mr Stein: To Riposte?
Terence Austin: To change something?
Mr Stein: Yes, to get support or get the engineers to come through or to get the code people to come and fix something?
Terence Austin: Yes.
Mr Stein: Yes. Is that code still available now, so if we wanted to check the system code right now, go back in time to what was being used for what we call Horizon Legacy, is that available?
Terence Austin: I can’t tell you. It was lodged in escrow.
Mr Stein: I’m going to ask you some questions about the original agreement and that’s going to require putting up on the screen FUJ00000071. You should have on your screen, Mr Austin, the first page of that.
I’m very grateful, Frankie.
As you can see, Mr Austin, this is just a reminder, this is Post Office Counters Limited and ICL Pathway Limited, the “Information Technology Services Agreement for Bringing Technology to Post Offices”, and this is the codified agreement. This is dated, as we understand it, from the system in mid-1999, okay? So this is the basic agreement between the parties, all right?
Now, I’m going to take you to a particular part of this, if I may, please. Can we go to page 97 of 914 on the Relativity system, sir, for your reference.
I’m going to read out this particular section, Mr Austin, so that you have a moment to think about what it says here and, therefore, from your point of view, what it means. So this is under the heading “Prosecution support”:
“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 (PACE) 1984 and the Police and Criminal Evidence (Northern Ireland) Order 1989 and equivalent legislation covering Scotland.”
At the next paragraph, 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 the normal retention period of that information.”
So we can see that the heading for all of this is “Prosecution support” and then between paragraphs 4.1.8 and 4.1.9 is basically saying that information’s got to be provided to the Post Office at the request of the Post Office and it has to have certain evidentially admissible requirements, and then the other part is basically saying that, well, you need to keep the information so it’s available.
Just help us a little bit, please, with your understanding of that. What was your understanding of what would be evidentially admissible and capable of certification in accordance with the Police and Criminal Evidence Act 1984 at the time?
Terence Austin: I’m not able to say that because that wouldn’t have been my responsibility. I’m not knowledgeable enough to know what that – would be required. That would be one of my colleagues in the audit department there that would have – Martyn Bennett and Jan would have liaised with the audit people within POCL to determine exactly the nature of what they required.
Mr Stein: Who within ICL was responsible for making sure that ICL was capable of fulfilling these prosecution support requirements?
Terence Austin: Martyn Bennett, in my opinion.
Mr Stein: Martyn Bennett. Help us, please, whether you are aware that ICL sought or did not seek an opinion from an experienced criminal lawyer as to what this all means?
Terence Austin: I can’t – I can’t –
Mr Stein: Again, are you referring that to Martyn Bennett?
Terence Austin: I am, yes, because I wasn’t responsible for that aspect. Martyn would have come to me and said “This is what we need to do”, as he did when we produced the audit trail capability.
Mr Stein: Right, well, let’s just deal with this a little bit more. What systems were you aware of that were put in place, so that ICL could fulfil this requirement? A policy, guidance, protocol –
Terence Austin: I wasn’t requested to do that.
Mr Stein: Well –
Terence Austin: I was requested to put in an audit system, which we did, which was to enable POCL to audit the system at various points throughout, from the correspondence server right through to the MIS, the back office system.
Mr Stein: Audit is not the same, is it? It’s not the same as providing information, which is evidentially admissible and capable of (unclear) –
Terence Austin: I was never – that never came across my desk.
Mr Stein: Then why are you referring to audits?
Terence Austin: Because the next sentence, which you referred to, which is the direction of POCL’s audit trial.
Mr Stein: All right but what protocols or systems were put in place for the first part, 4.1.8; do you know?
Terence Austin: No, I don’t.
Mr Stein: No. Your job, as we understand it, if I recall from your statement, is that this is meant to be dealing with the implementation of the system, getting it up and running, getting it going, getting it going to the acceptance requirements, yes?
Terence Austin: Yes.
Mr Stein: Right.
Terence Austin: And to deliver to a business requirement specification as produced and signed off by POCL. That was never anything that I ever saw.
Mr Stein: Well, this is part of their business requirements, Mr Austin.
Terence Austin: Not as I saw.
Mr Stein: Why not?
Terence Austin: I don’t know.
Mr Stein: Do you understand the importance –
Terence Austin: Absolutely, I understand the importance – I absolutely understand the importance but nobody said or asked me, or laid down in writing what was required in order to meet that requirement. That’s in a contract, with respect, that’s not in a business requirement.
I delivered things to a business requirement. That’s a document that says “These are our business functional requirements”.
Mr Stein: Right. So you delivered things to, let me see, the acceptance criteria, that was what you were aiming at?
Terence Austin: No, the set of business requirements. The acceptance criteria was based on the business requirements.
Mr Stein: Right, okay. So the business requirements, as far as you can say and recall, did not include a reference to the prosecution support section?
Terence Austin: No.
Mr Stein: I see. If we can just scroll down the page a little bit more, it says at 4.3 “Training and Training Material”.
Frankie, if we just go down to 4.3, thank you very much.
Now, there’s a reference to:
“The Contractor shall prepare all training events and training material …”
Can you help, from your recollection, with what training events and training material was even considered to try and provide the prosecution support that we have just been looking at?
Terence Austin: No, that was the responsibility of someone else.
Mr Stein: Mr Bennett?
Terence Austin: No.
Mr Stein: Who else?
Terence Austin: I can’t recall, but it was within Mike Coombs’ area. He would be able to say who was responsible for doing it.
Mr Stein: I see.
Terence Austin: It was a – training and implementation were not part of my responsibility.
Mr Stein: If we can go one step down, please, Frankie, just a little bit further down that page. Yes, at 4.4.2 you see there that:
“The Contractor shall ensure that all materials which are used for producing documentation relating to POCL services, conform to relevant parts of POCL’s Environmental Policy Summary.”
Well, obviously we would all agree that that should be done. Do you recall whether there was any summaries or policies provided to you from POCL as regards the operation of the prosecution support section?
Terence Austin: No.
Mr Stein: One moment please.
(Pause)
Mr Stein: Thank you, sir.
Sir Wyn Williams: Thank you. Could that document be taken down, please. Thank you.
Mr Blake: Sir, I believe Mr Henry is now going to be asking some questions. There is one document that –
Sir Wyn Williams: Sorry, Mr Blake, can you stop. I can hardly hear you.
(Pause)
Mr Blake: Sir, there is one document that Mr Henry will be taking the witness to that the witness hasn’t had an opportunity to look at before, it is going to be brought up on screen.
Mr Austin, if you need any more time on any of the documents, please do say so and we can take some more time on that. Thank you very much.
Questioned by Mr Henry
Mr Henry: Hello, Mr Austin. Yes, no desire at all to ambush you so please do follow Mr Blake’s suggestion, but could we go to FUJ00036863, please.
Now, sir, is this a document that you have seen before?
Sir Wyn Williams: Sorry, is that addressed to me, Mr Henry, or Mr Austin?
Mr Henry: Well, may I, like the duck/rabbit, ask you both, sir.
Sir Wyn Williams: Well, I can’t put my hand on my heart and say one way or the other. I have seen so many documents, Mr Henry, but I’m very happy for you and Mr Austin to discuss this document and I will do my best to follow.
Mr Henry: Thank you very much, sir.
Mr Austin –
Terence Austin: I have not seen this document.
Mr Henry: Well, look, Mr Austin, I don’t want to take you by surprise and I’m going to make it absolutely clear to you that if you need time to think, please do so, but this is produced, obviously from Fujitsu. It looks like it is a sort of helpdesk file because John Simpkins opens up the entry and it is talking about calls. So would you be prepared to agree with that?
Terence Austin: Yes.
Mr Henry: Good. It looks like it was opened, if we go to the very top of the page, just underneath the grey headline, “Opened”, 9 December 1999 at 11.00 am.
Terence Austin: Yes.
Mr Henry: And last update, 21 February 2000, and so there’s a call which we can see at 11.00 am.
Then could we go down a few lines and we’ve got at 11.00 am again, John Simpkins – it’s about six or seven lines down:
“EPOSS transactions. The EPOSS problems look to be related to Existing Reversals (often of the settlement line).”
So that looks like it’s a balancing the books problem, does it not?
Terence Austin: It looks like that.
Mr Henry: Thank you. I’m going to ask you now to go to page 2, please, the lady who is assisting us, and we can see an entry at line 4 from Mr Steve Warwick. It’s 9.28.14 on 10 December, and it says:
“Passing to EPOSS-FP for urgent analysis. This call is related to AI376 and will require resolution before the commencement of Rollout in January.”
You see that?
Terence Austin: Yes.
Mr Henry: We know what 376 was and obviously that would have been a major –
Terence Austin: Absolutely.
Mr Henry: Quite so. Could we now go to page 5 please. At page 5 there is a Francesco Chiarini. Do you remember Mr Chiarini?
Terence Austin: No. This is when my development team and a lot of my technical experts had moved over into the support environment.
Mr Henry: Yes.
Terence Austin: So they would have been fronting and going through that process.
Mr Henry: So they would have been customer faced?
Terence Austin: Yes.
Mr Henry: Right, okay.
Terence Austin: And the support teams, the actual development support teams, the expertise, for example Steve Warwick – and I don’t know who Francesco Chiarini is but he would be someone, I would assume, would be in that environment.
Mr Henry: I see, thank you. So we’ve got here, haven’t we, at 11.37.17, and it says, forgive me:
“FAD322704: Problem in the Scales transaction. A fix was delivered in WP5447 on 20/8/99, but the counter had a previous version …”
Now is this – and I don’t ask you to speculate, but is this an instance where perhaps, unknown to people trying to fix things, a fix had already been applied, or an update hadn’t yet taken place and so therefore the fix was not effective? “A fix was delivered in WP5447 on [20 August ‘99] but the counter had a previous version”, and then it gives WP4775. The “but” seems significant, doesn’t it?
Terence Austin: What it is suggesting is that the fix was – didn’t arrive at the counter, the right version of the fix didn’t arrive at the counter, that’s what it’s suggesting.
Mr Henry: Right, thank you. Then we’ve got, below there – I’m going to just say FADS, about five of them:
“The problem has been identified and can be reproduced.”
Then I omit words:
“The other reversals are being investigated.”
Is this again where the books are not balancing reversals?
Terence Austin: That’s what it would appear to be, yes.
Mr Henry: Then if we just move down the page to Mr Chiarini at 14.30.27:
“Further investigation has not been able to get to the root of the problem.”
You see that?
Terence Austin: Yes.
Mr Henry: So this was obviously, as you have said several times, very, very difficult, complex – complex, quite unique problems arising.
Terence Austin: A combination of circumstances, yes.
Mr Henry: Yes. But, obviously, this is suboptimal because you’ve got your brightest and the best, subject to the qualification you gave in evidence, trying to sort this out?
Terence Austin: Yes.
Mr Henry: Can we go, please, to page 7 and this is at 17.45, it says:
“Deleted User (Mark McGrath left [July]/00). I have released a fix for this in WP7029 – to be applied AFTER 7012.”
Can you work that out? Do you know what that means?
Terence Austin: No, I’m afraid I can’t.
Mr Henry: Because you see the name “Austin”, and maybe this is a coincidence, appears just after that, doesn’t it?
Terence Austin: It does and I can’t explain that because I had nothing to do – directly to do with this exchange or in the fixing, because this was a team not reporting into me.
Mr Henry: I see. So –
Terence Austin: So I don’t know why “Austin” is there.
Mr Henry: I see. You can’t – I mean, would this team, even though they weren’t reporting into you, given your seminal role in development, might they not have been consulting with you?
Terence Austin: No.
Mr Henry: No? Not at all?
Terence Austin: Not at all.
Mr Henry: “The response was delivered on the system”, that’s at 17.46, and then could we go, please, to page – forgive me while I just scroll it up.
Forgive me, sir, I’m just having difficulty with my one.
Yes, could we go to page 8, please. Do you see at 2 February 2000 at 18.17.25:
“Please inform me when this is released to live.”
Can you remember what that was about?
Terence Austin: I’m sorry, I’m just trying to find it.
Mr Henry: That’s John Simpkins, it’s about six up from the bottom?
Terence Austin: Yes, yes.
Mr Henry: “John Simpkins notified as requested. The fix has been released to live.”
Then finally, over the page, I’m going to ask you now about Colin Baker. Can you help me, please, about Colin Baker, who is he?
Terence Austin: I don’t know.
Mr Henry: Sir, you will see it is about the last eight/nine lines. 21 February 2000:
“We are unable to test this in PI Test but we are NOT aware of the problems described as occurring in our environments.”
Then this:
“I can only suggest that we be aware of potential problems and raise them if and when they occur.
“The Call record has been transferred to the Team: QFP.”
Do you know what that team was?
Terence Austin: No, sorry.
Mr Henry: I mean, this does not necessarily appear to be as coherent as what you suggested in evidence, that this is a somewhat as and when, ad hoc response to problems rather than a coherent policy of investigation and weeding out and rectification?
Terence Austin: It does appear like that, I agree, but this was part of – as I said, the development and the testing and error fixing was within the customer services arena.
Mr Henry: Absolutely, and it would be obvious, wouldn’t it, that the Post Office would be aware of this as well?
Terence Austin: Yes, I would assume so, yes.
Mr Henry: Absolutely. Could we just consider now, in the time we have – and I will finish before lunch, sir – Horizon, for POCL’s specific needs, was a frantic afterthought, wasn’t it?
Terence Austin: No, no. The reason it may appear like that is because we didn’t have a documented functional requirement.
Mr Henry: You mention that because you thought that it was apparent from both the DSS and POCL that they thought that they could just give you the functional requirements before it was supposed to go initially live in 1997. You say that in your statement?
Terence Austin: Absolutely. It became apparent to me that they didn’t understand the basic philosophy of a PFI, in that you write the specification, you then get a quote and then you deliver to what you said you would deliver and the functional requirement. And that’s the reason why, in the contract that we gave to BA and POCL, in the contract that was signed, it said that within 30 days of the contract being signed they would sign off the functional requirement.
Mr Henry: Right.
Terence Austin: Because that’s what we had.
Mr Henry: Let’s hold that because what you said there is very, very important but I want to address a more fundamental problem as to why I suggest it was a bit of a frantic afterthought. You, of course, worked for ICL from 1995 to October 2000?
Terence Austin: Correct.
Mr Henry: But, obviously, Pathway and Horizon had been in development before you joined the company?
Terence Austin: Pathway bid team was in before I joined the company, yes.
Mr Henry: Fine. But I want to ask you about this, that the Benefit Payment Card was scrapped in May 1999, wasn’t it?
Terence Austin: It was.
Mr Henry: Yes, and POCL, of course, wanted to continue with the Benefit Payment Card but the DSS wouldn’t support them?
Terence Austin: Is what I understand to be the case.
Mr Henry: Yes. ICL were initially supportive of POCL’s position but, eventually, you know, had to accept the inevitable, as did POCL, that the BPC was dead in the water, correct?
Terence Austin: Correct.
Mr Henry: Absolutely. So that’s what I suggest is the reason why it was a frantic afterthought because what effect did that have on the time you had available to address what POCL specifically required?
Terence Austin: The remaining time that we had to get a release is that we were agreeing with POCL what we would try and deliver by what dates and in order to do that we needed POCL to provide a functional requirement for us –
Mr Henry: May we go –
Terence Austin: – and to sign off the designs.
Mr Henry: I’m so sorry, sir, I didn’t mean to cut across you. I’m just anxious about time because I don’t want you to be here after lunch.
Could we quickly go to your witness statement, please, at paragraph 8, your witness statement – forgive me, I had the number to hand but I don’t think it should be … thank you so much. If we go to paragraph 8, please. Thank you. Do you see the last three lines?
Terence Austin: Yes.
Mr Henry: You’re dealing, first of all, with the DSS, Benefits Agency and the rejection of the BPC. Then this:
“There was very little functionality introduced for POCL consequently it has limited relevance to [the Inquiry]. In fact, when the DSS made the decision to cancel the project in May 1999, all the relevant card software was removed from the ICL Pathway solution. The POCL Horizon project only came into existence in the spring 1998 and a new agreement with Post Office Counters Limited signed in July 1999.”
In fact the Benefit Payment Card was scrapped in May 1999, wasn’t it?
Terence Austin: That – yes, I have put May 1999:
“In fact, when the DSS made the decision to cancel the project in May 1999~…”
Mr Henry: Exactly. So very little functionality for POCL, and you give the explanation in paragraph 9, because it really was because DSS was the dominant partner and the Benefit Payment Card was the priority and so therefore the BPC had taken precedence. Do you see your exact words:
“There was no doubt that the DSS were the dominant partner, and the benefit payment functionality took precedence over the … EPOSS functionality which would be developed in parallel over a longer period using [the] iterative development approach.”
Terence Austin: I am referring to the Initial Go Live.
Mr Henry: Yes.
Terence Austin: I’m not referring to the project as a whole. I’m trying to say that the Initial Go Live had little relevance because it was mainly BA functionality that we delivered.
Mr Henry: But when you say that the DSS material was stripped out of the project, would that have included the work on the fraud management system because were you aware that a major component, the fraud management system, was removed from the contract that POCL eventually signed?
Terence Austin: I can’t be sure. I have not heard of the term “Fraud management system”. If you’re saying the fraud procedures – we were instructed to remove all the code that was to do with the benefit card system.
Mr Henry: So it may have been – and I’m not asking you to speculate, but it may have been that all of this anti-fraud architecture was connected to the benefit card and when the benefit card was scrapped, then all of that architecture went as well?
Terence Austin: I understand the point you’re making and I’m trying to cast my memory back, is that we were instructed that we must remove all the benefit card functionality from the system, which was quite a large task and really did demotivate my team because –
Mr Henry: It demotivated?
Terence Austin: Very much so because they had spent quite some time developing that.
Mr Henry: Absolutely. They had invested, as had the company, time and effort and so therefore, at the very time that you’re trying to actually produce something for POCL, your team are obsessed and under the cosh at actually doing completely dead work, removing all of that architecture?
Terence Austin: There were two separate teams. The people that were removing the BPS, all the functionality for that, were not the same people that were developing on the POCL side. It was, as I said, being run in parallel. So I’m referring to the fact that we literally had to kill all the software and all the work we had done on the benefits payment system and then run in parallel and put all our resources into EPOSS.
Mr Henry: So this brings me to my final point and this was the point that you raised earlier, in fact, about “They didn’t understand the PFI”, et cetera, et cetera, because this actually turned from being a PFI to a turnkey contract, didn’t it, effectively?
Terence Austin: My colleagues who were responsible for that negotiation and the agreement that came to pass and, yes, it became more traditional.
Mr Henry: Yes, absolutely. So this was, as you anticipated in fact at the beginning of your statement at paragraph 5 – you know, you thought it was an incredibly ambitious timescale and you thought, really, from the beginning it ought to have been a turnkey or off-the-shelf?
Terence Austin: I did, that was my personal view.
Mr Henry: But of course turnkey or off-the-shelf doesn’t mean bespoke, does it?
Terence Austin: No.
Mr Henry: It doesn’t even mean made to measure, does it?
Terence Austin: No. Well, it means we developed – we had got a product, the Riposte product, and then we developed the BPS aspect of it and that was live and ready to go.
Mr Henry: But it’s very much working out compromises and make do and mend, isn’t it?
Terence Austin: We still had to deliver to the business functionality. We still – we were guided – we had to develop a system that met the requirement.
Mr Henry: I know, but –
Terence Austin: The business requirement.
Mr Henry: Unfortunately however, as is plain, it didn’t.
Terence Austin: Which bit?
Mr Henry: Well, I mean you even said to Mr Blake, you didn’t understand how you could achieve a product which would deliver to the business what they wanted. I mean you were doing your best, but it had, as it were, morphed so many times –
Terence Austin: That’s true. I mean, from a development team, we were getting hit by functionality we had never seen before.
Mr Henry: Exactly.
Terence Austin: And it was growing at a massive rate and my team was growing at a massive rate.
Mr Henry: Right, so it comes to this and this is, I promise you, my final question: you have stated, and Mr Blake has taken you through it, that paragraph 22 of your statement – no need to bring it up, paragraph 23 – you were aware of bugs, errors and defects. July 1997, it wasn’t sufficiently robust, you bring in Escher and Riposte, correct?
Terence Austin: Correct.
Mr Henry: But paragraph 26, September 1999/October 1999 – no need to bring it up on the screen, FUJ00079782 – I mean, post-Escher and Riposte, it still, quite frankly, is not fit for purpose, is it?
Terence Austin: It didn’t go to Escher for that reason. It went to Escher for a specific reason, in that the product, EPOSS, was not interfacing with Riposte correctly.
Mr Henry: Right.
Terence Austin: So the rest of the EPOSS product was as is. Escher didn’t touch it.
Mr Henry: Leaving that aside, September/October 1999 – FUJ00079782 – it was still not fit for purpose?
Terence Austin: No, and we had to put substantive corrective actions in place.
Mr Henry: But the substantive corrective action, as you say in your statement, was only to concentrate on 80 per cent of the bugs, errors and defects?
Terence Austin: No, no.
Mr Henry: Well, let’s go to your statement.
Terence Austin: No, I did say that. I just want to clarify. What we said was that we could stabilise the product. We couldn’t fix everything, we could stabilise the product by targeting the 80 per cent because 80 per cent of the bugs and defects were due to a particular area of the system and we attacked that.
We also attacked the others, but – and fixed a lot of problems in those areas, but the instability issue and the not fit for purpose was mainly due that people were seeing so many large amount of errors that they were using that as a yardstick to determine whether the project was fit for purpose or not.
So if you fixed the 80 per cent, you were then left with the 20 per cent, of which a lot of them you did fix but, overall, the product was becoming more and more stable.
Mr Henry: But, nevertheless, given the imminent – well, given the rollout and given what we now know, it was a catastrophically dangerous thing to have happened because of the number of unknown unknowns and the factors you have already said, that when you were fixing things, you were sometimes introducing further problems, unintentionally and unwittingly?
Terence Austin: Well, when you do that, that’s what regression testing was due to find and it did, so if that happened – you couldn’t be 100 per cent, but regression testing was there to try and avoid that happening.
Mr Henry: But all the time the Post Office was aware of this as well: the level of errors – the level of bugs, errors and defects?
Terence Austin: I believe so.
Mr Henry: Thank you.
Terence Austin: Because I – sorry, just to –
Mr Henry: Yes, please.
Terence Austin: I didn’t specifically hide that from POCL. I wasn’t – as far as I was concerned, acceptance and the errors and defects we were having, whether it was under the instability issue which I have discussed prior to that, which was very difficult to crack, 298, and then 376 which was the balancing issues, we took those extremely seriously and if we would have not solved those, we wouldn’t have achieved acceptance.
Mr Henry: Who was your counterpart at POCL then, if you didn’t hide it from POCL?
Terence Austin: I didn’t have a counterpart.
Mr Henry: You didn’t? But you –
Terence Austin: The nearest person that would – if you like, that I will be talking with would be John Marr.
Mr Henry: John Marr. Thank you very much, sir.
Mr Blake: Sir, can you hear me?
Sir Wyn Williams: Yes.
Mr Blake: Thank you. I just have one very brief follow-up question and also Mr Maloney is going to ask a question or two as well.
Mr Maloney: Sir, no. We have no questions. We have provided very detailed rule 10 requests and, if we may say, with respect, Mr Blake has very ably covered all the questions we identified in respect of this witness. So we have no questions.
Sir Wyn Williams: That’s fine.
Further Questioned by Mr Blake
Mr Blake: Thank you very much. So it’s just one question from me then.
We have seen the PEAK and PinICLs and I think your evidence was that you believed the Post Office had access to those. Would it surprise you if, in fact, they didn’t have access to those?
Terence Austin: I believed that POCL were – had people that were part of the helpdesk community so, from that perspective, I can’t believe that they weren’t given access to that system. I don’t know whether they were able to contribute to it, but I can’t believe they weren’t given access to it. They were part of the same team of experts.
Mr Blake: Would it have been best practice for them to have had access?
Terence Austin: I would – yes.
Mr Blake: Thank you very much. Sir, I don’t have any questions unless you do, sir?
Questioned by Sir Wyn Williams
Sir Wyn Williams: I just wanted to ask Mr Austin, there was reference in one of the emails which Mr Blake showed you to a man called Gareth Jenkins.
Terence Austin: Yes.
Sir Wyn Williams: Was Mr Jenkins part of your team?
Terence Austin: Not that I can remember.
Sir Wyn Williams: Did you know him at all?
Terence Austin: Not that I can recall.
Sir Wyn Williams: Fine. Thanks very much.
Thank you very much for making your statement, Mr Austin and also for coming to give oral evidence.
Terence Austin: Thank you.
Mr Blake: Thank you. 2.00, please, sir.
Sir Wyn Williams: Certainly, yes.
(1.02 pm)
(The luncheon adjournment)
(2.00 pm)
Ms Kennedy: Good afternoon, sir. Can you see me and hear me?
Sir Wyn Williams: I can indeed.
New Speaker: Our next witness is John Bennett.
John Bennett
JOHN BENNETT (sworn).
Questioned by Ms Kennedy
Ms Kennedy: Mr Bennett, I am Ruth Kennedy and I ask questions on behalf of the Inquiry, as you know.
Could you confirm your full name, please?
John Bennett: John Hamish Bennett.
Ms Kennedy: In front of you, you should have a copy of the witness statement that you prepared; do you have that?
John Bennett: Yes, I do.
Ms Kennedy: Have you read through this statement recently?
John Bennett: Yes, I have.
Ms Kennedy: If you turn to page 10 of that statement –
John Bennett: Yes.
Ms Kennedy: – is that your signature there?
John Bennett: Well, the one I’ve got here hasn’t been signed – yes, it is, I can see it here. Yes, it has been signed; that is my signature.
Ms Kennedy: Is it true to the best of your knowledge and belief?
John Bennett: Yes.
Ms Kennedy: I’m going to start by asking a few questions about your background. Please could you explain your background prior to joining ICL?
John Bennett: I – when I graduated I joined a company called English Electric-Leo-Marconi, which eventually became part of English Electric and therefore picked up what’s in paragraph 1 here.
Ms Kennedy: What did you initially do when you arrived at ICL? What roles did you have?
John Bennett: Sorry, what?
Ms Kennedy: Roles.
John Bennett: Rules?
Ms Kennedy: Roles.
John Bennett: Roles, I apologise.
Ms Kennedy: Excuse my Northern Irish accent.
John Bennett: Yes, I started my career as a computer programmer and progressed from that into systems engineering and eventually into sales. Then through sales management and then followed the track which you have here in paragraph 1.
Ms Kennedy: What role did you have between 1994 and 2000?
John Bennett: 1994 and 2000. In 1994, I took over the responsibility for managing the ICL team, which was bidding for the BA/POCL PFI contract, so it started as a pre-sales exercise. It ran – took about two years for the contract to be eventually let. The contract was eventually placed with ICL. I continued to work on that contract.
The company was reformed as ICL Pathway in –
Ms Kennedy: I think that happened – sorry, I was just going to say I think that happens in 1995 –
John Bennett: I’m sorry, yes.
Ms Kennedy: – that ICL Pathway is set up. You then take over as MD of that company in 1995, in the newly set up company?
John Bennett: Yes, that’s correct.
Ms Kennedy: Can you briefly explain, in your view, what the purpose of what would become the Horizon project – what the purpose of the project was?
John Bennett: Well, it started, of course, with two major customers, two major clients, and they both had somewhat separate but joint agendas – well, they joined up, but the essential feature for Post Office Counters was to fully automate their extensive network of post offices, which, until that time, was still running on mainly manual, paper process. So they needed to automate their entire network, for one thing to deliver their existing services but, more importantly, to build a platform for future business within the Post Office network.
The Benefits Agency, which were, of course, a – and had been for a long time – a customer of the Post Office Counters needed to develop a new and more automated system for the payment of benefits and the contract called for a Benefit Payment Card to achieve that, and the key driver there was a more efficient system but perhaps, even more importantly, a system which had a substantially lower element of fraud.
So the two customers were joined together to both deliver their separate business objectives.
Ms Kennedy: At the time of the procurement exercise, did you feel that ICL Pathway could deliver and meet those two aims?
John Bennett: When the business – when the sales campaign started and from all the invitations to tender and everything, yes, I was confident that we could deliver a system to meet this requirement.
Ms Kennedy: How important was training in respect of that vision? Did you see that as an important element of the project?
John Bennett: A key feature of the programme, particularly for Post Office Counters – not so much the Benefits Agency, but for Post Office Counters was the training of, I think, in excess of 30,000 staff to use the new system. And many people referred to the programme as one of the biggest management of change programmes in the UK and perhaps in Europe and, as a management of change, it did affect the working practices of an extremely large number of people, so training was a key feature of that programme of change and we were responsible within the contract for delivering training facilities to all those numbers of staff I have just referred to.
Ms Kennedy: I’m now going to take you to some board minutes of a meeting on 3 October 1995. If we could turn up FUJ00077832, please, and if we could turn to page 3 please. You can see that this is a note of the board meeting on 11 October 1995. If we turn to page 3 and at (d), the top (d), it says:
“As noted at the last meeting, we were still experiencing considerable difficulty with the way the procurement was developing. POCL/BA were attempting to rewrite the SSR [which is the statement of service requirements] via detailed contract schedules, then would implement change control so that ‘level playing field’ would be achieved with only one substantial variable left upon which to make a final decision between the three shortlisted suppliers, namely price.”
At this stage, the three shortlisted suppliers were Cardlink, IBM and Pathway; is that right?
John Bennett: Correct.
Ms Kennedy: In relation to price, what did you mean when you said that the final decision would be made on “namely price”?
John Bennett: Well, it was a competitive international tender and once all three shortlisted suppliers were compliant then price would be, in my reckoning, the predominant criteria for selection.
Ms Kennedy: Did you feel it was important then to be the cheapest option in order to win the contract?
John Bennett: There was no way of judging whether we were the cheapest bidder. We had no access to the costs and prices of our competitors’ bids. We could only price our bid at the best level we could, compatible with delivering the contract and making a return for the company, but we had no access to other people’s prices.
Ms Kennedy: No, but you have just said that you had an instinct or a desire to pitch it at the cheapest workable amount; is that right?
John Bennett: We would always bid at a level we thought we could win the contract.
Ms Kennedy: Looking down the page to (c), if we could just scroll down, it says:
“It was acknowledged that Riposte, produced by Escher, was vital to our proposed solution yet there had as yet been no effective technology transfer path agreed to Pathway. Mr Bennett would prepare a paper on proposals to deal with this issue, and try to ascertain any technical or commercial/legal concerns that Escher had.”
Pausing there, Riposte, that was the software that was required to make the whole project work, isn’t that right?
John Bennett: It was one of the essential products, it wasn’t the sole product, but it was a critical product to be installed in every post office, so, yes, it was a critical component of our solution.
Ms Kennedy: At this stage, did you have a good grasp of the Riposte product and how it worked and how it would function with the project?
John Bennett: Can you remind me what the date of this document is?
Ms Kennedy: Yes, it’s 3 October 1995.
John Bennett: 1995? Well, that’s very early in the process. I think we had, at that time, deduced that Escher, with their product, was ideally suited for this solution. It had, as you probably know, already been implemented in the Irish Post Office. An Post had also used this software from Escher and, having seen the An Post use of this software, we were satisfied that this would be a good fit for the requirement of meeting the needs with this contract.
Ms Kennedy: But at this stage, you still had quite a lot of work to do to understand how it would fit in this specific project; would you agree with that?
John Bennett: We had a lot of work to do to understand how it would fit and, also, which I think this leads on to, how to manage our relationship with this small company. Both of those factors were well understood in 1995.
Ms Kennedy: You also wrote a report that’s appended to the end of this document and if we could turn to page 8, please, and if we look at the first paragraph, it says:
“The last four weeks have seen very slow progress on the Stage 3 plan. BA/POCL have found it increasingly difficult to meet their timescales for schedule production and release. Progress has slipped 2/3 weeks in 4 weeks with little confidence in future dates and their achievement.
“Pathway has not been without its own concerns. Product descriptions have progressed only after intense and tiring effort; a number of key components for WINDEM are still outstanding; in short there is a sense of the procurement becoming bogged down.”
What did you mean by that last sentence, that there is a sense of the procurement becoming bogged down?
John Bennett: I think there was quite a big issue here which reflects later through the documents – and perhaps you will review – which was that we were dealing with what was essentially a PFI contract and a PFI contract being let for a complex IT bespoke system was something I hadn’t experienced before. And there was a conflict beginning, I think, to build up between how you could achieve a PFI contract with all the risk transfer requirements, alongside how and who had responsibility for design. And, I think, somewhere in here that is an element of where the procurement became difficult.
It took a long time for the procurement to complete. It was – I think I said over two years, which is an awful long time for a IT procurement and I think a lot of it reflected the difficulty of letting a PFI contract. This was not a standard IT supply or even service contract, and the whole basis of it required a lot of hard work and difficulty in the procurement phase, and I think it’s – I just say here, and even when that procurement eventually became a contract, the contract documentation was still in many ways incomplete and had to be dealt with by all the parties post-contract.
Ms Kennedy: Yes, and if I can ask you to turn to a board minute from 1996. If we pull it up, it’s FUJ00077839. This is a board meeting on 21 February 1996 and if we turn to page 2, please, and if we can pull up this second paragraph, thank you. In that second paragraph, picking up on this point that you mentioned, you say:
“If this work is left until after the Service Provider’s selection then it is difficult to see how a binding contract could be entered into and accepted by either party.”
So that was an issue you were very aware of in 1996?
John Bennett: I’m just trying to look in this paragraph to where that – what you just read out. Is it in the – can you just remind me where it is?
Ms Kennedy: Yes, let me find it for you. My apologies, it’s actually the paragraph before.
That’s why you couldn’t find it, and it’s the last bit of the second paragraph, if you see it says:
“If this work …”
John Bennett: I see, yes. Yes, I understand that now, yes. And the question was?
Ms Kennedy: So at this stage, you are raising this as an issue, the difficulty of securing a valid and binding contract between all the parties.
John Bennett: Yes, and it’s accentuated by the fact that, being a PFI contract as the provider, then we would only begin to earn revenue from the contract during the steady state or operating phase of such a contract, and the longer the procurement – or the longer it took post-contract to sort out these outstanding issues would quite naturally delay the time by which we could enter steady state and, by implication, how we could get our returns from this substantial investment.
So one thing is delaying the contract but equally important is the issues left unresolved in the contract, which still have to be sorted out and you – later on, but perhaps it is worth mentioning now, we entered into a situation where there was a – things called agreements to agree, you will find this percolating through a lot of this documentation.
An agreement to agree was a sort of legal camouflage for hiding difficult issues. It said that the parties would use reasonable endeavours to sort out things they couldn’t sort out during the contract negotiation but, by their very nature, it led to delay and difficulty for everyone and I would say that we didn’t get to the bottom of agreements to agree for quite a few years.
Ms Kennedy: If we could scroll further down this document so that it is showing what it was showing before and at the end of the second paragraph that’s shown there, again picking up on something you have already mentioned, the last sentence says:
“There is a growing awareness that the structural weakness of this procurement is having two customers who see the world from quite different perspectives.”
John Bennett: Yes.
Ms Kennedy: At this stage, though, you still felt like the project was doable and that it was something that ICL should continue to bid for; is that right?
John Bennett: I think I’m going to say yes, but presumably the date of this – is this – this is before the contract was let, isn’t it?
Ms Kennedy: It’s 21 February 1996?
John Bennett: So it’s a few months before the contract was let.
Ms Kennedy: Yes.
John Bennett: Yes, I think we did. I think we were alive to the fact that this was an unusual contract in having two customers in one contract. That did give rise to, downstream, quite a few difficulties which we might refer to later but at this stage in the process we accepted this as being what the contract was and what we were bidding for.
Ms Kennedy: The next paragraph goes on to mention the risk register.
John Bennett: Yes.
Ms Kennedy: Could you explain a bit about that?
John Bennett: Well, we started constructing a risk register both in a pre-sales environment, in other words what are the risks of bidding or winning this contract, and in some ways were the risks worth taking, should we in fact continue with the bid, that’s what the risk register was about in the pre-sales environment and it is true because I can read here that we refer to Escher and I guess we refer to Escher more later.
Ms Kennedy: Yes.
John Bennett: But I think there was a recognition, both in the pre-sales risk register, that dealing with a very small company would be a substantial risk to mitigate. We recognised that in bidding and that risk remained with us, I think, throughout the whole time I was on Pathway.
Ms Kennedy: I was going to ask you about Escher because we have moved forward in time since the last board minutes. Was there any work that you recall that was done with Escher between these two board meetings to minimise or work together with Escher to minimise that risk?
John Bennett: I can’t really pick out the chronology of that, but what I can say is that in mitigating this risk we took, either at this stage or perhaps later, I’m not sure, a number of actions to mitigate this risk, for example one I remember doing, we took their entire source code of their software and put it into escrow account, such that if anything happened to the company we would have access, at least at source code level, to everything they had provided us with.
We also – and I suspect it was probably a bit later than this – did draw up a comprehensive teaming agreement which spelled out what their responsibilities and ours were and how we should handle it. That was a help.
We also, and I guess it’s probably later than this as well, did allocate key staff to go to Boston, which was where Escher was based, to work directly within their team to learn first-hand elements of their software.
Ms Kennedy: As you have mentioned that can we pull up the next board meeting minute please, which is FUJ00077842, and if we go to page 2 and if we can go to (d) please. This is what you were just mentioning, Mr Bennett, about going and working with Escher in Boston. This is in April 1996, so very close indeed to being awarded the contract.
John Bennett: Yes.
Ms Kennedy: I’m going to suggest to you that this is quite late to be doing this type of work with a company where it was so important to the delivery of the project.
John Bennett: We had – our knowledge of Escher wasn’t just going to Boston. We had knowledge of Escher through the work and our association with the Irish Post Office, An Post, and one of the key directors of An Post was actually at an early stage, I think, on or attended our board meetings, which were used to supervise the project.
So yes, this visit to Escher was, as you say, in April, but we had access to and knowledge of Escher, particularly through An Post, probably – this is April 1996, probably – maybe up to – certainly well into 1995, so we had access and knowledge of Escher starting in 1995, perhaps even earlier, I can’t recall.
Ms Kennedy: But is that knowledge principally from An Post, as you say?
John Bennett: I’m not sure, but from reading this it sounds very likely that’s the case.
Ms Kennedy: At this stage it is anticipated that the rollout will take place in July 1997; is that right?
John Bennett: Yes. Yes.
Ms Kennedy: What were the reasons for the delay?
John Bennett: I think in my statement I highlight three areas, all of which contributed to the delay in rollout. The first one, which I referred to, is the difficulties we were having within Pathway in designing and completing our software development. Those problems caused delay and we had to take action to deal with them, so that was one cause of delay.
Another cause of delay, which I have already hinted at and referred to, was the fact that this was a PFI contract with a very unclear baseline when the contract was set and those requirements – there was a phase which I seem to think was called “drop down”, which is a bit of an ugly phrase, but it reflected the fact that everyone knew that the contract, although it was let and was in about four lever arch files thick, was incomplete and drop down was a process defined whereby those missing pieces could be sorted out.
In actual fact, they weren’t sorted out in the three months allowed for drop down and they – many of them weren’t sorted out even after six months, which was an extension and, as I said earlier, it still left a huge number, or a large number of agreements to agree which continued to be addressed well after the drop down.
So the PFI contract – I think I might say it now, if I don’t say it later, I think was totally ill suited to this contract but none of us at the time spotted that. Anyway, PFI itself caused delay as we struggled to understand the design processes and the clear statement of the requirements. We were developing a system and writing software against a moving baseline.
And the third issue – I have developed two – the third issue was, I think, a recognition that everything Pathway did was equally dependent on large development work taking place both within the two clients. The Benefits Agency had a huge amount of work to do in preparing themselves for their new Benefit Payments System, as indeed did the – and the Post Office themselves, Post Office Counters had massive development work as well, and there were dependencies and interdependencies between all three parties.
Each of us had to interface with each other, take information from and deliver information to, in order to eventually deliver an end-to-end service. So the delays were of those three components.
Ms Kennedy: I’m now going to ask you some questions about the Initial Go Live. Could you tell us about the Initial Go Live that happened shortly after the contract was awarded?
John Bennett: Perhaps – only in, perhaps, outline really. A small number – and it was a small number – of post offices were selected to be the first post office to use the new system for benefit payments. As I remember, the first benefit which was available through the new Benefit Payment Card was child benefit.
The other benefits were not – were yet to be developed by BA but, for Initial Go Live, the Child Benefit payment was available and was able to be used in those selected post – and I think, at some point, something like 40,000 beneficiaries on Child Benefit were able to collect their Child Benefit payments using the Benefit Payment Card through that selected number of post offices.
I might not have it absolutely right, but that’s the sort of – my understanding of what happened in 1990 – I don’t know what – ‘98, was it?
Ms Kennedy: 1996. If we could turn up the report that was written by one of your colleagues, FUJ00058278. You can see there in the abstract that, as you have described, it was introducing the benefit payment system into “10 offices in Stroud early”.
If we could turn to page 8 of that document. Just looking at the first paragraph there:
“IGL was implemented as a result of a political imperative from Peter Lilley which called for the introduction of payments of benefit by card, with the deadline of the 23rd September.”
Do you remember a political imperative?
John Bennett: I remember Peter Lilley coming to Stroud to look at the system. I remember meeting him there and, obviously – I didn’t – whether there is a political imperative, I’m not sure, but I do remember him being there and being very keen on the system.
Ms Kennedy: Did you feel like you were under pressure to roll out this Initial Go Live quickly?
John Bennett: No.
Ms Kennedy: What did you think of the Initial Go Live? Was it a useful process?
John Bennett: I think two responses. Yes, it was a useful process but it was extremely short and extremely small. It was not really real time representative system. It was too limited in scope.
Ms Kennedy: Was it quite high level?
John Bennett: Well, it paid benefits, which is what it was there to do. So for what it did, it was a proper operational system. It’s just that there were very few offices and only one benefit payment. That’s the limitation. But within that limitation, it was a true operational system.
Ms Kennedy: You presented the results of the Initial Go Live at a board meeting on 25 November 1996. Can we get up the document FUJ00077844. If we go on to – if you scroll to the bottom of that page we can see that you presented a report and if we turn over the page we can see that it says:
“Initial Go Live 2 had been successful on 21 October, although it took more effort than planned. Mr Bennett confirmed he was likely to sign off the drop down process at the end of the present week.”
Can you explain how it took more effort than planned or why you would have said that?
John Bennett: No, I can’t remember.
Ms Kennedy: At this stage, did you feel like things were operating well and that you were making good progress with the Horizon project?
John Bennett: I think this is – the date of this is – can you remind me of the date?
Ms Kennedy: Yes, the date of this is 25 November 1996.
John Bennett: Okay. This is very early in the life of the contract and it was too difficult to judge at that time how things would unfold, so it was an early start but only an early start, and there was an enormous amount still to do.
Ms Kennedy: I’m now going to pick up again the topic of delays. If we could turn up FUJ00078972. This is a memo that you sent on 7 January to all Pathway staff, and we can see there in the first paragraph:
“At the PDA board meeting [that’s the Programme Delivery Authority] in December, it was proposed that a joint review should be undertaken between ICL Pathway and the PDA to assess all the remaining risks which must be handled prior to a successful implementation starting with the Live Trial and leading in to National Rollout.”
If we can scroll down a bit, please. Yes. Up again – no, there it is:
“It is very likely that you will hear views expressed that the programme will be delayed by anything between one to as much as six months. At this stage I must ask you to treat any such views as speculative. If additional time is considered appropriate, it will be handled through our formal change control process.”
So, at this stage, you seem to be suggesting that rollout can happen reasonably quickly?
John Bennett: I think there was – and this letter rather implies it. There was a recognition that, although that was the date, delays were not ruled out. I think at this stage we could begin to anticipate that there would be delays yet to come and be clarified.
Ms Kennedy: It says “as much as six months”. That appears to be the outer limit of what you thought the delay would be at this time?
John Bennett: Well, I think it says here that other people were expressing the view about one to six months. I don’t think I was expressing the view of one to six months.
Ms Kennedy: Quite right. At this stage do you recall how long you might have thought that it was going to take?
John Bennett: No, I didn’t have a considered view.
Ms Kennedy: In February 1997 there was a no fault replan of the programme between the three contracting parties and then in June there was a meeting of the Programme Delivery Authority. If we could pull up POL00028304. Could you explain to us what the Programme Delivery Authority was and how it worked?
John Bennett: Well, I can try. I mean, it goes back to something I was saying earlier, which is this contract was unusual in having two customers and one supplier. Most of my experience of IT contracts with government were you had one customer and one supplier and you dealt directly between the supplier and the customer in all aspects of the contract and contract delivery.
Now, in the case of this PFI contract, that didn’t function, so instead – and this is something which the contract documentation, early on, didn’t really specify in any details – there was a need to create a new organisation called the PDA, which sat above and in-between the supplier and the two customers.
So the PDA was a new organisation, staffed from both BA and POCL, and it was put in place to really discharge the contract on behalf of both customers, but in many ways it did actually sit between us and the customer and it got quite large and I think you will – maybe you will come to this later on – there were – but I will mention it now – there was a major review – this is 1997, it wasn’t soon after this, it was a major review, external audit, carried out by the PA Consulting group which I – which looked at the entire range of project Horizon.
And they addressed this issue of the PDA and its size and, I think, echoed some of the comments I have just made, that it was a large organisation, it was interceding between us as a supplier and the two customers and it didn’t have – and this I think is quite important – any executive authority, by which I mean it could press ICL Pathway to do things and it could disagree with what we’re doing and it could point out the things we hadn’t done.
But when it came to making decisions about change or things which would affect the so-called sponsors, this case BA – it always had to revert back to the two customers, so that process of interceding did actually take a lot of time.
So if there were critical issues which needed rapid resolution, we might be able to agree to them within ICL Pathway, but PDA could not agree to them itself, it had to revert back to the sponsors. So you will often find, in a lot of the documentations, the “This will be reverted to the sponsors for agreement” and indeed it was but it was a process which took time.
Ms Kennedy: If we turn you to page 3 of this document, we can see at these PDA meetings you had the opportunity to present reports, or report ICL Pathway issues; is that right?
John Bennett: Sorry, which report is this? This is?
Ms Kennedy: So you can see there it says “John Bennett reported on ICL Pathway issues”.
John Bennett: This is a PDA board meeting, is it?
Ms Kennedy: Yes.
John Bennett: Okay, I’m with you.
Ms Kennedy: Yes, the same document.
John Bennett: Okay, thank you.
Ms Kennedy: Would that typically happen?
John Bennett: At the PDA board, yes, I think on – on the PDA board we would always report on progress and issues.
Ms Kennedy: If we look at the fourth – 2.4.4 it states:
“John Bennett, Paul Rich and Colin Baker NFSP had visited sites in the North East. It was noted that that had been a useful exercise in terms of achieving early exposure of some of the issues needing NFSP decisions.”
Can you tell us a bit about what that site visit involved?
John Bennett: I don’t think that these site visits were ever designed to resolve any issues. I don’t recall – I do recall the meetings. I mean one of the things I was very interested in – and this is one example of it – I was very interested in visiting Post Offices around the country. I was keen to meet subpostmasters and their staff and I was very keen to see how they were finding, adopting and using the new system or their enthusiasm for anticipating the new system, so I liked – I enjoyed and found it very useful to meet and have these visits and I did request a number of them which were always – and Paul Rich, I recall, often would sponsor and organise these meetings and, as you can see, would attend. So we had a number of these meetings over time, which I found very useful, but I don’t believe they were ever designed to deal with any particular specific issue. There might have been feedback and an understanding of how subpostmasters were thinking, but I don’t recall they ever led to specific resolution of defined issues.
Ms Kennedy: As managing director of Pathway, you wrote a number of monthly progress reports on the development of the Horizon System; is that right?
John Bennett: Correct.
Ms Kennedy: What can you tell us about how those reports were written and drawn together?
John Bennett: This was something we started quite early in the process, probably after contract I guess, but quite early in the process and I determined that it would be very useful to have a comprehensive monthly report of everything we were doing in Pathway and to construct – and I – and to construct that report I got every one of my direct reports, obviously, to send me their input. I would consolidate their input and write a management summary.
And that report – as I think you’ve got quite a few of them in this bundle – would often run to 20 or 30 pages of information and that report was sent both to my boss, which was the chief executive of ICL, it was shared with all my direct reports and it was also shared with other people who needed it, for example we had a dedicated team from Fujitsu from Tokyo with us, for quite a time, who came to work with us later on in the process and they had a copy of this report.
Since it was sent to all my team, it meant that all my team, not only knew what their contribution this last month had been, but they could see quite clearly what the contribution of all their colleagues had been. So I looked upon it as a very important piece of communication and I continued it every month for, I think, quite a few years.
Ms Kennedy: Shall we look at one of those reports. If we could pull up FUJ00058162. Thank you. If we could turn to page 4. This is what you were just describing, isn’t it, one of these reports?
John Bennett: Yes, it is indeed.
Ms Kennedy: When you were talking about a managing director’s summary, this is the bit that you wrote?
John Bennett: Correct.
Ms Kennedy: This report is dated 11 July 1997 and we can see here on this page, looking at the first paragraph:
“This month saw the drawing together of the findings of three separate activities. The first concerned the difficulties in testing of Release 1c, the second review concerned the plans for future Pathway releases in 1998 and the third was the output and findings from the programme audit conducted by Mike Coombs and Andrew Boswell across ICL Pathway. This has led a programme review being undertaken and a comprehensive reassessment of the achievable outputs from now through to national rollout.”
It goes on to say:
“The programme review has been presented to PDA, POCL, BA, ITSA and SSA … The consistent response has been one of disappointment and shock that yet another slippage has come to the surface so soon after two previous replans.”
So, at this stage in your report, you’re reflecting the frustration of the various interested parties; is that right?
John Bennett: Yes. Everyone was deeply disappointed and affected by these delays.
Ms Kennedy: If we could scroll down to the bottom of that page, the final bullet point, it says:
“The anticipated delays have caused a serious impact on the business cases of BA, POCL as well as ICL Pathway. As a result, quite a few people have now voiced their concerns that the programme may not be viable and this has given rise to suggestions of significant contract readjustment as well as exploring the position on termination.”
Was this a very difficult time to be in your job?
John Bennett: I think this was a very difficult time for everyone, not just me, but the sponsors and all our staff.
Ms Kennedy: If we could turn to page 19 of that document please. If we could scroll down, please, to the “Current Critical Problem”. Is it a fair summary that often, if not always, in your report you would summarise each theme and set out a current critical problem?
John Bennett: I think in the report we – I had settled on a format which was always followed every month. It was followed both by my summary and I think the format was reflected in all the reports from my management team, so we all had a strict format and this is – I think that’s right – and this is a part of that format.
Ms Kennedy: If we look at the bottom bullet point, we can see that there is a reengineering programme being devised to:
“resolve the issues surrounding the EPOS product.”
Do you see that there?
John Bennett: Yes, I do.
Ms Kennedy: That involves redevelopment work being carried out by Escher.
John Bennett: Mm-hm.
Ms Kennedy: So, already at this stage in 1997, there are issues with the EPOS product, aren’t there?
John Bennett: Yes.
Ms Kennedy: Was that something that you were acutely aware of and concerned about?
John Bennett: I think the problems with EPOSS started quite early and they continued for a long time. There was a lot of action to resolve and deal with the issues, but they persisted through – what – I don’t – what month – this is July – this is June 1997, isn’t it?
Ms Kennedy: Yes, written in July but dealing with June 1997.
John Bennett: I mean, EPOSS took the attention of my technical team, not just in 1997 but all the way through to 1999 and probably into year 2000. EPOSS was always high on the agenda of things to deal with.
Ms Kennedy: Is that partly because it was such an important part of the programme itself?
John Bennett: It was a vital part of the programme for Post Office Counters and it was – and I think I might have mentioned this – the service, the EPOS Service was an end-to-end service, so it reflected not only what we were doing but it reflected what was happening across the interfaces with the work done elsewhere, particularly in this case, or later on with Post Office Counters.
So it was a complex product. It had extensive end-to-end implications. It involved an awful lot of people and we, in our responsibility, had our own problems in delivering our side of that picture as well.
Ms Kennedy: If we could turn up a PDA minute. If we could pull up POL00028311. This is another PDA board minute. If we could scroll down, this is, as I say, from August 1997. The first item is:
“Mr Bennett to identify how long it will take to obtain all the information required for all post offices and provide a progress update with timescales for collation of full details and resolution of the issues to the next PDA board meeting.”
So, at the same time that the EPOSS issue is being reengineered, you’re also being put under quite a lot of pressure to identify how long it is going to take to get the Horizon project completed, aren’t you?
John Bennett: Yes, I mean, this is a different but a major strand of the programme, which is the more practical – well, I say practical, it’s the more physical end of the programme, which is the fact that the software and the equipment associated with it needed to be installed in either 17,000 or 19,000 post offices. The number I think came down during the period, but even so it was getting on to 20,000 outlets.
I have to say on this that the information available to Pathway at the contract stage about the state, physical state, of the Post Office network was very slender, very thin, one might say very thread bare, and it was only – and we weren’t, I think – and I might have this slightly wrong, but we were not – not only us, but the other shortlisted suppliers as well – we were not encouraged or allowed during the sales campaign, during the procurement phase, to see for ourselves what a typical or a range of post offices might actually look like, in reality. That was something which was not to be available until post-contract.
Ms Kennedy: When you say it wasn’t allowed, was it something that you asked to be able to do?
John Bennett: Do you know, I can’t remember.
Ms Kennedy: Are you conscious of anyone asking the Post Office whether they could go and inspect –
John Bennett: Oh, I think so, although I dare say this wasn’t the highest thing on our list. We rather took it that the post offices would be suitable for automation and the Post Office Counters themselves would have told us in advance if they themselves had serious doubts that their estate was not or had defects or difficulties.
So we relied, I guess, on any information from the Post Office and took on – perhaps on trust or however you might describe it – the view that the network would be in good condition.
Ms Kennedy: You made assumptions about the network?
John Bennett: I guess we did.
Ms Kennedy: Shortly after this – if we could pull up POL00028442 – Peter Crahan on the 24th – if we could look at page 3 please – wrote to you to give notice of breach of contract. If we could maybe scroll down so that we can see the whole letter, thank you.
Were you surprised when you received this?
John Bennett: Sorry, can you just remind me of the date of this letter?
Ms Kennedy: Yes, it’s 24 November 1997.
John Bennett: 1997. Was I surprised at this letter? Probably not.
Ms Kennedy: Did you see the way that things were going?
John Bennett: Well, I think that everyone was having difficulty and major IT contracts nearly always have difficulties in their early days. Normally, and in most cases, those problems are dealt with but, if they can’t be dealt with, then contract cancellation is always an option. So I think, in this case, I certainly couldn’t put to one side that the government would take the option to cancel. It was always an option.
Ms Kennedy: Mr Todd’s evidence was that you were involved in producing a response to this letter and, if we could pull it up, it’s POL00031117. If we could turn to the third page, please. Were you involved in drawing up this position paper?
John Bennett: I wasn’t the author, but yes, I was aware and I inputted to this position paper. I suspect, reading it, it was produced by our legal counsel, the way it’s written, but yes, I was involved and I was aware of the content and the thrust of this position paper.
Ms Kennedy: What did you understand “without prejudice” to mean? Was that the legal person’s drafting?
John Bennett: One of the – let me just stand back from that a bit. One of the constant themes in this contract – it didn’t just start with this position paper, it started very early on, which was somewhat disappointing that so much correspondence between the sponsors and Pathway was always headed “Without Prejudice”. This is, for me, quite unusual because, in most contracts, or most IT contracts I have been involved with, the contract, once it had been signed, was normally put to one side and everyone worked on delivery.
I don’t recall in my previous roles ever constantly having correspondence which is always without prejudice. It was an unusual feature of this contract and this is perhaps another example of it.
Ms Kennedy: So the fact that it is headed “Without Prejudice” didn’t impact or affect the information that you fed into this document?
John Bennett: No, it was a constant feature of the contract.
Ms Kennedy: If we could turn to page 5, please, and if we could scroll down. This is a long document but I’m only going to take you to some key parts. Further down and, in fact, it’s across the page, but this is a section dealing with “The Authorities/PDA”.
If we could go over – yes, great, and scroll to the bottom of that page, please.
At the bottom of that page, it says:
“At the pre-contract stage, had the true role of the PDA been accurately described, Pathway would have reconsidered the commercial terms upon which it entered into the Contract.”
Do you agree with that?
John Bennett: Yes, I do.
Ms Kennedy: Have you read through this document and is there anything in its contents that you take issue with?
John Bennett: I have read this document several times and it was the result of a considerable amount of thought and work in constructing it, and I think, I would say, that this document, within the bundle of documents you have sent me, is one of the more significant documents I would subscribe to.
Ms Kennedy: If we could look at page 10 of that document and if we could scroll down. In that first line, it says:
“It became apparent during installation work for the first 200 Post Offices that many post offices are not fit for the purpose of installing automation equipment.”
Was that something you also fed into?
John Bennett: Well, I think I was talking about that a few minutes ago, so, yes. I mean, what – just what we did, as soon as we were beginning to draw up our plans for rollout, we made a point of visiting every single one of the 19,000 post offices to do our own survey, on the grounds that there were no other survey reports to work from.
So within this contract – I don’t know whether we anticipated it at pre-sales time, I suspect we didn’t, but, as soon as we started, it was clear that, since we had to install this equipment, we had to do our own surveys. And we did survey every single office to determine did it have the physical attributes to take even the limited computer equipment we provided, did it have sufficient power supplies to drive those devices, did it have the capability to be connected to a network and how much work, by whom, needed to be done to bring it up to a satisfactory state.
That was a job which fell on ICL Pathway to do and we did it for every office.
Ms Kennedy: Sir, that might be a convenient moment to take a short break.
Sir Wyn Williams: Thank you and what time should we start again?
Ms Kennedy: 3.10?
Sir Wyn Williams: Certainly, okay.
Ms Kennedy: Thank you.
(3.00 pm)
(Short Break)
(3.10 pm)
Ms Kennedy: Sir, can you hear me?
Sir Wyn Williams: Yes, I can, thank you.
Ms Kennedy: Thank you.
Picking up where we left off then, if I could bring up a further report that you wrote on 10 July 1998. It’s FUJ00058174. Thank you. If we could turn to page 5, please, and if we look at the fourth bullet point down it states:
“The main stress point on NR2 testing continues to be with the EPOSS system, testing together with POCL reference data. Resources have been reallocated within Pathway to bring more effort onto this area and extra skills are being brought in from elsewhere in ICL.”
If we turn over to page 11, and we’re looking halfway down the page, it states – so towards the bottom of the screen:
“The volume of system incidents (PinICLs) is perilously high. Clearance plans are being devised to are all products.”
If we look to the bottom of that page, it says:
“The current architecture for the TIP interface module may not be capable of supporting the entire network. The simulated tests suggest that it cannot harvest the daily transactions generated by EPOSS and send them to POCL in the overnight time slot available.”
So, as at July 1998, the EPOSS issue is reaching a point where you are needing to deploy extra resources into it; is that right?
John Bennett: Yes, yes, we did need to put more effort in.
Ms Kennedy: Were you being put under pressure to clear PinICLs at that stage?
John Bennett: The pressure was self generated. There was a clear recognition that there were many more errors than we expected and that these were growing rather than retreating, if I put it that way, and so the effort was doubled down on this system and I think there were – you may talk about it later. There were a number of technical audits carried out on the development process to try and find a way of bringing our development work of EPOSS more under control.
Ms Kennedy: Shortly after this report, you set up a task force, an EPOSS task force; do you remember that?
John Bennett: I remember it but let me put it this way, personally I don’t remember that task force, it was 24 years ago, but if I look at the bundle of documents you sent me I have had a read of that task force report so I’m familiar with it in terms of it within your bundle, although I don’t particularly remember it directly myself.
Ms Kennedy: The task force at the time would have been reporting to you as the MD; is that right?
John Bennett: That’s not quite right. Let me step back a bit. In Pathway, we conducted every year a range of audits, in-house audits, technical audits and in – I’m not sure what year this is, is this 1998?
Ms Kennedy: 1998.
John Bennett: Well, in 1998 – particularly in 1999, which I remember better, we embarked upon probably several technical audits and one technical audit was indeed to do with this task force, looking at the development of EPOSS. This technical audit was produced for my development director. It was he and his staff who were writing the software and this audit report was produced for him and his team.
And if you look at my report, which you have done, you will see it was sent to a lot of people and I indeed was sent a courtesy copy so, in a sense, I was sent a copy of this task force report. But, being an audit report, it was sent to my development director and his boss, which is the overall programme director.
Now, the principle in Pathway was that if we had an in-house audit then the process was that when the audit report was completed, all those recommendations would be reviewed by the responsible directors and the corrective actions would be registered, recorded and were placed with owners. And I think you will find that, as far as that task force report was concerned, that’s exactly what happened and the corrective actions from that task force report were recorded, owners were placed and there is a record of that in this bundle.
Ms Kennedy: We will come back to the eventual report from the EPOSS task force in a moment, but if we could move forward to August 1998 and we could pull up POL00031127. This is a Bird & Bird expert report produced on the BA/POCL payment card programme and if we look at page 4, we can see the purpose of the report and the terms of reference. So this is at the stage of assessing the strength and weaknesses of the sponsoring authority’s case.
If we could turn to page 12, please, and scroll down, we can see at paragraph 304 that you are mentioned in the middle of that paragraph. The paragraph reads:
“We have not yet conducted a review of the project management of the programme by ICL Pathway, the PDA and the Sponsoring Authorities. Our initial impression is that no formal methods, such as PRINCE, were used. There are well prepared, high level, plans documented in the various versions of the Master Plan and we understand that lower level plans may have been prepared in some areas. The comment by Mr Bennett of ICL Pathway at the PDA Board meeting on 13th August 1996, when Master Plan version 1 was approved, is revealing. The minutes state … ‘Mr Bennett confirmed that ICL Pathway were anxious to progress from drawing up plans to actually using them and were content therefore to sign off this version for that purpose. He did however want it placed on record that the plan quoted dates which were a mixture of agreed baseline, planned targets and hoped for dates and that this weakened the effectiveness of the plan and the process for review’.”
If we turn over the page and scroll down it says:
“Our impression from the work we have carried out to date is that Mr Bennett’s comments of 13th August 1996 reflect the weakness in the project management approach taken by ICL Pathway at that time.”
Do you have any comments on those words in the report?
John Bennett: I’ve never seen this report before so I don’t know its pedigree at all. I do notice that it is August 1996, which is early in the process and I would have – I was of the view that, certainly around that time, the programme management processes ICL Pathway was adopting were quite extensive, but I think that’s probably a better question for my programme director or my development director to answer, so I can’t say much more about this report.
Ms Kennedy: If we then move forward in time to May 1999, you produced an update for the board at that stage, which is at FUJ00117463. Could we turn that up, please. If we look at the top, you have stated:
“The ICL proposal submitted in December 1998 has not been progressed or discussed since that date and we have now formally withdrawn it.”
It then sets out a number of options and, if we scroll down we can see option B1.2 and you set out there the proposal for that suggestion should the BA Benefit Payment Card be cancelled. So, at this stage, you are already sketching out a plan for if the BA benefit card is cancelled, aren’t you?
John Bennett: It looks like it, yes.
Ms Kennedy: Do you remember this from the time?
John Bennett: Not specifically, but it’s – it sounds quite familiar.
Ms Kennedy: If we turn to page 7 of that report and we look in the “Programme Status” section, in the middle of that section, it says:
“All the 200 post offices running release 1c have been successfully converted to NR2 [New Release 2] which is running well in terms of the day-to-day transaction operations. There are however, major problems with the cash account balancing which takes place on a Wednesday evening and this has been analysed as much more to do with the business processes, business support and the skill knowledge of subpostmasters, rather than structural issue with the Pathway system. Nevertheless, it will require joint effort to straighten out.”
That’s quite a crucial issue that you have identified in that report, isn’t it?
John Bennett: Yes, I think it is. I think it begins to draw us to the understanding that the complete delivery of this aspect of EPOSS, which is the critical one to do with the accounts and the balancing of these accounts, required quite a lot of activity across a wide spectrum. It clearly involved Pathway and what we were doing, but it required – and it hasn’t been – well, it’s referenced a little bit in the document you pulled up a little while ago.
It relied, to start with, by very good input to us from the reference data system being developed within POCL and I think, if you look at the correspondence, in order to address these end-to-end issues, we do advise a thorough review of the end-to-end process. I think people probably understand that, to produce accounts in the Post Office, you need to know how much you are charging for individual products being sold. Now, it’s a very similar – I’m not an expert on reference data but, in its simplistic form, we relied on reference data to tell us the status and pricing of every product to be transacted across the counter.
And, if you think about it, taking a very simple example, if the Post Office changes the price of, let’s say, a First Class stamp – it sounds very easy and it’s probably the simplest product to think about – what we have to do is to make sure that every single one of the maybe 40,000 counter positions in perhaps 19,000 post offices, uses the new price at exactly the same time and that’s just one simple product and, of course, there are hundreds – I don’t know how many, but there were several hundred products which are marketed through the Post Office network.
And to get the accounts right at the end of the day or the end of the week, every single product has to have its exactly right price at the right time and I think it was recognised that – and this isn’t from a Pathway audit, but I think it came out from other audits, that just as much as we had work to do in Pathway, there was a lot to do, to do with the integrity of the reference data information which would impact on the ability to produce good accounts at the end of the week.
So that was a factor, but I think overall this paragraph does draw you into the complexity of getting end-to-end EPOSS working at the level everyone wanted.
Ms Kennedy: You also suggest, don’t you though, that the skill knowledge of the subpostmasters was an issue, rather than the structural issue – there being a structural issue with the Pathway system?
John Bennett: Well, I’m not trying to dodge the issue that we had problems ourselves. We had a lot of problems and you have referred to those earlier but another end of the EPOSS service is, of course, what happens in the post offices themselves and that, I think, takes you into a broader issue, which is to do with the adequacy of the training for the staff who had to use the system.
We were contracted to provide substantial training to staff, both the managers and, indeed, the other staff operating the system, but this was – has often been referred to as a major management of change programme and whether it was sufficient to rely just on technical training on how to use the system to really cope with the issues of helping 30,000 people with a variety of skills, fears and motivation to use the system well is a big challenge.
And I think – my understanding, my knowledge of the EPOSS system end to end is that parts of it were well used and people liked, which was the daily transactions, the ability to construct – to register a transaction during the day when dealing with people across the counter, in other words the interaction across the screen. I think that system, from my recollection, was generally well used and well liked.
The real weaknesses, which is what you have pointed to, were really to do with the end-of-week accounting process, which proved to be, for many people, very difficult.
It was perhaps my understanding – I admit I might have this wrong – that the question of balancing had been a big issue well before Pathway introduced EPOSS. In other words, the paper-based system which pre-dated the Pathway or the POCL system was never an easy system to use at that time and required – I might have this wrong and I’m perhaps talking outside my knowledge, but I think balancing at the end of the week had never been an easy thing to do.
Ms Kennedy: On 14 June 1999 you gave evidence to the House of Commons Select Committee on Trade and Industry. Do you remember that?
John Bennett: Yes, I do.
Ms Kennedy: Your position, is this right, was that you didn’t think that there was a technological or technical issue with the system and that this system was extremely robust and applicable?
John Bennett: If I said that, I must have said it.
Ms Kennedy: Shortly after that, the Post Office agreed to accept Horizon on a conditional basis, provided criteria were met. If I could ask you to look at a document from 27 September 1999. It is FUJ00079189 and it is page 2, and it says:
“I am delighted to confirm the completion of acceptance: the second stage has been successfully finalised by the signing of the second supplemental agreement on 24 September 1999.”
Did you feel at this time like you had a complete endorsement of the system and that no further work was required?
John Bennett: No, but I would pick issue with you about the acceptance being conditional. There was no question of it being conditional. The system was either accepted or it was not accepted. It is true that, once the system was accepted, there were a number of Acceptance Incidents which had to be addressed later on, but acceptance was acceptance, it was not conditional.
Ms Kennedy: If we could look at an audit – you mentioned audits earlier. This audit was carried out on 28 October 1999 and it is at FUJ00079782. If you look at that there, you can see this was one of the audit documents you were referring to earlier; is that right?
John Bennett: Well, this is an audit document. Whether this is – yes, it’s an audit document, yes.
Ms Kennedy: We can see that you are on the distribution list for this one.
John Bennett: Am I?
Ms Kennedy: John Bennett, distribution.
John Bennett: Oh, yes, correct, yes.
Ms Kennedy: If we could turn to page 19 of this document. Mr Austin was taken to this document earlier, so I don’t intend to read it out again, but if you could read it to yourself, Mr Bennett, it’s the third paragraph – well, from the first paragraph onwards and let me know once you have finished.
John Bennett: Sorry, from the first paragraph?
Ms Kennedy: Yes, from under “Commentary”.
(Pause)
John Bennett: Right, I have read what’s on this screen.
Ms Kennedy: Thank you, and if we could turn over the page, thank you. Pausing there:
“The figures indicate that the problems facing EPOSS during the Task Force period have not diminished. Of greater concern are the non-EPOSS PinICLs within the group suggesting that there are still serious quality problems in this vital, customer facing element of the system.”
Then underneath:
“The EPOSS Solutions Report made specific recommendations to consider the redesign and rewrite of EPOSS, in part or in whole, to address the then known shortcomings. In light of the continued evidence of poor product quality these recommendations should be reconsidered.”
So, at this stage, there’s the suggestion that EPOSS should be rewritten; isn’t that right?
John Bennett: Correct.
Ms Kennedy: This is 28 October 1999.
John Bennett: Yes.
Ms Kennedy: So this is very late in the design of the programme, would you accept?
John Bennett: Yes, it is.
Ms Kennedy: If we could turn to the next document in the series, which is FUJ00079783. This is another development audit and, again, we can see you are on the distribution list and, if we could turn to page 6, again, Mr Austin was taken to this, this morning. Your initials, are they under MTM, “JHB”?
John Bennett: Yes.
Ms Kennedy: So you were the – I believe this means the managing – even though Mr Austin was the owner, you were ultimately managing him?
John Bennett: Well, his direct manager was Mike Coombs, MJBC, and Mike Coombs was the technical – was the programme director working for me, who had technical authority for the programme. So, yes, the development director Terry Austin worked for the programme director Mike Coombs who was a member of my management team. But he was the overall programme director.
Ms Kennedy: Were you aware of this suggestion or recommendation that EPOSS should have been rewritten or could have been rewritten at this time?
John Bennett: Well, I’m aware of this – only by reading these reports. I have read this report and I think under “Actions” you can see that the view of my – I don’t know, is this the one? Yes, the view of my development director, which it says here at the end:
“We will … continue to monitor the PinICL stack … and … re-evaluate this decision. Would [you] please close this issue formally using the rationale described.”
So that was the assessment of my development director and that was accepted by his boss the programme director.
Ms Kennedy: So you wouldn’t or didn’t have input into that decision?
John Bennett: No. It never came to me to make a managing director’s decision on this point.
Ms Kennedy: If we could move forward in time to 20 December 1999. You wrote a further report. If we could pull it up, it’s FUJ00058188. If we could turn to page 6, please, and scroll down. It states:
“The most serious issue on acceptance resolution concerns AI376 and the integrity of the accounting data being managed from the end to end basis with Horizon. This in turn requires more disciplined and strict accounting integrity controls, some of which can be achieved through the EPOSS reconciliation software and others through process and independent tools and the balance through stronger end to end control of the reference data processes.”
So, at this stage, this issue is causing you still a great deal of concern?
John Bennett: Yes.
Ms Kennedy: What do you understand in relation to the integrity of accounting data being managed from the end to end basis with Horizon?
John Bennett: Well, I think it’s – well, I’m only interpreting what it says here, that the – whether there were errors in the accounting data which were being promulgated through the system and could you therefore trust the way the accounting data was being managed. And it does make the point, I think, which I think we talked about a bit earlier, that there’s a lot of areas where the integrity can be compromised and there were steps put in place to try and address these.
Ms Kennedy: Did you feel that you were across or had adequate knowledge of the steps that were going to be taken to get across this and resolve this issue?
John Bennett: Well, I think, as we said earlier, we thought that there was work we had to do with our software. We had a lot of discussion about how the training facilities with Post Office based staff should be improved or augmented and I think it called for a new set of training courses to help people with – I think there’s new documentation, as well, for guidance and guides how to use the system.
There was plenty of opportunities for user errors in running the end-to-end system, which we thought had to be dealt with. So you had a component in the Post Office themselves with how the staff can be helped to use the system, you have problems in the use of software – and it’s not recorded here, but I know there was an issue concerning how long it took to print-out reports in the post office itself, which was a source of concern – and then there was, as it says here, stronger end-to-end control of reference data. So there were plenty of steps in this process where improvements could be made, a number of them obviously were with ICL Pathway.
Ms Kennedy: Did you feel that the programme was fit for purpose when it was rolled out?
John Bennett: At some point, and I’m not quite sure in this documentation where it is recorded, AI376 was deemed to have been handled to such a level that the software was judged suitable to go into live use. So, at some point, yes, this was considered, notwithstanding these weaknesses, the system was judged fit for purpose for live use.
Ms Kennedy: When in 2000 did you leave your role in ICL Pathway?
John Bennett: Well, I was beginning to withdraw towards the end of 1999. I mean, if you look at some of the ICL Pathway board meetings you will see that my successor was in fact attending board meetings in 1999 and I think my last board meeting was either January or February 2000, I’m not absolutely sure.
Ms Kennedy: If we could turn up WITN04600104 please. This is a further version of a document that we looked at earlier, dated 10 May 2000, so this may well postdate your departure. But if we could look at page 7 –
Next page, I think. Sorry, one moment. Page 9. Yes, over the page.
So we have seen all of this before but if we could turn over the page, and you commented on the agreed action before, but this is new. Could you take a moment to familiarise yourself with the “Agreed action” column.
(Pause)
John Bennett: Yes, I have read that.
Ms Kennedy: Are you able to help us with what happened between November and May that results in this particular issue being closed?
John Bennett: No, I can’t fill in the gap, but I can notice that you will see that this report was actually sent to my successor, Mike Stares, so he is on the distribution list for this and you can further see that Mike Coombs, who was the programme director to whom the development director reported, really supported the previous view of my development director that this code should not be redesigned or rewritten at this time. In fact, Mr Coombs makes it more clear in that final paragraph of actions – let me just have a look:
“Effectively as a management team we have accepted the ongoing cost of maintenance rather than the cost of a rewrite.”
And I think that was the judgement of my programme director and I – although I wasn’t, as you say, on – in post in May 2000, I would have supported his judgement.
Ms Kennedy: To your knowledge, were Post Office employees able to review PinICLs?
John Bennett: Do you know, I’m not sure, but I would have thought they would. We were working very closely with Post Office and AI376, which lies behind an awful lot of this, was actually raised by the Post Office Counters’ people so they would have been very much aware of everything going on with end to end EPOSS service, including the closure of AI376. It was their decision to close it.
Ms Kennedy: You may have heard the evidence of Mr Oppenheim yesterday. Did you consider that remote access by ICL and Fujitsu a facility that was so obvious that it didn’t need to be set out or explained?
John Bennett: Sorry, could you repeat the question.
Ms Kennedy: So remote access, the ability to access branch data remotely, would you consider that so obvious that it need not be minuted or explained, the ability?
John Bennett: Well, I was – I did see that statement elsewhere. I didn’t hear the evidence from Mr Oppenheim, but I have seen in one of the reports the suggestion that ICL staff or ICL Pathway staff would somehow have access to transaction data. I found that an amazing allegation or suggestion and, in my view, that was never contemplated or happened. It was never suggested it should happen and I really don’t know why and where anyone should think that could have taken place.
Ms Kennedy: Mr Bennett, I don’t have any further questions for you.
Chair, do you have any questions for Mr Bennett?
Sir Wyn Williams: No, thank you.
Ms Kennedy: If I could pass to Mr Jacobs.
Mr Jacobs: Thank you. Sir, can you see and hear me?
Sir Wyn Williams: As usual, Mr Jacobs, I first hear you and now I see you.
Mr Jacobs: Thank you, thank you.
Sir Wyn Williams: There’s always a delay between the two.
Questioned by Mr Jacobs
Mr Jacobs: Yes.
Mr Bennett, good afternoon. I have some questions for you on behalf of 153 subpostmasters who are represented by Howe & Co and I want to ask you some questions concerning paragraph 30 of your witness statement, and can I ask that we could just have that on screen. It is WITN04 –
Ah, it is here already. Thank you very much, Frankie.
So you say:
“Throughout the rollout the Post Office had full visibility of ICL Pathway’s key activities including all the incident recording and resolution processes.”
Now, we know, Mr Bennett, from the findings that were made in the High Court, that the Post Office was unable to access audit data or ARQ data, which was held by Pathway and are you aware of what that is, are you familiar with that?
John Bennett: I’m afraid I’m not. I assume that’s information captured at the counter when transactions were processed.
Mr Jacobs: Absolutely correct, yes. It’s the keypad activities, what keys are pressed –
John Bennett: Yes.
Mr Jacobs: – when they are pressed by the subpostmasters. It emerged that Post Office had to request that from Pathway and, after a certain amount of requests, then Fujitsu were contractually entitled to charge them for providing that information.
I want to ask you about what you say about visibility of Pathway’s activities. Are you aware of any other data or key material, which was held by Pathway, which Post Office was unable to access without requesting it of Pathway?
John Bennett: Well, first of all, I don’t – I mean, your original comment about audit data, I didn’t realise that this wasn’t available to Post Office. It was captured by Pathway because we captured everything which went on, so I could see why people would want access to it, I can understand that. I can’t understand why it wasn’t available.
Taking your second point, can I think of any other areas, well, I dare say someone will find something which we didn’t pass on but I would make the general point that, under my direction, most of my staff operated a very transparent process of the work we were doing and the problems we were having and we would share them as appropriate with people who needed them. This was a technical programme to get right and there was no value in not sharing critical information. So I can’t – I can’t think of anything, no.
Mr Jacobs: That’s helpful, and perhaps you might not be able to answer my next question, but I will ask it anyway.
You said in your evidence today that you were working very closely with Post Office.
John Bennett: Yes.
Mr Jacobs: What mechanisms were available for Post Office to access data held by Fujitsu? If they wanted to do so, how would that be done?
John Bennett: Well, I suspect one of the key providers or key conduits for that would be the PDA.
Mr Jacobs: Right.
John Bennett: Because, I think as we discussed a lot earlier, most of our contact with the Post Office had to be through the PDA.
We had very little direct, technical programme contact, directly with the Post Office themselves. I think the PDA was our source of interface.
Mr Jacobs: Thank you.
John Bennett: I mean, I don’t – I’m quite sure, from time to time, we met with Dave Miller and his people and all sorts of things but, in terms of programme management and programme development, the sponsors were very clear they saw us routing our information, both ways, through the Programme Development Authority.
Mr Jacobs: But you’re not aware of a specific mechanism?
John Bennett: Not as a mechanism, no.
Mr Jacobs: Okay, and just for completeness perhaps, you have heard that some information Fujitsu was contractually entitled to charge Post Office for. Were you aware of charges for any other information or data?
John Bennett: In my experience, we charged for virtually nothing for five years on this programme. I mean, one of the big issues for us was that we worked for five years without any payment and our payments didn’t start until pretty well the end of 1999.
Mr Jacobs: Yes.
John Bennett: Even though we started work in 1994 and, in-between 1994 and 1999, I would consider the income we would have earned through any charging mechanism to be infinitesimally small.
Mr Jacobs: Well, thank you. I might have some further questions for you but I’m just going to ask those who instruct me if there’s anything else that I need to ask you.
I don’t have anything else for you. Thank you very much.
Ms Kennedy: Chair, apologies, I understand that Mr Henry may be putting three documents to Mr Bennett, I believe two of which Mr Bennett has seen but one of which has not been seen and I believe someone should be handing a copy of that now.
Unfortunately, one of the documents, which is an organogram, is not on the system and can’t be shown on the screen.
Mr Henry: The organogram is actually POL00089867.
Ms Kennedy: I’m told it’s not with RTS and can’t be shown on the screen.
Mr Henry: Oh, I’m so sorry. That’s a shame, because I had quite a number of questions to put on it but not to worry. Let me see.
Questioned by Mr Henry
Mr Henry: Mr Bennett, I’m very sorry, what have you got in front of you now? Have you got –
John Bennett: I’ve got two documents I have seen before –
Mr Henry: Yes, and you’ve got one page.
John Bennett: – and I’ve got a one-page organisation chart.
Mr Henry: What a shame because, although I gave that as a reference, the organogram, on reflection, I would quite like to put about ten pages out of that presentation, which of course you and ICL Pathway gave in a sort of all-day session with POCL on 19 November 1996 and you couldn’t possibly remember that all-day session, but let’s just go to the page you have got and that shows the accountability hierarchy at ICL Pathway in 1996, doesn’t it?
John Bennett: Yes.
Mr Henry: So we have you as managing director, correct?
John Bennett: Correct.
Mr Henry: Then if you’re the admiral, your rear admirals or vice admirals are director quality and risk management, Martyn Bennett, correct?
John Bennett: Correct.
Mr Henry: Director of commercial and finance, Tony Oppenheim, okay? So they sit, as it were, to your left and right.
John Bennett: I think that’s drawing too much from this chart.
Mr Henry: Really?
John Bennett: I think you should consider all these people as my direct reports.
Mr Henry: So they are your direct reports?
John Bennett: Yes, rather than some form of different – it doesn’t –
Mr Henry: But you are the managing director?
John Bennett: Oh, yes, but I don’t know why you refer to these two – I consider them all to be my direct reports, simple as that.
Mr Henry: I see, all right. But you are the managing director?
John Bennett: Correct, yes.
Mr Henry: Oh, yes, quite clearly. Then we have a line, a direct and unbroken line, like a plumb line, down to programme director Terry Austin, so he was your direct report as well?
John Bennett: Correct.
Mr Henry: Right. Then we have a business development director, Liam Foley, we have customer services director – is it Stephen Muchow?
John Bennett: Stephen Muchow.
Mr Henry: Muchow, right. I won’t – customer requirements director John Dicks, et cetera, et cetera.
Could I just ask you to consider various things and I’m going to make it absolutely plain to you that, if you cannot remember, then you must obviously say so, because the last thing I would want to do is to put you in an invidious position. But let me just ask you about what POCL wanted because you had, up until a very late stage, as it were, two customers, didn’t you?
John Bennett: Yes.
Mr Henry: Yes, and the dominant party was the DSS?
John Bennett: As far as I’m concerned, they were joint partners, they were joint customers.
Mr Henry: Really?
John Bennett: They each had their own requirement but they were both equal standing customers.
Mr Henry: But 30 per cent of POCL’s revenue came from DSS BA, didn’t it? You knew that?
John Bennett: I – well, no, I didn’t know that.
Mr Henry: I mean, would you not have become familiar with what your client, or one of your clients depended upon?
John Bennett: I was very well aware that Benefits Agency were one of the most important customers POCL had. I didn’t know it was 30 per cent.
Mr Henry: You, of course, were present, weren’t you, at a meeting which took place on 3 July 1998, correct, with Mr Keith Todd and also Frank Field?
John Bennett: Yes.
Mr Henry: You have that, it’s FUJ00075721. Do you recall that Mr Field, the Minister, talked about the Post Office dependency culture and the concern in maintaining the Benefit Payment Card?
John Bennett: Can you refer me to which paragraph?
Mr Henry: Yes, of course. We have a reference to the Benefit Payment Card at 4.5, do you see?
John Bennett: Yes.
Mr Henry: “We spent a lot of time on the benefits of the payment card and not surprisingly picked up this question of part payments. The minister was particularly keen to know that our system was quite capable of handling part payments and that the constraint was essentially a BA rule.”
Then we considered – 4.7:
“… some time discussing the wider use of cards across government to connect various government services together.”
John Bennett: Yes.
Mr Henry: 4.8:
“We discussed the need for the Post Office to move to a more commercial outlook and Keith explained that their difficulty with payment systems was more to do with concern about their funding arrangements and that if the Post Office was block funded then they would probably take a more relaxed and open minded view of how to meet modern payment systems. Frank Field called this the Post Office dependency culture.”
But then 4.9:
“There was no strong reaction to our key comment that the progress to ACT [Automated Cash Transactions] was inevitable but would take time and had to be managed alongside re-engineering of the Post Office network.”
Now, you were effectively drafting this diary note from that meeting, weren’t you?
John Bennett: Yes, I wrote this note.
Mr Henry: Absolutely. So what I’m trying to suggest to you is that that was primarily the concern at that time and, so therefore, the DSS was the dominant partner?
John Bennett: I’m prepared to accept your opinion.
Mr Henry: Could I just ask you, please, to just help me a little bit about Mr Todd’s managerial style.
So far as you were concerned, you were reporting back to him, were you, candidly and frankly everything that was going on from those who were directly reporting to you?
John Bennett: Yes, I was his direct report on this project. It was a bit unusual because most of the business in ICL went through established business divisions. We had a retail division, we had a government division, we had a finance division, et cetera. But this programme was sufficient size and importance that this organisation broke the normal organisation rules. So, rather than reporting through an established line business, which is what we would normally do, I was a direct report to my chief executive.
Mr Henry: What about Sir Graham Corbett?
John Bennett: Graham Corbett? He was nothing to do with –
Mr Henry: The chairman of ICL?
John Bennett: Graham Corbett was not the chairman of ICL. You have the wrong man.
Mr Henry: Forgive me, I will withdraw that. So you were, therefore, tasked with being the messenger to Mr Todd?
John Bennett: I reported to Mr Todd and he was my boss.
Mr Henry: Yes.
John Bennett: That’s not a –
Mr Henry: I didn’t mean that pejoratively –
John Bennett: Well –
Mr Henry: – but if you had to bring him bad news –
John Bennett: I reported everything to Mr Todd.
Mr Henry: You reported everything to Mr Todd. Clearly, at that time, sir – and I note what you say about gradually, as it were, distancing yourself from direct responsibility from about, what do you say, 1999?
John Bennett: Well, the end of 1999/early 2000.
Mr Henry: Yes, but clearly, at that time – if we go over the page to page 3 and paragraph 7 – you were clearly the –
John Bennett: Sorry, can we just – which document – oh, this is the same document.
Mr Henry: Same document, sir, yes.
John Bennett: Yes, I’ve got it?
Mr Henry: Paragraph 7 which is on page 3?
John Bennett: Page 3, which paragraph?
Mr Henry: Paragraph 7.
John Bennett: Right, thank you.
Mr Henry: This was a list of the action points that arose from that meeting and, clearly, with one exception, you were deputed or, of your own initiative, had to execute the vast majority of those actions, didn’t you?
John Bennett: Yes.
Mr Henry: So, for example, the draft letter confirming the parallel approach, the sort of compromise approach, correct?
John Bennett: Well, all these actions I can see are directed to me to discharge.
Mr Henry: Yes, yes, the visit to Feltham, that’s not particularly important. You then talking to Derek Sayers for details of the employment services business, so trying to, as it were, capture more business, correct?
John Bennett: Yes, that’s another aspect of ICL’s business.
Mr Henry: You to write to Mr Field reconfirming Horizon’s capability of handling part payments under the BPC, correct?
John Bennett: That’s what it says.
Mr Henry: Yes:
“… to discuss with Terry Reynolds the impending visit of [Mr] Field to … An Post …”
And family budgeting, in other words his campaign against poverty, you know, to sort of teach people how to manage their own money under the system; would that be right?
John Bennett: This is the action.
Mr Henry: Yes. Then:
“[Mr Todd] to speak urgently to John Roberts to get much more vigour and energy behind the Post Office’s move to financial services.”
John Bennett: Yes, I think on that I would say that Keith Todd had a very strong view, and he expressed it on many occasions, he thought the Post Office had a huge opportunity in being more dynamic and active in the banking field and he thought that, just as the Post Office network had a huge coverage in the UK, against a climate of high street banks retreating from towns and villages, that this opened up a new business opportunity for Post Office Counters and he was thinking well beyond the BA/POCL contract as to how some of these more visionary services could be used to enhance the network, Post Office network, and provide a better service to the community.
Mr Henry: You obviously bought into that vision?
John Bennett: We did, indeed, although our focus was delivering the contract, not –
Mr Henry: Yes, of course?
John Bennett: – not thinking too far ahead.
Mr Henry: But if I could bring you back, therefore, to paragraph 2 of that document on page 1, because of course the Minister, his opening remarks were that he was keen to see Mr Todd to talk about social banking, whereas Mr Todd’s opening remarks were that he was here to talk about the programme in the round and the key points were that Horizon is:
“deliverable, that it is critical to ICL as well as DSS, POCL and Government and that the infrastructure being built is essential for all aspects of fraud, welfare reform, the future of the Post Office and all aspects of better government.”
He was going at it not less than 100 per cent, wasn’t he, from the beginning of the meeting?
John Bennett: Yes.
Mr Henry: So when you say that you didn’t feel under any pressure to deliver, if I ask you –
John Bennett: Sorry, can you just repeat what you say I have said?
Mr Henry: Well, you didn’t feel under any great pressure to –
John Bennett: Do what?
Mr Henry: – deliver the project. You said that earlier.
John Bennett: No, I didn’t say that.
Mr Henry: Really?
John Bennett: I said that we were always under – I’m not sure I would use the word “pressure”, but if you run a programme like this you are always energised to get on with the job.
Mr Henry: Yes.
John Bennett: I wouldn’t call that somehow unrealistic pressure. If you run a programme like this then you, every day, are working hard to make progress.
Mr Henry: Of course.
John Bennett: I wouldn’t call that pressure, I would call that normal operating.
Mr Henry: Could I ask you – and I have nearly finished because, obviously, I can’t put things to you from a document which you haven’t seen and which isn’t on the system, so I’m going to abandon that whole tranche. But you appear to say that it was Mr Coombs’ decision – and do correct me if I’ve got this wrong – that it wasn’t necessary to rewrite the IT; is that right?
John Bennett: No, I think we were talking about rewriting the code for the EPOSS. Redesign and rewrite a part or all of the EPOSS software.
Mr Henry: Exactly, that’s what I meant. Are you saying that that was his exclusive responsibility?
John Bennett: He was the technical authority on the programme and I trusted his judgement and his authority was what I followed. His judgement was what carried and I implemented.
Mr Henry: But, ultimately, were you not – I’m not saying you were ultimately accountable, I will rephrase that. I mean, obviously, ultimately, those above you are ultimately accountable, but you were the managing director, were you properly and fully sighted on that momentous decision?
John Bennett: There were many momentous decisions during the six years I was managing director of Pathway and I learned, over that time, whose judgement I would follow and who had the authority. Now, Mike Coombs – if you’re talking about Mike Coombs in this case – was probably the most professional, skilled and experienced man in ICL in programme management and I would not overrule his judgement.
Mr Henry: But surely this is not simply a technical issue?
John Bennett: Isn’t it?
Mr Henry: This is a governance issue about: (a) suitability of the programme for your customer; and also (b) as you have alluded to in the answers you have given a short while ago, cost must have played some consideration in this?
John Bennett: I think it was a technical decision, based upon economies and cost, and I think Mr Coombs in the paper we looked at a moment ago explained the two options which were in front of us and the two options were either to continue to manage the system we had developed, with its benefits and drawbacks, or to involve a major rewrite, which, again, had benefits and drawbacks. His judgement, which is well recorded in the papers, was that we were better off managing the system we had and, at that time, that was what was done.
Mr Henry: If you had not chosen to go down that path there would have been further delay, would there not?
John Bennett: Well, we didn’t go down that path, so I couldn’t speculate on that.
Mr Henry: Well, obviously, if you were going to – it’s not a question of speculation really, it’s a question of common sense. If you weren’t going to rewrite that EPOSS issue and EPOSS would have been part of the backbone of the system, wouldn’t it? The Electronic Point of Sale Service, it would have been part of the backbone of the system for a subpostmaster in his office?
John Bennett: It was very important to get that decision right.
Mr Henry: It would have been the backbone, wouldn’t it?
John Bennett: It was a critical – it was one of the most critical systems in the Post Office.
Mr Henry: Absolutely. Transaction information processing: again, part of the backbone, correct?
John Bennett: It’s a key system.
Mr Henry: Inventory management: part of the backbone?
John Bennett: A key system.
Mr Henry: Yes, so if you were going to rewrite that there would have been delay, wouldn’t there?
John Bennett: Well, I think there is clearly pros and cons of either two options, and both –
Mr Henry: I won’t ask the question again. I won’t ask the question again. I suggest to you it would have been obvious that there would have been delay.
Cost. Obviously, you would have had to have invested more in rewriting, wouldn’t you?
John Bennett: The judgement was that that was not the best option available.
Mr Henry: Again, I won’t ask the question again.
Opportunity cost. The cost involved in rewriting would prevent you from utilising staff and resources to work on other projects?
John Bennett: That’s absolutely true. Every decision you take has an opportunity cost.
Mr Henry: Then, of course, Her Majesty’s government might have something to say about this, wouldn’t it?
John Bennett: I can’t answer that one.
Mr Henry: Well, you can because, of course, they had already – and you would have been aware of this – put you in breach of contract in November 1997.
John Bennett: We rejected that breach.
Mr Henry: I’m sorry?
John Bennett: We rejected that breach.
Mr Henry: Well, that –
John Bennett: And that breach was never carried out.
Mr Henry: Yes, but the position was, wasn’t it, as well, that there were – I mean, I won’t go through them in detail but, eventually, you were proposing, and I suggest that you should have been aware of this if you were dealing with this with Mr Todd, that there was a proposal not to do live testing or to drastically reduce testing of the system. Do you recall that?
John Bennett: I don’t recall a debate about reducing testing, no.
Mr Henry: Were you aware of a problem, as well, about evidence of ownership of assets involved, such as perpetual licences for intellectual property?
John Bennett: No, I have not – that’s not a subject I have any recollection of.
Mr Henry: I mean, if I put something to you (unclear) accept it but, isn’t it right that An Post, which was supposed to be, forgive me, the poster boy for a wonderful system, was, in fact, in April 1998, in a massive court case and dispute with no less than Escher over who actually owned the IP?
John Bennett: I don’t remember that at all but I take your word for it.
Mr Henry: Well, because I want – final this: when you say that you, in fact, put the source code into escrow in case anything might have happened, and you said that earlier this afternoon –
John Bennett: Yes.
Mr Henry: – you must have had a memory of why that was?
John Bennett: We put it there because we saw the risk of a small company not being in business during the life of this contract.
Mr Henry: Forgive me, sir, were Escher aware that you put their source code into escrow?
John Bennett: They certainly were.
Mr Henry: Were you aware –
John Bennett: We had – I mean – sorry, I don’t mean to interrupt, but we couldn’t put their source code into escrow unless they gave it to us.
Mr Henry: Thank you, because obviously then – I mean, weren’t they supposed to be bought out by Andersen Consulting?
John Bennett: I don’t remember that.
Mr Henry: You don’t remember that. Well, thank you very much for answering my questions.
Sir Wyn Williams: Is there anyone else who is intending to ask any questions?
Ms Patrick: Yes, sir, Ms Patrick.
Questioned by Ms Patrick
Ms Patrick: Mr Bennett, my name is Ms Patrick. I ask questions for 64 subpostmasters and I’m instructed with Mr Maloney KC, who sits beside me, by Hudgells Solicitors.
I only have a few questions for you, following up on two points that Mr Henry was raising with you, a visit to Feltham, but instead of looking backwards, I may be looking forwards, as it were.
The potential for the future commercial exploitation of Horizon was important, both for ICL and for POCL?
John Bennett: Yes.
Ms Patrick: But first Horizon had to work and be seen to work?
John Bennett: Yes.
Ms Patrick: Can we look, just to perhaps refresh your memory, at how you closed out 1999 in your end of year communication to the ICL staff. I think you have seen this document but we can bring it up at FUJ00075736, and it is the first page.
On the left-hand column – you see there are two columns to the document and I’m looking at the second paragraph on the first column to start with and I’m going to start a little of the way down, maybe about a third of the way down the paragraph, you will see there’s “There”:
“There are still some important issues which we are working on with the Post Office but we plan to restart rollout on 24th January 2000 at which time we will rapidly reach the rate of 300 post offices per week, completing as planned in spring 2001. Meeting these dates is just as important to the Post Office as to us, since they are keen to get started on the exploitation opportunities, which Horizon provides. The next major new activity for both parties will be around banking services. Work here will accelerate rapidly through 2000.”
Now, I’m going to skip ahead a little and, if we look over to the second column at the top, it is visible on screen:
“We have recently hosted, here in Feltham, Alan Johnson MP, Minister of State at the DTI, responsible for the Post Office. Like many of his colleagues, he found the session an excellent introduction to the project. We have also been very fortunate to have visits from the Parliamentary IT Committee and the Performance & Innovations Unit from HM Treasury during November. Those attending were particularly excited by the impact that this project can have on the way that government services are delivered in the future, exploiting the natural strengths of the Post Office network.”
It goes on:
“2000 will be a challenging and exciting year for us all and I thank you all in advance for all your efforts and wish you and your family a Happy Christmas and New Year.”
You see it is signed off there at the bottom by you; is that correct?
Now, POCL and ICL, and the government, were particularly excited by the future commercial exploitation of Horizon, weren’t they?
John Bennett: I’m sorry, I didn’t – I have seen this. Could you just repeat the question?
Ms Patrick: So we have seen what you said at the end of December 1999 to your staff. POCL, ICL and the government were particularly excited by the future commercial exploitation of Horizon, weren’t they?
John Bennett: I believe so, yes.
Ms Patrick: Now, looking at that, we have seen the meetings that were going on with ministers and Parliamentarians to explain the system. Did those meetings include an update on just how many receipts and payments imbalances had occurred in 1999?
John Bennett: Are you quoting from a document or is that –
Ms Patrick: No, I’m just asking you a question.
John Bennett: I see, yes.
Ms Patrick: You were involved in those meetings, you knew they had happened. In those meetings with ministers and with Parliamentarians to explain the system, did those meetings include an update on how many receipts and payments imbalances had occurred in 1999.
John Bennett: I’m sorry, maybe my hearing is bad but I don’t quite – could you just.
Ms Patrick: When the MPs – sorry, it has been a long day, Mr Bennett. I will go really slowly.
When you had those meetings –
John Bennett: Yes.
Ms Patrick: – with MPs –
John Bennett: Yes.
Ms Patrick: – and with ministers to explain the system –
John Bennett: Yes.
Ms Patrick: – did they include an update for them on how many receipts and payment imbalances had occurred in 1999?
John Bennett: I – I do recall that element, no. I don’t – I doubt whether that was discussed. I mean I think the main purpose was to show them an example of how the system worked and raise their sight as to how it could be utilised in the future. I don’t think we discussed any particular issues or programme activities which were of the subject you have just raised, so I doubt whether we did discuss that.
Ms Patrick: Thank you, Mr Bennett.
Our last point: did the meetings involve an explanation of the continuing recommendation from some within ICL that the EPOSS required a redesign or a rewrite?
John Bennett: It wouldn’t have been discussed in those meetings, no.
Ms Patrick: Thank you, Mr Bennett. That’s all the questions we have.
Ms Kennedy: Chair, I –
Sir Wyn Williams: Mr Bennett – Ms Kennedy, there’s one aspect of Mr Bennett’s evidence that I think may require a little further clarification and that relates to the questions you asked him about the potential for remote access – I use that phrase as a very shorthand phrase – and what’s concerning me is that I haven’t got before me the transcript of Mr Oppenheim’s evidence yesterday, which was similar to Mr Bennett’s evidence in the sense that he didn’t think that remote access in the strict sense could be achieved, but he did give quite a detailed account of how use of the central servers might have an effect on branch accounts, which ought, if the system was operating properly, to have been flagged up in the data produced.
Now, I’m loath to ask Mr Bennett questions about that without having precisely what Mr Oppenheim said before me so that I can quote him accurately to see whether the two of them agree or disagree about this because, as you will know, in the civil litigation there appeared to be an acceptance that remote access – and I use that again somewhat loosely – was not just a possibility, it occurred.
So, as it seems to me, there is this area of evidence which may need to be clarified and I’m saying all this publicly because I’m contemplating asking Mr Bennett to make a short supplementary statement, once we have a transcript of Mr Oppenheim’s evidence, so that he can say whether or not he agrees with it.
That’s a very long-winded statement by me, but I wanted to make it public to everyone because I don’t want this aspect of the case to be left up in the air, so to speak, with different nuances and different accounts from different witnesses, unless ultimately that is the state of the evidence, so to speak.
There we are. It’s not a question to you, Mr Bennett, but it is, now that I have said what I have said, raising the possibility that at some stage the Inquiry might write you a letter with an extract from Mr Oppenheim’s evidence and ask you to comment on it. You understand that?
John Bennett: Yes.
Sir Wyn Williams: Yes, thank you. So that’s it for this afternoon, Mr Bennett, and I would like to thank you for making your written statement and coming into the Inquiry to give oral evidence.
John Bennett: Thank you.
Sir Wyn Williams: So one witness tomorrow, Ms Kennedy?
Ms Kennedy: Yes, Mr Miller.
Sir Wyn Williams: Can we use that well-known legal phrase “not before 10 o’clock”, just in case my train is late tomorrow?
Ms Kennedy: Yes, thank you.
Sir Wyn Williams: All right, fine.
(4.27 pm)
(The Inquiry adjourned until 10.00 am on Friday, 28 October 2022)