11 January 2023 – Steve Bansal
Hide video Show video
(11.30 am)
Mr Stevens: Sir, can you see and hear me?
Sir Wyn Williams: Yes, I can.
Mr Stevens: Than you, sir. If I may call Mr Bansal.
Sir Wyn Williams: Certainly.
Steve Bansal
STEVE BANSAL (affirmed).
Questions by Mr Stevens
Mr Stevens: Good morning, Mr Bansal. As you know, my name is Sam Stevens and I ask questions on behalf of the Inquiry. Please could I ask you to state your full name?
Steve Bansal: Steven Bansal.
Mr Stevens: Thank you for giving evidence today to the Inquiry, both in the written form which we’re about to turn to and orally today as well. In front of you I see you have a bundle of documents, at the front of which should be you’ve witness statement.
Steve Bansal: It is.
Mr Stevens: That is dated 9 August 2022 and runs to seven pages; is that right?
Steve Bansal: That is correct.
Mr Stevens: Have you had a chance to read that statement recently?
Steve Bansal: I have.
Mr Stevens: Could I ask you please to turn to page 7 of that statement. Is that your signature?
Steve Bansal: It is.
Mr Stevens: Are the contents of that statement true to the best of your knowledge and belief?
Steve Bansal: They are.
Mr Stevens: Thank you. That statement now stands as evidence in the Inquiry. I will now turn to ask you some further questions on it.
Let’s start with when you joined Peritas Limited. That was in October ‘97 as a training instructor; is that right?
Steve Bansal: That’s correct.
Mr Stevens: Now, just for background, Peritas Limited was a company subcontracted by ICL Pathway to deliver training to end users of the Horizon System; is that right?
Steve Bansal: I believe so, yes, yes.
Mr Stevens: You say in your statement that you weren’t solely limited to the Horizon project but delivered training to a number of different projects; is that right?
Steve Bansal: That’s correct.
Mr Stevens: And, because of the passage of time, your recollection has faded and you cannot necessarily say which of your recollections refer to the Horizon project itself and which refer to others.
Steve Bansal: That is correct.
Mr Stevens: I understand that you delivered on either basis an agreed training plan to end users but you weren’t involved in designing the training programme itself; is that right?
Steve Bansal: Not technically true. I did put together some of the training that trained the trainers in preparation for some of the Pathway –
Mr Stevens: I see.
Steve Bansal: – training.
Mr Stevens: So the people who would eventually go out to train the end users, you helped put together documentation for training those trainers?
Steve Bansal: Correct – at the time.
Mr Stevens: At the time. So that’s ‘97?
Steve Bansal: ‘97.
Mr Stevens: You say that in the delays to the rollout of the Horizon IT System, because of that, you transferred to ICL Pathway to work as a trainee tester; is that correct?
Steve Bansal: That is correct.
Mr Stevens: So when the further offices started rolling out in ‘99, with the national rollout in 2000, did you return as a trainer to train people on rollout or did you remain in testing?
Steve Bansal: No, I remained in testing.
Mr Stevens: Did you have any knowledge of the training then after you left Peritas Limited?
Steve Bansal: None at all.
Mr Stevens: I’d like to refer to your witness statement, please. The reference is WITN04770100. Please could we turn to page 6, paragraph 19. Thank you.
In the second sentence it says that you received:
“… feedback reviews from my Peritas manager at the time, which collated comments from subpostmasters in respect of training. I also read the feedback forms and requested feedback directly back from the attendees, as it was important to me that the training had been received and understood.”
Just to clarify, the feedback you’re referring to there, is that personally how you delivered the training or on the course as it was as a whole?
Steve Bansal: A combination of the two. So, if I recall – and it is vague memory – there were effectively two forms for the attendees to complete. One was on the training itself, the content, duration, you know, was it technically sufficient, and then the second was on the trainer, how they delivered, what their technique was like, were you, as an individual, comfortable with the information that had been passed to you.
Mr Stevens: But the forms you read they were the ones completed in relation to training you delivered, rather than – you didn’t look at other trainers’ feedback forms?
Steve Bansal: No, it was purely a case of collecting the data attend then perusing it before returning it to the office and, indeed, at the time talking to the attendees.
Mr Stevens: Please could we go to page 3 of the same statement and paragraph 12. This describes the cash account or you have put subheading “Cash Account”. Then over the page, the final sentence says that:
“… I do not recall having any experience of working with the “Cash Account” software.”
Does this mean that you didn’t train end users on how to use the EPOSS application or how to balance?
Steve Bansal: I don’t believe so. I think at the time – it’s part of I don’t have an awful lot of recollection at all of what the actual specific training was. I don’t believe it would have covered cash account at that time but I can’t say categorically no.
Mr Stevens: I want to move on now then to testing. Your evidence is that you transferred from Peritas to ICL Pathway, as we say, as this trainee tester. Could I ask, at the time, what qualifications in IT did you have?
Steve Bansal: At the time I did not have specific IT qualifications. I think the position was that the rollout or the training of the trainers was paused because the project itself was at a pause. At the time, I was informed that we were unsure whether that would be a three-month pause, a six-month pause and, because of the information and the training that I’d gathered, Pathway/Peritas made the decision it would be useful if I were to support the testing community because of some of the knowledge I’d picked up. So, initially, I was there purely to support and give a different perspective to the testing.
Mr Stevens: Just to clarify, had you worked in IT as a tester prior to that point?
Steve Bansal: No.
Mr Stevens: Did you receive training from Pathway on your role as a training tester?
Steve Bansal: I received on-the-job training. As I say, initially I was there to support but then I ended up shadowing the testers and gradually built my level of experience and knowledge.
Mr Stevens: I’d like to turn to a document. The reference is FUJ00058375. This document is titled “Direct Interface Testing Specification Pathway to HAPS”. We will come to the acronyms in a moment.
If we could just move down slightly on the screen, please – thank you – at the bottom you’ll see you are the author. Do you recall writing this document first?
Steve Bansal: I vaguely recall writing it, yes. It was quite some time ago but yes.
Mr Stevens: On that “quite some time ago”, apologies, if I could now ask us to go a bit further up the document to the top, we’ll see the date is 3 February 1998. Now, in your statement you say that you joined as a trainee tester in April 1998 so you must have presumably joined the testing team before then.
Steve Bansal: Formally, I think I joined – effectively my contract with Peritas ended. My new contract with Pathway effectively started in April. Prior to that, I was effectively on loan to the testing community. So I’d been there for some time.
Mr Stevens: Can you give any indication, just to place how long you’d been in the testing team at this point. At this point, roughly how long had you been working on testing?
Steve Bansal: I’m afraid I couldn’t say.
Mr Stevens: Please could we turn to page 5 of this document. The introduction says that:
“This document details the direct interface test specification between Pathway AP system …”
Stopping there, that’s the Pathway Automated Payment System, isn’t it?
Steve Bansal: That’s correct.
Mr Stevens: It goes on:
“… and POCL HAPS System.”
That being Post Office Counters Limited Host Automated Payment System?
Steve Bansal: Correct.
Mr Stevens: When we are talking about the interface here, in simple terms, are we saying what you’re testing is how data is transmitted from the Pathway Automated Payment System to POCL’s back end system?
Steve Bansal: From APS to HAPS.
Mr Stevens: The document goes on to say that:
“It identifies the requirements that will be used to accomplish direct interface testing between POCL and Pathway, as such this document must be owned and approved by POCL, Pathway and the PDA.”
Indeed, if we can turn to page 2 of the document, please, and go down to “Approval Authorities”, you see there that there are three approvals, Simon Palladino, Pathway; John Robson, POCL; and John Bruce, PDA. Could I ask what the role of the approval authorities was in relation to this document?
Steve Bansal: To review and approve the document.
Mr Stevens: Did they have any input into its content from your recollection?
Steve Bansal: Not from my recollection.
Mr Stevens: Would it have been possible to conduct this testing, the direct interface testing, without input from Post Office Counters Limited?
Steve Bansal: I don’t think so.
Mr Stevens: Please can we turn to page 10 of the same document and go down to heading 4:
“Each party will use its all fault reporting system. Pathway will log any incidents using the fault reporting system PinICL the incident number will be passed back for future progression and clearance.”
So, in essence, is that any problem that arose during testing will be logged on PinICL on Pathway’s side?
Steve Bansal: Yes.
Mr Stevens: If we could go back to your witness statement, please – that’s WITN04770100, page 5, paragraph 16 – you say:
“In my role as trainee tester, I was given scripts to run in order to test the equipment and/or counter. I would then record the result of the test and feed the results back to the Fujitsu test manager. It is my understanding that the Fujitsu test manager would communicate the results of the tests with the relevant Post Office test manager.”
So just to take it in stages, were you involved in passing on any information about testing to the Post Office itself?
Steve Bansal: I suspect I was, yes, at some stage.
Mr Stevens: In what forum would that be? How would you pass on the information?
Steve Bansal: Potentially there may have been triparty calls, there would have been emails and potentially through reporting of the testing that was carried out.
Mr Stevens: Do you recall the type of information that you would have provided to Post Office Counters?
Steve Bansal: At the time, and I can’t say this because I don’t actually recall it, but my assumption is that I would have been passing on details of the PinICL reference number and the faults that were found.
Mr Stevens: Could you just give an overview of the types of areas that you were – we see here the interface. What else did you test in your role as trainee tester?
Steve Bansal: I don’t have a good recollection of that at all, I’m afraid.
Mr Stevens: In respect of where you say your understanding was, that the Fujitsu test manager would communicate the results of the tests with the relevant Post Office test manager, what is the basis of that understanding?
Steve Bansal: Again, from my recollection when I did the witness statement back in August, is that I wasn’t leading any of the discussions. There was always a senior either tester or manager in the meetings initially with myself and any triparty meetings.
Mr Stevens: Are you aware of any formal procedures or protocols that were in place regarding the communication of test results?
Steve Bansal: I can’t say that I am. I think that it generally was agreed – again, my recollection is vague – but I think the principle was that, if there was a meeting, then they were documented as part of that meeting. If it was a PinICL and, as I say, or if the Post Office or PDA had any issues, they would be reported via a mail into us.
Mr Stevens: So, overall, your understanding is that things were passed across at these meetings, possibly emails as well, but is it fair to say your recollection is –
Steve Bansal: It is very vague, I’m afraid.
Mr Stevens: My understanding is that you remained in a testing role until 2002 when you left ICL Pathway; is that right?
Steve Bansal: That is correct.
Mr Stevens: You then returned to, then, Fujitsu in 2007.
Steve Bansal: Correct.
Mr Stevens: At this stage, what’s been known as Legacy Horizon was still in use but it was looking for gearing towards changing to Horizon Online and developing Horizon Online. I understand you were involved in the development of Horizon Online?
Steve Bansal: In, again, the testing of Horizon Online.
Mr Stevens: Now, the Inquiry will be considering the design, development and testing of Horizon Online in greater detail in due course. I want to limit what we discuss to a few small points, starting with testing, if I may.
Please could we bring up POL00029327. So this document, and I’ll ask you for your held with the title, is “HNG-X: ITU V&I Business Continuity High Level Test Plan”. It says you are the author at the bottom. Could you please provide a summary of what this document is describing?
Steve Bansal: It is validation and integration and it is business continuity. So it’s effectively providing assurance around resilience, business continuity, that the infrastructure will cope with a level of impact. So if, let’s say, a server was to go down, that we have sufficient resilience that a single server going down won’t impact service and that the service itself will fail over to another component providing the resilience and potentially also the business continuity. So if we were to fall into a disaster recovery scenario, that potentially we could move from one site, one data centre, effectively, to another data centre and maintain service, albeit there would be a period in which we would have to complete that move.
Mr Stevens: This specific area of testing, was this the sole area you were dealing with or did you deal with others as well?
Steve Bansal: Potentially, I would have dealt with others but I think this was the – one of the main areas at the time.
Mr Stevens: Could I ask just to move down the document to the “Approval Authorities”. Again, here we have three approval authorities. There’s the HNG-X test manager and then Andrew Thompson, Post Office Limited test manager, and Tony Wicks, business continuity manager.
If it’s different to what we went to before, can I just ask you to explain what the role of the approval authority was for this document.
Steve Bansal: Again, to review and sanity check the proposal and to provide their approvals from their respective positions.
Mr Stevens: Do you recall what input Mr Thompson from the Post Office had on this document?
Steve Bansal: I can’t, I’m afraid.
Mr Stevens: Once this document was in its complete form, so approved, would a copy be sent to all the relevant approval authorities as well?
Steve Bansal: That is how the process should work, yes.
Mr Stevens: Can I move to a different topic, please, and if I can bring up document FUJ00084350. Actually, let’s see, we’ll stay there for the moment but we may want to go to the first page, if you need it.
This is a spreadsheet that was provided to the Inquiry by Fujitsu and the file title is 20100526_CS prayers. It appears to be dated 26 May 2010. Please could you clarify what “CS prayers” are?
Steve Bansal: I think it’s customer services prayers, and prayers would be a meeting that’s held in the morning to discuss issues.
Mr Stevens: Did you attend those prayers meetings?
Steve Bansal: I believe I would have attended on occasion, yes.
Mr Stevens: We’re looking here at the Closed tab you see at the bottom it says “Closed” and in row 124, column C refers to a problem, saying:
“More than 2,000 critical events per day.”
In column F there are a series of what I presume to be dates listing various entries and at 9/2 in F it says:
“Steve Bansal running analysis on all events to see what can be done.”
Do you have any recollection of these events or what this means?
Steve Bansal: Bear with me, I’ll just …
Mr Stevens: Of course.
(Pause)
Steve Bansal: No, I can’t say with any certainty.
Mr Stevens: Are you able to help with what a critical event would be generally?
Steve Bansal: A critical event could be a counter going offline, it could be many things.
Mr Stevens: You can’t assist, yes. No, thank you. We can take that document down now, thank you.
Moving on from Horizon Online, your witness statement states that you became a problem manager in around 2010 and that at this point was as a full-time employee?
Steve Bansal: That is correct.
Mr Stevens: Again, the Inquiry will be investigating the identification and rectification of bugs, errors and defects in the Horizon IT System in due course but I’d like to explore some general points on the problem management system with you first.
Please can I bring up the following document FUJ00080043. This is titled the “RMGA Customer Service Problem Management Process” and it’s the second version. Does “RMGA” stand for “Royal Mail Group Account”?
Steve Bansal: It does.
Mr Stevens: It states that this is a process definition to describe and document the customer service problem management process. The document was drafted on 22 April 2008, so before your time as problem manager.
Steve Bansal: Yes.
Mr Stevens: But would it have described the process of problem management when you became a problem manager in 2010?
Steve Bansal: The likelihood is yes.
Mr Stevens: Do you know whether this document – or, to your knowledge, was this document an internal one?
Actually, if we can scroll down slightly, please, before I put this question you see the distribution list. To your knowledge, was this document purely an internal document or would the Post Office have received it?
Steve Bansal: Based on the information on that page, it would appear to be an internal document.
Mr Stevens: Please could we turn to page 6 of the document. So in this introduction, it sets out the process, objective and scope of problem management and a problem is defined as “the unknown underlying root cause of one or more Incidents”.
We see in the documentation a distinction drawn between problems and incidents or major incidents, with different processes. Please could you help us with what the difference between a problem and the problem management process and an incident and a major incident process is?
Steve Bansal: Okay. A problem could be raised off the back of an incident or an issue in a single branch or multiple branches. We would use the problem itself, a problem ticket, to continue the investigation, the analysis, until such time the incident is resolved.
For a major incident, the distinction there is the severity and the priority and potentially the impact to the wider estate. So a major incident would mean that potentially a greater number of branches are down, they’re offline, there is not a service being offered. So the priority there is resolution to get those branches’ services available as soon as possible. We would then subsequently raise a problem ticket for any outstanding issues where we’ve not developed/understood the root cause to continue the investigation.
I think there was an element I haven’t covered.
Mr Stevens: Let’s just break it down with that first, so we can understand the difference.
So, for example, if there was an unexplained discrepancy of a low amount, say, a £5 discrepancy at a single Post Office reported, would that be classed as an incident in itself?
Steve Bansal: That would be classed as an incident, yes.
Mr Stevens: The underlying cause of that discrepancy, that would be the problem?
Steve Bansal: Yes.
Mr Stevens: A major incident would be, say, if there was a complete outage of service for a period of time, which had a very severe effect on the network but, again, the problem is trying to find the underlying cause of that major outage. Is that the distinction?
Steve Bansal: Correct. It’s getting the root cause.
Mr Stevens: So when we talk about problem management here. We’re talking about finding the root causes of bugs, errors and defects, basically, or trying to find whether there is a bug, error or a defect?
Steve Bansal: Correct.
Mr Stevens: It refers to reactive and proactive problem management. We’re going to, I think, look at that in due course as we go through this document here.
Can I start, though, by looking at some of the responsibilities for problem management and, if we turn to page 6 of this document, if we’re on page 6, if we could go to the bottom of it, please. Thank you.
So the first point here is a “Process Owner” and it says:
“The owner of the process this POA Service Delivery Manager responsible for the Service most affected by the Problem. The Process Owner, otherwise known as the Problem Manager, is appointed by the Service Delivery Team Manager.”
So if a problem arose, who would have day-to-day responsibility for the problem management process and seeing that the problem is investigated?
Steve Bansal: So unless there is a defined problem manager, it would fall to the SDM, whose service that problem falls under.
Mr Stevens: So the “SDM” being the service delivery manager?
Steve Bansal: Service delivery manager, correct.
Mr Stevens: Is it the case that a service delivery manager can appoint a problem manager and delegate responsibility for that particular problem?
Steve Bansal: That can happen.
Mr Stevens: In 2010, when you were described as a problem manager –
Steve Bansal: Yes.
Mr Stevens: – were you a person to whom problems would be delegated or were you a service delivery manager?
Steve Bansal: I was a problem to whom – a person where the problems would be appointed to.
Mr Stevens: I understand that you became a service delivery manager later in your career; is that right?
Steve Bansal: That is correct.
Mr Stevens: When did that happen?
Steve Bansal: 2010.
Mr Stevens: Right. Sorry, so you were – you weren’t a problem manager in 2010, you were a service delivery manager in 2010?
Steve Bansal: My apologies. I started out in the service team as a problem manager and then moved into becoming an SDM.
Mr Stevens: In the same year?
Steve Bansal: Later that year, 18 months afterwards.
Mr Stevens: Roughly, yes.
Steve Bansal: But it was a progression.
Mr Stevens: If we turn over the page, there is a role described as a “Problem Resolver”, who’s responsible for finding a resolution to the problem. Would that be, for example, someone in the SSC who’s actually investigating, running diagnostics?
Steve Bansal: Possibly someone in the SSC but it would be someone who has the technical knowledge. So SSC, being the third line support team, would have knowledge, articles and information for them to investigate but it may be that the resolution would come from the fourth line support. So there isn’t a specific problem resolver and it is allocated case by case.
Mr Stevens: So your role as problem manager would be to, what, oversee them and – well –
Steve Bansal: To ensure the process is followed and that we have the correct support, et cetera, and that we’re doing the communication both internally and externally.
Mr Stevens: Looking then at how this process works, could we start with problem identification and turn to page 10 of this document, with the flowchart at section 4.1.1, please.
So we see on the top left there’s two ways into the problem management process: incident management and alerting of a pattern likely to cause a problem, at the far left. Is that what you would describe as proactive problem management where an incident is detected by Fujitsu itself?
Steve Bansal: Yes.
Mr Stevens: Then we also have the major incident management in the second from the left.
Then it says to open a problem record at 1.1.1 in the middle. The third box on the top, hard to see but it says “Incident & Problem Alerting Process”, was there a written procedure for the incident and problem alerting process that you’re aware of?
Steve Bansal: The incident and problem alerting process, to my recollection, would be the daily monitoring that is performed by the SMC. So they would effectively see alerts, because they’re monitoring the system, and they would then the raise an incident. The incident would then be trended and that would be how we would then raise a problem record.
Mr Stevens: So that may be a way through opening a problem record but, looking at this flowchart, if we look at the box 1.1.1, we’re at the stage where a problem record has been opened and then the flowchart goes off to three boxes. Now, the middle one is “Start Total Time Clock” and the second one is “Start [I assume Service Level Agreement] SLA Clock”.
Is that referring to, sort of, deadlines for when a problem should be resolved by?
Steve Bansal: The SLA clock is if there is a Service Level Agreement in place. So, at that point, effectively, we’re starting the clock.
Mr Stevens: Yes. So we’re in the position where we’ve got the problem open?
Steve Bansal: Yes.
Mr Stevens: So it may have come from the SMC or not, but the box we didn’t look at on the left “Incident & Problem Alerting Process”, do you know to what that refers?
Steve Bansal: I don’t, I’m afraid.
Mr Stevens: When a problem record was opened, who would be told of the problem or provided with the problem record?
Steve Bansal: The problem manager would obviously be either made aware or would have raised the ticket themselves. That would then be put onto effectively a spreadsheet, a database, and then that would be informed to the wider account via an update on the actual incident ticket. So the incident ticket would then have a reference back to the problem record. The problem record should then have a reference back to the incident itself.
Mr Stevens: So you said the wider account. That’s the wider group of people within Fujitsu working on this account?
Steve Bansal: Correct.
Mr Stevens: If we follow this flowchart through at the top right we see it says go to “A”, after we’ve taken these various steps. If we could go to page 12, please, of the document – thank you – this section concerns classification and, in paragraph 4.1.2.1, which is just below the flowchart, it asks the problem manager and resolver to capture the sense and respond codes. Could you assist with what those are?
Steve Bansal: I can’t – no. What I would say is that I’m not sure whether the – how long the sense and response codes were actually in play and what I would say is that I think we have a matrix which would give us the priority and severity, which I think is further down in the document.
Mr Stevens: Yes, I want to turn to that now, actually. We see “Priority” is in a different section, so if you follow it across, it’s to 1.2.3. So after the problem’s been classified, a priority’s set and, in that regard, we look at the appendix to this document.
I’d like to look at the final page first, which is page 23, please. This is a table which says “Priority”. Is this the table to which you were referring to get a priority score for the problem?
Steve Bansal: Correct.
Mr Stevens: On the column on the left, there is an impact score or an impact value of 1 to 5 and then the columns on the top, from the second column to the final column, these are urgency scores, again of 1 to 5, which we’ll come to in a moment. But for present purposes, it looks like this ends up with a score – if you combine these two, the impact and urgency to get a priority score of somewhere between 1 and 5?
Steve Bansal: That is correct.
Mr Stevens: Were there any deadlines or – how were the different scores for priority treated? How was a “1” priority different from a “2”?
Steve Bansal: So a 1 priority is the most immediate; so effectively resolve this with the highest priority. A 5 would be the lowest priority.
Mr Stevens: Were there targets or deadlines for a priority 1 and then a priority 2?
Steve Bansal: Relating to –
Mr Stevens: How long they needed to be – within what time they needed to be resolved?
Steve Bansal: Within problem management, I don’t believe that there was.
Mr Stevens: In practice, what effect did the priority level have on the speed to which problems were resolved?
Steve Bansal: If you had a P1 then, effectively, we would trump any other activity that’s going on to be able to call SMEs, the support units to come and prioritise this work to look at the resolution of the incident or the issue and, bearing in mind it was a problem that would already have had a high priority incident allocated to it, that activity would have been ongoing.
So yes, a higher priority would have meant that people would have paid attention and actually appropriately prioritised the activity.
Mr Stevens: Is it possible to say, if you gave something a priority 1, within what period of time you would have expected the problem to be resolved?
Steve Bansal: As I say, with urgency but a problem is different to an incident. An incident does have a four-hour SLA or an eight-hour SLA or a three-day SLA. A problem does not have the same SLAs because those incidents, high priority, are being worked on as part of this problem ticket.
Mr Stevens: If you look at some of the factors that go into giving us the priority, please can we turn to page 21. Thank you. This first refers to, we see in the bottom the impact value. There’s a table there but, starting at the top, the first step is to give it a criticality value, which there are, again, five scores from critical to cosmetic.
This would be assigned by the problem manager; is that right?
Steve Bansal: That is correct. Problem manager and SMEs.
Mr Stevens: Was there any guidance on what would be determined as a critical, high, medium or minor?
Steve Bansal: The critical would be defined as something which has effectively a show stopper on a wider scale. So, again, if we go back to a P1 scenario, almost a disaster, service has stopped. That’s regarded as critical.
And then we go down in severity down to the things which are cosmetic or minor.
Mr Stevens: So when you say the show stopper point there, critical, you suggested that’s something that’s stopping service but also would you take into account how many people were –
Steve Bansal: Absolutely, and I think that’s covered in the impact section below. So if it’s one user or if it’s the entire estate, they will have a different –
Mr Stevens: So that’s taken into account under the impact but the criticality part, is it fair to say it’s a judgement call at there’s no particular written guidance on what is critical and what is medium?
Steve Bansal: So, again, hence why it’s the problem manager and the resolver group looking at this. So it’s a collective view on how critical things are and it’s not one individual’s judgement.
Mr Stevens: Was there ever an incentive to lower the criticality score or to put in a lower score than you otherwise would have thought?
Steve Bansal: No. No, there was never any pressure to do anything like that.
Mr Stevens: When we go down – if we could move down – thank you – to the impact table, the number of users affected, obviously at the top we see it ranges from, on the left, over 70 per cent to, on the right, to a single user and that affects the overall impact score.
Was this – “Number of users affected”, was this the number of users that had been affected or would it be an assessment of how many users may be affected by a problem?
Steve Bansal: I think for a problem we would be – we would take both into account. If the problem was well understood and defined, then potentially you’d be looking at just the affected users because, again, we’d be in a position to understand that.
If the issue/problem was relatively new and that was still being defined and understood, then we would also look at the potential wider impact and take that into account.
Mr Stevens: So from a criticality point of view, if, say, less than 100 – say less than 50 subpostmasters were reporting unexplained discrepancies in their branch accounts, where would that have fallen on the criticality score?
Steve Bansal: To my mind, that would have been a critical.
Mr Stevens: That would have been –
Steve Bansal: That would be a critical. If you’re getting that many postmasters reporting something of that nature, that’s something that needs to be looked at with urgency.
Mr Stevens: So that’s if they were reporting all at once. If it’s just a single discrepancy that’s being reported, how would that change things?
Steve Bansal: That would change things because, until we’ve done some trending along that, we don’t know where those discrepancies are. They could be related, they may not be related; so we would, as part of that problem review, pull together any child incidents to see if they actually are related.
Mr Stevens: Could we turn the page, please, to the urgency score on page 22. Before I ask you about the detail of it, in broad terms can you explain how the impact score differed from the urgency score?
Steve Bansal: Sorry, my mind’s gone blank. Can you repeat your question?
Mr Stevens: Of course. In what way – what considerations or what different considerations would you take into account when arriving at an urgency score, in comparison to the impact score?
Steve Bansal: I guess we would look at what potentially may unfold over the next period. Depending on where the scenario of the issue is, it could be that with the batch processing that happens overnight that may then add to the severity or the impact of the issue, and it could be that during a working day there is the opportunity to support the postmasters, support the post office with a resolution so that would make that resolution within that time span far more urgent than if there was a roll on impact of an overnight batch.
Mr Stevens: Let’s look at what the urgency table says and go through it there. For the first level, which is the most urgent it says it:
“Has a significant adverse impact on the delivery of service to a large number of end users.
“Causes significant financial loss and/or disruption.
“Results in any material loss or corruption of customer data.”
It says:
“For example, incidents with this urgency may affect the COMPANY.”
What company is being referred to there when it says “the company”?
Steve Bansal: I’m afraid I don’t know.
Mr Stevens: Would it be the Post Office as a whole rather than individual subpostmasters?
Steve Bansal: I don’t know, I’m afraid.
Mr Stevens: The urgency value 1, as we say, refers to significant financial loss or disruption. The second score, it says it causes – sorry, urgency score 2 – it says:
“Causes a financial loss and/or disruption to the customer which is more than trivial but less severe than the significant financial loss described in the definition of an Urgency level of 1.”
Are you aware of any guidance on how a problem manager was to distinguish between trivial or significant financial loss or somewhere in between?
Steve Bansal: No specific guidance.
Mr Stevens: At the bottom of urgency score 2, it says:
“For example, incidents with this urgency may affect a VIP SITE.”
Do you know to what that refers?
Steve Bansal: I think, historically, Post Office did have a number of sites that they determined as VIP and – yes, I’ll say no more.
Mr Stevens: Could we look at an actual problem report. It’s POL00029568. We see this is a problem report. It says it affects 14 branches. It was reported by Steve Parker and you’re listed as the problem manager.
Now, this concerns a bug in the system described by Mr Justice Fraser as bug number 3, the suspense account bug and, in essence, what this document shows or suggests is, in some branches, there was data entered into the local suspense account that was relevant to balancing in trading periods 9 and 10 in 2010 and ‘11 and this data in the suspense account was retained in the database. Therefore, when the branches came to balance in the corresponding trading periods 9 and 10 in later years, that 2010 data was reused incorrectly.
Is that a fair summary of the problem?
Steve Bansal: I believe so, yes.
Mr Stevens: Whilst branches had experienced the error in 2012, it was only reported to Fujitsu in 2013; is that right?
Steve Bansal: As I understand it, yes.
Mr Stevens: If you could move down, please, the page, we see at this stage 14 branches are listed as having discrepancies. Some of them are small amounts. For example, the third one down is 1 penny but, as you see the fourth one down is £9,799.88. Can we go to the top of the table, please, again. Thank you.
Now, this was given an urgency score by you of 2. Could you explain why this had an urgency score of 2?
Steve Bansal: I think at the time because there were 14 branches and because at the time we were looking to get the investigation underway. So I think, if memory serves, this had come through to us from Post Office. So we raised an immediate problem record to do effectively a historical investigation into those 14 branches. That’s why I think it was a 2 rather than a 1.
Mr Stevens: When you were – in a case like this when you’re given an urgency score, would you consult the appendix to which we just referred or was it more of a sense of experience and feel to what score would you ascribe an urgency score?
Steve Bansal: So I think I can’t hand on heart say that I looked that appendix for this one. I think I may have done; I may not have done. So I can’t comment. But, normally, I think the advice to the problem management team is to look at the appendix.
Mr Stevens: Please could we go back to the appendix – it’s FUJ00080043 – and turn to page 23. On what you just said, the paragraph below the table does say:
“For example, if the agent decides that the Urgency score is 3, and the Impact has been calculated as 2, then from the Priority table, the final Priority will be automatically generated as 2. The assigned priority can be overridden if the problem is serious and discussed with the Service Delivery Team Leader, but the Problem Management process must be followed.”
Now, in the problem record there that we just looked at, the priority score given was 4. If we look on the urgency score for an urgency score of 2, the only priority scores you can give are 1, 2, 3, 3 and 5. Could you assist with why you considered that or gave the priority score of 4 for that problem?
Steve Bansal: I’m afraid, I can’t.
Mr Stevens: In practice, giving it a score of 4 rather than, say, 3, what difference do you think that would have made in practice to how the problem was resolved?
Steve Bansal: On this occasion, I don’t think an awful lot. Having read through the rest of the pack, I know that that particular issue was dealt with by a number of people and I think there were a number of high priority PEAKs that were raised and the investigation was quite intensive.
Mr Stevens: You have raised it. Let’s look at that. It’s POL00029671. Can we turn to page 6, please.
There’s an entry, 6 March 2013. I should say, for the record, that this PEAK is the PEAK referred to in the problem report we’ve just seen but the entry on 6 March 2013 at 4.05 says:
“There was a conference call with POL (Laura Darby, Mark Wardle and others) on 28th Feb about this call, and the spreadsheet showing the impact of the problem on the 14 branches was sent to them by Steve Bansal. We are waiting to hear from Mark whether this is sufficient information for them to resolve the consequences on the branches and POLSAP.”
So do you recall how this problem was resolved thereafter following this call?
Steve Bansal: I don’t.
Mr Stevens: You, mentioned that you remember this in particular at there were several people on it. Was this problem given more resources than, say, another priority 4 problem would be given?
Steve Bansal: I think that, in this particular scenario, I think Anne Chambers, it was her priority. She effectively dropped all other work, to my approximate knowledge, as it were, and this was her main focus. I believe there was another PEAK open and I think that in the background other teams were also looking at different aspects in support of this. So Anne wasn’t looking at this on her own; there were wider teams looking at the scenario and the issues.
Mr Stevens: Sir, I don’t know if you want to have a break this morning but this would be a good point to break for the hour mark?
Sir Wyn Williams: Yes. Well, certainly that’s okay. All I don’t want to do is to have a break and then have another long break if you see what I mean. How are we going with the witness, generally?
Mr Stevens: Quicker than – yes, there’s probably about the same again, maybe less.
Sir Wyn Williams: Okay. So should we – let’s ask Mr Bansal. If we have, say, a ten-minute break now, should we then complete his evidence without having a formal lunch break, so that that would take us to maybe 1.30 or would he prefer to have a formal lunch break at 1.00?
Steve Bansal: I’m easy to go through.
Sir Wyn Williams: You would prefer to go through?
Steve Bansal: I would prefer to go through rather than stop for lunch.
Sir Wyn Williams: Is that all right with you, Mr Stevens?
Mr Stevens: It is, sir.
Sir Wyn Williams: So we will have a ten-minute break now and complete Mr Bansal’s evidence and that will be it for the day.
Mr Stevens: Thank you, sir, fine.
(12.26 pm)
(A short break)
(12.38 pm)
Mr Stevens: Sir, can you see and hear me?
Sir Wyn Williams: Yes, I can. Thank you.
Mr Stevens: Thank you. Mr Bansal, we will continue. Can you please bring up on the screen POL00029671.
That’s my error in the reference. It’s FUJ00080043.
Thank you. If you could turn to page 13. Sorry, page 14. Thank you.
So once we’ve got the priority, it goes into this flowchart of managing root cause process and establishing corrective action and it’s, at this point, I assume, where the problem resolver takes over the mainstay of the technical work?
Steve Bansal: Yes.
Mr Stevens: Now, as a problem manager at this stage, how do you review or, in 2010, how would you review or keep track of how problems were being resolved or diagnosed?
Steve Bansal: So we would have regular meetings with the resolver and possibly the support teams to understand exactly where we are with getting to resolution.
Mr Stevens: Would the regularity of those meetings be connected to the priority of the problem or …
Steve Bansal: Yes. If it was a high priority incident, then we would be having almost daily conversations to track progress but, again, we would also be reliant on the SME, the support teams, providing sufficient feedback to determine the regularity of those conversations. Again – yes.
Mr Stevens: Could we turn to page 16, please. Now, this is, again, part of this error control process and the step in the flowchart here at 2.3.1 says “Assess if permanent solution is required”, and it gives eight options for this assessment, ranging from “Impact minimal: not cost-justifiable” with other ones requiring – it says “Resolution requires POL funding” or “Resolution requires action by POL”.
I want to look at the first two. Would anyone from the Post Office be involved in this assessment of whether a permanent solution was required?
Steve Bansal: Yes, they should be. So we would hold a regular review of problem records with the Post Office and we would take to them our findings and, if we were in a scenario where we had to look at the justification in this manner, if it wasn’t apparent, ie that we had to fix it, then we would have a conversation with Post Office.
Mr Stevens: These meetings in 2010 that started around that point, how often would you have those meetings with Post Office?
Steve Bansal: I can’t say with absolute certainty. I would suggest minimally at a month but I can’t say with any greater recall.
Mr Stevens: At these meetings, would you discuss all active problems or a certain priority of problems?
Steve Bansal: I think the approach would be that we would discuss all active problems but with priority given to those that are of the highest urgency priority, hot topics, et cetera, and then you would work your way down the list.
Mr Stevens: So where it says in this chart “2.3.2 Impact minimal: not cost-justifiable”, if the problem resolver had found a bug in the Horizon System that Fujitsu had provided to the Post Office, to whom was the cost not justifiable to enter a permanent solution: Fujitsu or the Post Office?
Steve Bansal: That would be determined by what the root cause of the problem was.
Mr Stevens: You’ve identified the root cause of the problem and now the question is what action to take with it and one of the options is not to do anything or not to implement a permanent fix because it’s not cost justifiable.
Steve Bansal: Yes.
Mr Stevens: Whose costs are we looking at here?
Steve Bansal: Again, that is dependent on the resolution. If what is found to be which case is that it’s missing requirements or incorrectly stated requirements originally, then that may be something that we would look to Post Office. Because it’s a change of requirements, they would need to confirm that what they would like is that issue addressed with a new set of requirements.
Mr Stevens: So that would be covered, would it, by, if we look in this diagram, “2.3.8 Resolution requires POL funding” or “2.3.9 Resolution requires action by POL”?
Steve Bansal: Correct.
Mr Stevens: So in 2.3.2, “not cost-justifiable”, does that refer to cost to Fujitsu?
Steve Bansal: No, that would also refer to cost to Post Office. So I see what you’re saying but it falls under that category as well. So, yes, there may be an occasion where Fujitsu, depending on what the impact is, may say it’s not justified, as Post Office might have done historically as well.
Mr Stevens: So in what circumstances would Fujitsu say the cost to them meant it was unjustifiable to implement a permanent fix?
Steve Bansal: So it could be that the impact is only to our support teams. So if it means that we see something within our monitoring, let’s say, our error handling, and it – effectively we could then potentially ignore that particular scenario. So what we then do is write a knowledge base article to that effect so we don’t then have to put in a software or hardware update to achieve that. So it’s cheaper, therefore, to put together the knowledge article in that scenario, where we see that again we know that, under those circumstances, we can ignore that event.
Mr Stevens: You said that the Post Office were involved in this assessment. What happened if there was a divergence of views on whether or not to implement a fix?
Steve Bansal: Then we would follow the customer’s recommendation.
Mr Stevens: Please can we bring up another document. It’s FUJ00085191. This is another spread sheet. We’re on the first page there. It was provided to the Inquiry by Fujitsu, the title was “POLS [so POL’s] Weekly Problem Review 241013”.
Do you recognise this type of document?
Steve Bansal: I do recognise this type of document.
Mr Stevens: Who created this or – not specifically which person, but which corporate entity would create this document?
Steve Bansal: I’m going to say I’m little bit hazy whether it would have been something that Fujitsu produced or whether it’s something Post Office produced but it was something that we reviewed collectively and updated collectively.
Mr Stevens: Can you recall when spreadsheets like this were used for collective discussions first?
Steve Bansal: I can’t say that I can recall when it started or whether it was practised when I joined.
Mr Stevens: In terms of the meetings you discussed earlier about going through various problems that you had, you said at the least regular interval’s monthly but you couldn’t remember how often precisely –
Steve Bansal: Yes.
Mr Stevens: – would this be the document that was used –
Steve Bansal: This would be the type of thing, yes.
Mr Stevens: The type of thing?
Steve Bansal: The type of thing. So, again, just to your point, I think when I initially started as a problem manager it was monthly but, to my recollection at that time, I found that to be insufficient, so I brought that forward to fortnightly and then that also was quite slow, so we went to a weekly meeting.
Mr Stevens: At these meetings, who from POL – or at least who in terms of what job roles from POL – would attend? I should say Post Office. Which job roles from Post Office would attend?
Steve Bansal: So I think we would have some representation from Post Office from a service perspective. We would have I’m going to suggest some SDMs and senior service person. From memory, I’m not going to say names because I can’t remember all of them but, certainly, there was at least, you know, two to three people at all of these meetings early on.
Mr Stevens: Could we now just turn to the “Closed” tab, please, on the spreadsheet and if we could go to row 20. Thank you.
I think what we’ll need to do, if we could drag the row 20 down so that it’s – I think if you go to the left there and – yes, thank you – drag it down we’ll get that detail in. Thank you very much.
So this we see from column D refers to the 14 branches and the local suspense account issue and we have in column F, which is titled “Supplier Updates” a series of entries with dates. If we could go across to column G which is titled “POL Updates “there are also entries on dates as well, not necessarily the same.
How were these columns updated; can you recall?
Steve Bansal: Yes. They were potentially drawing the meetings. As we mentioned earlier, we would go down the sort of priority list and we would look for updates from either side on the particular issues.
Mr Stevens: Who maintained – because if this is an updating document that was used for meetings, was there a master copy or was someone responsible for maintaining a master copy?
Steve Bansal: I’m going to say that I think the master copy was held with Fujitsu and was shared post every meeting with the Post Office representatives.
Mr Stevens: Thank you. We can take that document down now.
Could we please bring up FUJ00085175. We were previously looking at version 2 of the “Customer Service Problem Management Procedure” before the break. This is, if we go to the bottom, version 2.3, which I understand means it’s in draft form; is that right? It’s a draft, not approved version?
Steve Bansal: I can’t see approved on here.
Mr Stevens: If we go up, sorry, slightly –
Steve Bansal: Ah, yes.
Mr Stevens: Draft version.
Steve Bansal: Yes.
Mr Stevens: At page 4 – go to the bottom, please – you’re listed as a mandatory reviewer. So presumably you would have seen this document at the time.
Steve Bansal: I would have done.
Mr Stevens: Please turn to page 9 of the same document. Under heading – can we go to heading 1.5.1. This says:
“The Problem Records for [Post Office Account] is held on the …”
Is it TRIOLE?
Steve Bansal: TRIOLE.
Mr Stevens: Thank you.
“… Service Desk [system].”
Who would have access to the TRIOLE service desk system?
Steve Bansal: Fujitsu staff.
Mr Stevens: Post Office didn’t have access to that?
Steve Bansal: Correct – I don’t believe so, no.
Mr Stevens: Over the page, if we may, it refers to, at the top:
“Problem Managers can access the Problem Action Plans by …”
Then it gives a reason – sorry, the way to do it, and it says:
“These reports are held within a spreadsheet which contains three tabs: Horizon, POLSAP and Closed.”
Is that referring to the spreadsheet or the types of spreadsheet we were seeing that we just took you to?
Steve Bansal: I believe so.
Mr Stevens: Please could we move to a different document. It’s FUJ00085985. We see from it there’s a note on the second paragraph of the substance:
“Note Jan 2018: Document updated to reflect the changes on the POA Account.”
So we’ve jumped forward quite a bit.
Have you seen this document before?
Steve Bansal: I think I have seen this document before, yes.
Mr Stevens: Do you know – it says “IP Handover”. Do you know what it was drawn up for?
Steve Bansal: Sorry, could you?
Mr Stevens: Sorry, do you know for what purpose this document was drawn?
Steve Bansal: Yes, it was effectively a task list for IPs.
Mr Stevens: “IPs” being?
Steve Bansal: Industrial placement.
Mr Stevens: These people would help with the problem management and incident management processes?
Steve Bansal: They would help with various tasks across the service team to give them some scope and bandwidth of some training and some understanding of how business works.
Mr Stevens: Could you turn to page 4, please. This refers to the “ATOS Problem Spreadsheet”. I think at this stage it would be helpful to introduce ATOS. Could you state how ATOS fit into the problem management process?
Steve Bansal: So I think at the time Post Office effectively brought in a managing agent to work on their behalf and, as part of that, they procured a problem management service through ATOS.
Mr Stevens: So ATOS were when it says “ATOS Problem Spreadsheet” and we talk about ATOS, that is subcontract – or people contracted by the Post Office?
Steve Bansal: Yes.
Mr Stevens: It says that:
“… the Problem Spreadsheet to ATOS Problem Management … with Fujitsu updates which are discussed on the weekly Problem Management call every Friday.”
I think earlier in your evidence you referred to these calls going from a monthly to fortnightly and then an even shorter period of time.
Do you have any recollection as to when they went to weekly calls?
Steve Bansal: I don’t, I’m afraid.
Mr Stevens: The spreadsheet that’s referred to, is it basically – was it in a similar form to the spreadsheet we looked at earlier?
Steve Bansal: I believe so.
Mr Stevens: So, fundamentally, the process you’re describing hadn’t changed, just the frequency of the –
Steve Bansal: The – yes.
Mr Stevens: – meetings?
Steve Bansal: Actually, if you – I think if you go back to the other spreadsheet that might give an indication of the regularity of that particular spreadsheet, whether that was weekly.
Mr Stevens: In due course, the Inquiry can look at the documents to see that but thank you.
Can we please move to page 12 of this document. Now this talks about PEAK reporting. The Inquiry’s heard a lot about PinICLs because of the time-frame but PEAKs were effectively the same as PinICLs in order that they – well, the PEAK system was a system in which problems were recorded and it was a flow of the information done to rectify those problems. Is that fair? It was a log, basically, of actions taken.
Steve Bansal: It was or it could be used in that form, yes.
Mr Stevens: Was there any material difference between the PEAK and the PinICL systems?
Steve Bansal: At a high level, I’m going to say I don’t believe so.
Mr Stevens: Page 12 says that these instructions are:
“… to generate a PEAK Report for Steve Bansal in preparation for the Leadership Team Meeting on Friday.”
Who attended the leadership team meeting?
Steve Bansal: That would be an internal Fujitsu meeting, from recollection.
Mr Stevens: What was its purpose?
Steve Bansal: To provide an update to the leadership team on the status of service.
Mr Stevens: With the reporting of PEAKs, the second paragraph says”, As PEAK Reporting is used to keep track of the trend of PEAKs”, and goes on to say “when there is a sudden increase or decrease”, can you explain what Fujitsu did in respect of trend analysis. How did it analyse trends in PEAKs?
Steve Bansal: We would have members of the service team and the MAC team looking at trends, effectively, if we were seeing an increase in them and, if we were seeing an increase or a decrease, in which areas, and was that associated to any new releases, was that associated to any updates that had gone out, positive or negative we needed to understand what was going on and then potentially, proactively be able to get ahead of any issues as well.
Mr Stevens: So who within Fujitsu was responsible for that trend analysis?
Steve Bansal: So responsibility for it would ultimately come to myself in that particular phase, but it was a number of teams that were producing that activity.
Mr Stevens: Which teams would they be?
Steve Bansal: So I think at the time they were the – I think they are currently called the MAC team and I can’t for the life of me remember what they were called then.
Mr Stevens: At the start of your evidence, or near the start, we discussed proactive problem management. Presumably this is an example of proactive problem management analysing the trends of PEAKs?
Steve Bansal: Yes. So the PEAKs will be done via that team – apologies to talk across you – and the problem manager would be doing the problem effectively trending. But the two should meet.
Mr Stevens: Was there anything else other than this PEAK – those two points you said, that Fujitsu did in respect of proactive problem management?
Steve Bansal: I could say probably, yes, but nothing is coming to mind. Apologies.
Mr Stevens: Before moving on, can we please move to page 16. This refers to major incident reports and when we discussed this earlier you referred to a major incident being a particular incident that had a significant effect on the network or it was particularly severe.
Steve Bansal: Yes.
Mr Stevens: In this, it says, starting with the second line:
“In the event of a Major Incident, you alongside the rest of the team will be expected to drop whatever you are doing to manage the issue in the most effective way.”
I don’t need to read the second paragraph. The next one is:
“When producing the Major Incident Report, you will be assisted by the Duty Manager who was running … the incident, who will provide you with a detailed timeline of events, including calls that were made and resolution steps taken by the individual teams. With this information, you will do the typing of the first draft using the account template …
“Once you have completed the report, you will review with the relevant parties, eg Duty Manager involved and Steve Bansal, before sending the report to Steve Bansal. From this point Steve will make the final edits and send to the customer. Your main job is to type up the report and make sure all detail is recorded, Steve will make the decision to remove any unnecessary detail.”
So in respect of major incidents, you were the sort of final point of call or the final interface of information between Fujitsu and the Post Office?
Steve Bansal: Correct.
Mr Stevens: What type – when it says you would make the decision to remove any unnecessary detail, what types of thing would you remove? Would they be substantive or –
Steve Bansal: They would be what I call the “he said/she said”. So effectively some of the chit-chat. So, again, the purpose of having an IP recording what was going on, effectively as a transcript almost, they would document everything that was kind of said and when that then came to me to review, I would remove some of that because it wouldn’t be pertinent to the actual final report.
Mr Stevens: Were you ever under any pressure to downplay an incident?
Steve Bansal: No, no.
Mr Stevens: Please –
Steve Bansal: Apologies. I was going to say that, while the report is being produced and while the major incident is ongoing, I would have open dialogue with my Post Office counterpart and I would be providing them with updates. That’s before and after a major incident. So the technical written would support everything I’d been saying to him.
Mr Stevens: Can we please go back to FUJ00085175 and can we please turn to page 9. This was a document we were looking at a moment ago, version 2.3 of the problem management process. 1.4 refers to metrics to be reported monthly, which will be used to measure effectiveness of the process and drive performance of the process and overall service in general. That included things such as number and end impact of incidents occurring before root problem is identified and resolved.
Do you know who was responsible for including this in this document?
Steve Bansal: I think, at the time, it was my predecessor or my manager at the time.
Mr Stevens: Please can we now turn, on this issue, to the Horizon Issues judgment, which can be found at POL00022840 and page 97. In this section, Mr Justice Fraser is making findings on Mr Godeseth’s evidence. Presumably you know Mr Godeseth as a member of Fujitsu as well?
Steve Bansal: Correct.
Mr Stevens: At paragraph 322, Mr Justice Fraser refers to a later version of the problem management document we’ve been discussing. So as you will see in the second line, it refers to being copyrighted in 2017.
At paragraph 324, he refers to paragraph 1.4 of that document. He says:
“The following metrics, to be reported monthly, will be used to measure effectiveness of the process and drive performance of the process and overall service in general …”
Over the page, we see the list which we saw in the document previously.
If we could go down please to 325 – thank you – it says that:
“… the Claimants … sought to obtain reports that would [have been] expected to exist [as a result of this policy].”
It says that:
“… Fujitsu stated (through the Post Office’s solicitors) that ‘Fujitsu believes that it does not record problems in such a way that would allow this to be determined without retrospectively carrying out detailed analyses’ and that it would require ‘a disproportionate effort and cost’ to provide these.”
Mr Justice Fraser then quotes from Mr Godeseth’s evidence and he says:
“I have spoken to my colleague Steve Bansal, Fujitsu’s senior service delivery manager, who has informed me that the Post Office account customer service problem management procedure document was introduced by Saheed Salawu, Fujitsu’s former Horizon lead service delivery manager and that Saheed Salawu left the Fujitsu Post Office account in around February 2013, before the new procedure had been implemented. I understand from Steve that Saheed Salawu’s replacement did not wish to implement the changes and therefore the records referred to by Mr Coyne in paragraphs 5.157 to 5.159 of his report do not exist, as we continued to follow the previous existing reporting methodology.”
Do you recall having a conversation like with Mr Godeseth?
Steve Bansal: I do.
Mr Stevens: Is Mr Godeseth’s evidence correct in that regard?
Steve Bansal: It is.
Mr Stevens: So the 1.4 documentation and procedures were never implemented?
Steve Bansal: They were not implemented.
Mr Stevens: Why was that?
Steve Bansal: I think when I then subsequently took over, in my view most of the data was being captured in alternate locations, not necessarily as a specific problem KPI dashboard, shall we say, and the majority of that information was being discussed with Post Office. So if I took those points and reviewed them in the context of that meeting that we were having weekly, those points were being picked up.
What I hadn’t – what I didn’t do was put them into a dashboard.
Mr Stevens: Fujitsu through the Post Office solicitors is recorded to have said that to retrospectively carry out detailed analyses, it would require a disproportionate effort and cost to provide these. If we could go up the page, would it have been difficult to ascertain these issues or ascertain this data retrospectively?
Steve Bansal: I think some we of the data would have been available but I don’t think it would have been easy to have then subsequently collated all of it.
As I say, some of those points, I think, are discussed but is it there for anyone to root out? I don’t think so. Depending on how far back anyone would like anyone to go to retrieve that historical data, it would take some effort.
Mr Stevens: Do you think it would have been helpful to have this information available in a dashboard form, as you suggested?
Steve Bansal: With hindsight, yes.
Mr Stevens: Please can we move to another document. It’s FUJ00085953. This is a 2015 “[Post Office Account] Problem Management – Problem Review” and the abstract says:
“This report contains the trend analysis of the 34 problem records raised in the [Post Office Account] Problem Management TfS database during 2015.”
The TfS database, is that the TRIOLE –
Steve Bansal: Yes, TRIOLE for Service.
Mr Stevens: Can you recall when this type of annual review was first conducted?
Steve Bansal: Possibly ‘13 onwards.
Mr Stevens: Do you know why it was implemented?
Steve Bansal: Because I wasn’t – I didn’t have that information, so I requested it to commence.
Mr Stevens: What did you want that information for?
Steve Bansal: So I could do a review of the problems and then I would have effectively a year-on-year view of what was going on so I could trend at a much bigger scale.
Mr Stevens: Was this an internal document or was it shared with Post Office?
Steve Bansal: I think it’s internal.
Mr Stevens: That document can be taken down, please, and if we can go to POL00029084 and if we could go to the email at the bottom, please, this is an email chain in September 2010 from Gareth Jenkins. Did you know Gareth Jenkins?
Steve Bansal: Yes, I did.
Mr Stevens: Did you work with him?
Steve Bansal: I worked with him on occasion, yes.
Mr Stevens: His role at this stage was distinguishing engineer. What does that mean or how did you see his role in Fujitsu at this point?
Steve Bansal: I saw him as a 4LS, so fourth line support. He was an architect and an SME.
Mr Stevens: Here he’s referring to a receipts and payments mismatch issue and he’s attached a document. This has now become known as the receipts and payments mismatch book. Are you aware of the nature of that book?
Steve Bansal: I am at a high level, yes.
Mr Stevens: Just for ease, could you give your high level description of the book and how it operated?
Steve Bansal: So I think effectively … I’m not sure how to put it into words but – I’m going to say no then.
Mr Stevens: It was a case, was it, where postmasters would try to put – to do a trial balance, so they wouldn’t do a complete balance but would try to do a trial balance, and there would be a discrepancy that they were asked to put into – whether they wanted to put it into the local suspense account. Does that sound right, so far?
Steve Bansal: That sounds about right. I was going to say it had suspense account.
Mr Stevens: Then if you cancelled at that stage and you were taken back to another screen where you’re given various options, but when they cancelled, in the local cache, the counter’s own system, the discrepancy was zeroised. Does this sound right?
Steve Bansal: Yes.
Mr Stevens: So far. The problem was if they rolled over again from that point there would be – the fact the discrepancy had zeroised would be essentially recognised and there would be a discrepancy between what the counter showed and what was in the actual back end systems. At that a high level, does that sound –
Steve Bansal: At a high level I think that sounds …
Mr Stevens: So going back to one of the problems we said earlier, in terms of problems, that’s really quite a significant problem.
Steve Bansal: That’s a very significant problem.
Mr Stevens: In this email, the third paragraph down, Mr Jenkins says:
“We probably need to formally raise this as a problem with POL. I’m not sure how this is done, but presumably you can initiate that. We should then plan to do the initial analysis and provide POL with a view as to the scope and then agree how to progress it.”
Why do you think it is that a senior member of Fujitsu’s front line staff was not aware how to formally raise a problem at this point?
Steve Bansal: I can’t comment on that but yes. No, I can’t comment on that.
Mr Stevens: Are you aware of any steps that Fujitsu took to make its own staff aware of the problem management process?
Steve Bansal: I think that it is done not necessarily by a broadcast or a communication but the wider account are aware that the service team have a problem management function because they are involved, shall we say. Third line, fourth line are all aware of the problem management function and, as I say, they do support it. So I’m not sure why Mr Jenkins didn’t know how the process worked.
Mr Stevens: If we go to the top of this email, we see that Mark Wright subsequently sends you this?
Steve Bansal: Yes.
Mr Stevens: Were you the problem manager?
Steve Bansal: I then pick this up, yes.
Mr Stevens: In broad terms, do you remember how the problem was handled?
Steve Bansal: So I think from that point on we raised the problem record. We got – Gareth was more heavily involved to do his analysis. When we discussed it, my feeling was that we would need what I called a White Paper, just a paper that would go through in detail because – as I failed to articulate the summary of the scenario back to you is because in – I think it was quite complex and so what I asked Gareth to do was to actually write it up in a White Paper so effectively when we communicated with Post Office we were clear in what the issue was, what the scenarios were and where we’d got to with our investigation, and it was that paper that I subsequently shared with Post Office.
I think thereafter there were multiple conversations which Gareth and occasionally I was also party to.
Mr Stevens: Can we leave that there then thank you and move to one final – sorry, penultimate point, and it concerns a briefing to the NFSP. Please can we bring up POL00002091. This is a Fujitsu NFSP briefing on 4 July. If we turn to page 2, you see in the right-hand column that you’re there to talk about capacity management, transaction monitoring and event management as well as major incident history.
Do you recall why you were asked to give this talk to the NFSP?
Steve Bansal: I think it’s possibly because there had been in that particular period or leading up to that period a number of major incidents and I think it was effectively to confirm that and acknowledge that we’d had them, what had been done about them and, effectively, how many actions came out of them and to give them a level of assurance and also to allow them to pass on any feedback and comments around each of those scenarios – each of those incidents, rather. But, again, a long time ago, so I think.
Mr Stevens: Do you recall, when you were drafting the content of the briefing, was that reviewed by anyone or was it your own work?
Steve Bansal: I think it was my own work.
Mr Stevens: Did the Post Office have any input into the briefing?
Steve Bansal: I don’t believe they did directly.
Mr Stevens: You say “directly”.
Steve Bansal: I may have discussed it with whoever at the time to give them an overview of what we were doing and whether they were comfortable with that.
Mr Stevens: Do you recall from anyone having any pressure put on you as to what should go in the briefing?
Steve Bansal: No.
Mr Stevens: Can I ask the screen to go to page 48, please. This is part of the problem management section on which you gave a presentation and you provide a problem report and you give the example of counter transaction processing. The summary states:
“Last week we analysed the milliseconds each transaction takes and found an issue in the recent version of the IBM Tivoli software that has affected counter transaction performance.
“Most of the counters have this version of the software. We are still well inside SLA but it is not as optimum as we would usually prefer.”
So is it a fair summary that this problem that’s been picked here is that transaction times were intermittently taking longer than expected?
Steve Bansal: Yes.
Mr Stevens: How much longer are we discussing in this case?
Steve Bansal: Again, I’m going to suggest it’s in the milliseconds and, as is alluded there, we are within SLA but it’s something we picked up and we are informing both Post Office and the National Federation of SubPostmasters.
Mr Stevens: Can you recall why you chose this as the example problem?
Steve Bansal: Possibly because it’s a proactive update.
Mr Stevens: Did you discuss problems such as the receipts and payments mismatch book?
Steve Bansal: I don’t think so unless it’s in the list in the – sorry, in the presentation.
Mr Stevens: In the presentation.
Steve Bansal: Apologies. Then not. I don’t know and I can’t recall what the scope was, whether I just went back six months, whether I went back whatever. But, no, it wasn’t mentioned if it wasn’t on that slide.
Mr Stevens: Can you explain why you use this problem rather than a more significant problem like the receipts and payments mismatch book?
Steve Bansal: No, I can’t.
Mr Stevens: Do you think choosing this as a problem was a fair reflection of the problems in the Horizon IT System?
Steve Bansal: I think at the time possibly I was trying to get a balance because, again, as I say, we’d gone through a period where there had been some major incidents and I was trying to give some closure and some level of confidence that we were kind of over that period and this particular one would have been – I don’t recall exactly but possibly would have been fairly current. I can’t say at this moment where either of the two other investigations you’re referring to where they were, whether I had something substantive to be able to provide.
Mr Stevens: This was in 2012, this presentation. The receipts and payments mismatch book was in 2010?
Steve Bansal: Yes, so I don’t think the presentation would have gone back two years.
Mr Stevens: That’s what I want to deal with on problem management. Just before I finish, I wanted to go back to a document I took you to right at the start. It’s FUJ00058375. Forgive me for the jumping around in the chronology.
It’s the “Direct Interface Testing Specification”. Please could I ask that we turn to page 11. So I took you earlier to what it said about PinICLs, PinICLs being recorded. This says “IT SERVICES”, at the top. This is the next paragraph:
“IT SERVICES will fax details of incidents raised to Pathway …”
Now, where it says IT services there, is that referring to Post Office?
Steve Bansal: I believe it is.
Mr Stevens: It says:
“IT SERVICES will fax details of incidents raised to Pathway, if any incidents are found to be software or hardware faults these will be entered into PinICL. A copy of the PinICL report will be faxed to HAPS.”
Is HAPS Post Office?
Steve Bansal: I think HAPS is external in Farnborough.
Mr Stevens: If we look at the – it may help to look at page 3, just for your assistance and the abbreviations.
Steve Bansal: Yes.
Mr Stevens: “HAPS (POCL) Host Automated Payment Service”. So is that a branch in Farnborough?
Steve Bansal: Memory may be vague but I think HAPS themselves were based in Farnborough. So I think the initial – no, I could just be completely wrong here. It could be that IT Services provide us the fax, we then raise the PinICL, and then send it back to them but then I don’t know why it’s worded that way.
Mr Stevens: So is the wording being raised a PinICL – sorry, they inform Fujitsu of the problem, a PinICL’s raised and the PinICL’s faxed back to Post Office?
Steve Bansal: Yes, why it says “HAPS” and it doesn’t say “IT Services” I’m unsure because HAPS, to my mind, is effectively third party and is Farnborough-based, rather than IT Services which would have been back to Post Office.
Mr Stevens: Can we turn to page 12 of this document and down to section 7. It says “Responsibilities test sign off”:
“This will be via a handover meeting at which the interfacing systems will give their approvals.”
We’ve got POCL, PDA, Pathway. Could you just explain what that – was it the case that all three had to approve the test scripts?
Steve Bansal: Effectively, yes.
Mr Stevens: Thank you. I have no further questions but there are questions from – may I just turn my back for a moment?
Steve Bansal: Yes.
Mr Stevens: Sir, there are questions from Core Participants, I believe.
Sir Wyn Williams: Certainly. At the moment, I’ve just got that last document on the screen so I can’t see you sadly.
Mr Stevens: I’m sorry.
Sir Wyn Williams: Who is going first then?
Mr Stein: None from us, sir.
Questions by Mr Henry
Mr Henry: Thank you, Mr Bansal. Could I just ask you to reflect on your role as a problem manager and then a service SDM. When were you a problem manager? 2010?
Steve Bansal: Yes.
Mr Henry: Right. What I’m going to be suggesting to you is that the White Paper was, in fact, to do with the receipts and mismatch bug. You can’t recall that specifically but if a document were to arise that in fact establishes that fact, you would not dispute it, would you?
Steve Bansal: I wouldn’t dispute it.
Mr Henry: No, and so therefore that can be dealt with another witness. But the fact is there were a number of problems, both when you were a PM and an SDM, to do with Horizon Online. You must have been extremely busy. Do you agree?
Steve Bansal: It was the role, it was the job.
Mr Henry: Now, in 2010 – there’s a document that I’d like to put up which is FUJ00084531. Now, can we just have a look at this. Page 1 we can see – and thank you. Could you scroll so that we can see the – yes, thank you, just there.
Can you just make the screen a little bit smaller, please? That’s fine. Maybe a little bit bigger to your previous position – forgive me. I just wanted to be sure that nothing had been cut out yes. Thank you.
So we have at that point a number of PEAKs. There are 25 on hold, correct?
Steve Bansal: Yes.
Mr Henry: Three are impacting. Does that mean that they have some adverse effect on the system because they are impacting? Is that the description given?
Steve Bansal: I’m not sure if they’re out for impacting; so to be assessed.
Mr Henry: The fact is that “impacting” often has a deleterious connotation, doesn’t it, at times?
Steve Bansal: I believe they were out for assessment.
Mr Henry: You’ve got investigation, which is – again, it’s not resolved. So “hold” is not resolved, “investigation” is not resolved. What does – “monitoring” obviously you’re just waiting to see whether it’s going to get worse; is that right?
Steve Bansal: They are monitoring to see what is happening, yes.
Mr Henry: Right, exactly. “Release to live”: what does that mean, please?
Steve Bansal: “Release to live” means that they are being packaged and distributed.
Mr Henry: And then “to be closed tomorrow”, that means that they are supposed to be sorted?
Steve Bansal: Effectively they could be the ones that are currently on monitoring –
Mr Henry: Right.
Steve Bansal: – a period has been agreed and that potentially is tomorrow.
Mr Henry: And then “waiting fix” means that there’s 14 that are awaiting resolution?
Steve Bansal: Correct.
Mr Henry: So really we’ve got roughly, haven’t we, 60 issues that you’re not on top of because you’ve got 25 on hold, 19 which are being investigated, and 14 which are awaiting a fix – roughly 60?
Steve Bansal: That’s what I think it says, yes.
Mr Henry: Thank you. Could we just scroll up, please.
Why is it called “prayers” as a matter of interest?
Steve Bansal: I think it was just a given name. I’ve no idea. This is dated a couple of days after I joined, but yes.
Mr Henry: Sometimes prayers means “heaven help us”. I mean, you can’t think why there was that sort of – was it an acronym? Did it stand for anything or was it “Oh my God”, you know, “look what we’ve got to deal with”?
Steve Bansal: I couldn’t say.
Mr Henry: You couldn’t say. You never asked?
Steve Bansal: Never asked.
Mr Henry: Right, okay. Scroll up, please. Thank you.
Pat Lywood: who was Pat Lywood?
Steve Bansal: Pat Lywood was a member of the Post Office account. I can’t remember her exact role.
Mr Henry: Don’t worry. Let’s just scroll up a little bit further, please. You see we’ve got Mr Godeseth there as well. Do you know notice his name?
Steve Bansal: It’s not jumping out at me but, yes, it will be there.
Mr Henry: Don’t worry. Torstein Godeseth. Carry on, please. If you scroll up. And a little bit further up, please, so I can get to the text of the message, if you please. Isn’t a suggestion that here you are being asked if there’s anything you can do to speed things up? I think there’s some further text and delay. Carry on, please.
Steve Bansal: Yes, I think you can see it’s a communication to –
Mr Henry: Sarah P, ENT:
“Sheila, please could you take a look at the ones on you and try to resolve some of the hold investigation ones.”
So this was basically a constant battle, wasn’t it?
Steve Bansal: It was an update communication to everyone to see if they can address any PEAKs to speed things up, yes.
Mr Henry: I mean, a constant battle with instability and errors, wasn’t it?
Steve Bansal: It was a call to address PEAKs, yes.
Mr Henry: 60 of which were, you know, as you’ve already said, remain to be resolved.
Could we now move on please to POL00029493, please.
I’m so sorry, I thought that that was notified. So it’s 00029493. That’s interesting because I actually have it on my system and it’s one of the ones that I was allowed to ask. Don’t worry, we don’t need to put it up.
I just want to ask you, please, just very – were you aware that this was a retro-engineered system? The way in which it had been eventually allegedly made acceptable was to reverse engineer it. Rather than prospectively design a logical system, it was essentially dealing with a number of problems and trying to reverse engineer it but at the same time, when that was happening, further problems were being introduced. Were you aware of that?
Steve Bansal: I wasn’t necessarily aware of that.
Mr Henry: You weren’t told that, fine.
Could we move on, please, to POL00029460. This is a major incident report and you’re the owner. And could I ask you, please, to help me. Was that data – familiarise yourself, please, with the document. Has it been shown to you in advance?
Steve Bansal: Possibly.
Mr Henry: Do make yourself familiar with it. Tell me you’re – it would help if you could let the officer know who is very kindly assisting in scrolling up. So you just let her know when you need to read more of the document.
(Pause)
Steve Bansal: Could you scroll up.
Mr Henry: I would like you to concentrate, please, on the first three paragraphs within the box “analysis of problem”. Obviously, you must read everything but I want you to – of particular interest to “Post Office Limited” down to “1 February”.
Steve Bansal: Are we also able to go down to the root cause?
Mr Henry: Yes, of course. Please do. I’m not trying to … (Pause)
Steve Bansal: Okay. Then if we could go back to that section.
Mr Henry: Of course. Of course, Mr Bansal.
Right, now my question is that this is described as an update but if you see the second paragraph in analysis of the problem:
“This was a second iteration of the data as a problem had been identified with the initial dataset that had been supplied during validation of the token data. The CTO update was in effect a primary package with an incremental update.”
Was the data update in fact actually a fix because of the problem identified within the initial dataset?
Steve Bansal: I couldn’t tell you.
Mr Henry: You couldn’t say.
Steve Bansal: I couldn’t say at this moment in time.
Mr Henry: Fair enough. Don’t worry. I now have permission, sir, to refer to POL00028830. We can see the date of this. This is 28 September 2010 and it relates to PEAKs PC024765 and PC0204263 and then 64 and 63 is again mentioned.
Can I just ask you, please, to look at this document which I have permission to put to you. So, again, if you could inform the officer who is presenting it. (Pause)
Steve Bansal: Okay, if we could go up.
Mr Henry: You can see there, can’t you, receipts and payments mismatch. If you go back, PC0204263 describes a problem with SU balancing that will result in a receipts payments mismatch. So given the fact that is authored by Gareth Jenkins, we can fix his knowledge as to that problem in September and isn’t that the White Paper that you were –
Steve Bansal: I believe this is the White Paper I was referring to.
Mr Henry: Well, I’m very grateful, sir. Thank you very much for your time and your patience.
Sir Wyn Williams: Are there any other questions?
Mr Stevens: No, sir. That’s everything, thank you.
Sir Wyn Williams: Well, I’m very grateful to you, Mr Bansal, for coming to give evidence to the Inquiry and also being very flexible about the time when you started giving evidence and the progress of your evidence and that’s helped us to move along efficiently. So thank you very much again.
Steve Bansal: Thank you, sir.
Mr Stevens: Thank you, sir. That concludes today but we have Steve Muchow tomorrow.
Sir Wyn Williams: So that will be at 10.00?
Mr Stevens: Yes, sir.
Sir Wyn Williams: It is just Mr Muchow tomorrow?
Mr Stevens: Yes, it is.
Sir Wyn Williams: Fine, thank you. See everyone tomorrow. Goodbye.
(1.42 pm)
(Adjourned until 10.00 am the following day)