12 January 2023 – Stephen Muchow
Hide video Show video
(1.00 pm)
Mr Blake: Good afternoon, sir.
Sir Wyn Williams: Good afternoon.
Mr Blake: Can I call Mr Muchow.
Sir Wyn Williams: Certainly.
Stephen Muchow
STEPHEN MUCHOW (affirmed).
Questioned by Mr Blake
Sir Wyn Williams: Good afternoon, Mr Muchow. I hope you haven’t had too difficult a time in getting to the Inquiry this afternoon.
Stephen Muchow: You obviously have heard. Yes, my train was cancelled and then my seat was taken on the next one.
Sir Wyn Williams: If it’s of any consolation to you, if I had been attempting to come, I wouldn’t even have got out of the town in which I live. So at least you got there.
Stephen Muchow: I texted my wife to say much the same for the future.
Mr Blake: Thank you. Can you give your full name, please?
Stephen Muchow: Stephen Manfred Muchow.
Mr Blake: Mr Muchow, do you have in front of you a witness statement?
Stephen Muchow: I do.
Mr Blake: Is that statement dated 12 September of this year?
Stephen Muchow: It is.
Mr Blake: Could I ask you to have a look at the final page, page 22 of 24.
Stephen Muchow: Yes. That’s my signature.
Mr Blake: Thank you. Is that statement true to the best of your knowledge and belief?
Stephen Muchow: Yes, it is.
Mr Blake: Thank you very much, Mr Muchow. That statement is going to go into evidence and it will be uploaded onto the Inquiry’s website so the questions I’m going to ask you today will be in addition to the questions you have already been asked about in that statement. But I’m going to start with a bit of background. You joined ICL in 1979; is that correct?
Stephen Muchow: Yes.
Mr Blake: You held various roles in Pathway and then Fujitsu until your retirement in 2009?
Stephen Muchow: I did, yes.
Mr Blake: Much of your time at Pathway was in the customer services division; is that right?
Stephen Muchow: Yes.
Mr Blake: I think between 1985 and 2001 you were in that division?
Stephen Muchow: In fact, most of my career in ICL has been with customer service.
Mr Blake: And you were customer services director at the time of the rollout of Horizon?
Stephen Muchow: No, I was customer service director, yes. I beg your pardon.
Mr Blake: I think in 2001 you became business director?
Stephen Muchow: Yes, there were some organisational changes in the offing and I became interim managing director, which is business director.
Mr Blake: So for the core period that we’re going to be addressing today you were customer services director?
Stephen Muchow: Yes.
Mr Blake: I’d like to start by looking at the hierarchy of ICL at the time. Can we look at POL00028211, please. Thank you. This is part of the codified agreement. If we turn over the page, it has – could we look at the structure there, the diagram at the bottom of the screen there. Thank you very much.
So we have there your name, it’s the second one from the right-hand side, director customer services; is that right?
Stephen Muchow: Yes.
Mr Blake: There’s quite a flat structure. Can you just explain to us how that worked with the various directors and who they reported to.
Stephen Muchow: Well, we all reported to John Bennett. This was a contract, a PFI contract initially, and there were myriad streams of work and expertise required and so all of these people here were responsible for a very specific part of the bid for the contract and subsequently some of us remained on to operate.
Mr Blake: So in terms of your reporting line, is it Mr Coombs and Mr Bennett or principally Mr Bennett or principally Mr Coombs?
Stephen Muchow: Principally Mr Bennett but my recollection of Mike Coombs was that he was a very difficult man to ignore and he had a great sway.
Mr Blake: Was it straightforward to report concerns to the managing director and the deputy managing director?
Stephen Muchow: Was it straightforward?
Mr Blake: Yes, in terms of the reporting lines and their management style for example.
Stephen Muchow: Yes. I think John Bennett – he chose the people that he wanted to do these roles. He interviewed us. I remember there being quite a team spirit. This was a very large bid that we were mounting, one of the largest, I think, that ICL Fujitsu had ever done, and I think it depended on a great deal of teamwork. So we were very much a team and John, as I recall, was somebody who – he had an open door and we knew what we had to do. He set our objectives and we got on with it.
Mr Blake: Can we look at page 16, which sets out your CV in a bit of detail. Thank you. I’m just going to read that section, 1996 to the present, so in 1996 to the time of the contract. It describes your role as:
“Director Customer Service, Pathway.
“Responsible for all aspects of Customer Service across all boundaries both internal … and external and with subcontractors.”
Stephen Muchow: Yes.
Mr Blake: If we go over the page, it sets out your role in a little more depth, and it says there:
“Role.
“Operate services in accordance with service level agreements … The current role includes:
“Client
“POCL operational support services
“Help desks
“Counter support services
“Site services
“Training (ongoing)
“Management information …
“Pathway
“Help desks
“Site services
“Training
“MIS”, I think is management information?
Stephen Muchow: It is. There’s clearly a few typos in there.
Mr Blake: But it’s fair to say your role covered both helpdesks and training?
Stephen Muchow: If it wasn’t to do with development, then operationally it was for me to deal with. So I didn’t do any development, I didn’t do any implementation but my team looked after the operation of the data centres, the support services, the management information system, which was actually probably one of the largest components of that because we were building something from scratch. We didn’t have anything available off-the-shelf. This all had to be built.
Mr Blake: What does that mean, management information services very briefly?
Stephen Muchow: Management information systems, not services, the systems which, for instance, we had to submit every month how well we’d done in achieving the service level agreements that we’d signed up to do. So we had to devise ways of showing how the helpdesks had responded, how the transactions had performed – I’m sure you will come on to this – how many incomplete transactions and lost transactions there were, and so on.
And all of that was done by my team in devising processes, procedures and spreadsheets and other forms, that maybe there were some databases written by the SSC, data applications to capture the information that we gleaned from the system, in order to inform the management team how well we were doing.
Mr Blake: I’m going to begin, just by way of background, to ask you some questions about the Helpdesk. We have heard the about Helpdesk, both in the previous phase and this phase, but just to refresh our memory can you tell us, in very brief terms, what the Helpdesk was, the Horizon System Helpdesk how that differed from, for example, the National Business Support Centre.
Stephen Muchow: Yes. The Horizon System Helpdesk was the first point of contact for most things that were unexplained, went wrong, confused in the system. So the postmasters and their staff would call the Horizon System Helpdesk when something didn’t go right.
The first line of support was the HSH where they would log into a system called PowerHelp, which was a global ICL system for recording calls, and they would follow scripts to determine – initially, there were no scripts but we developed scripts later, as the Helpdesk matured and as problems emerged, to try and determine where the postmaster or the operator of the counter terminal was in relation to the process of performing a transaction and what had gone wrong at that point.
So the Helpdesk, that became the first line of support.
There was a second line of support, which dealt with more hardware-type problems like – so if the comms had gone down or if the barcode reader had failed or the printer hadn’t worked, then those things would be passed on to the second line of support who – they would schedule an engineer mostly to deal with that problem.
Then anything that was a little more complicated that couldn’t be resolved in that way and with particular timescales, as well – I can’t remember what they were particularly, but there were quite stringent timescales in which we had to resolve these issues – then the call would be escalated to third line, which would be the SSC, the Systems Support Centre, and they had far more knowledge of the application itself, not from a development perspective but they had access to how the system operated and they knew how the system software integrated with the hardware, and so they would be able to deal with a much more in-depth query and hopefully resolve a fault.
If they couldn’t resolve it, then the problem rested with development. So there was something fundamentally wrong with the product and it would be escalated to fourth line support. But the HSH, primarily, was levels 1 and 2. So the HSH taking calls direct from the postmasters and then passing on to the SMC, the second line of support, and they were mostly engineering calls.
Mr Blake: Did you hear Kevin Fletcher’s evidence from earlier this week at all?
Stephen Muchow: Kevin Fletcher?
Mr Blake: Yes.
Stephen Muchow: No.
Mr Blake: One issue that was addressed was training and his evidence was that any concerns or concerns about training and the length of training – so let’s say it was a day and a half for managers – would have been resolved because there was a Helpdesk, so users could use the Helpdesk. Did you see the Helpdesk as fulfilling that kind of a role, filling the gaps in the training?
Stephen Muchow: At the time, no. Now even less, I think.
Postmasters took many years to get where they were in dealing with the processes and procedures of the Post Office; selling stamps is not as trivial as it sounds. But even more so, when you start introducing benefit encashment services and those things were very, very complicated and, even the postmasters struggled before in my understanding before Horizon with some of the rules, and so on. But at least at that stage they were in charge of everything themselves.
When it went into Horizon, the recording of what they did was assumed to be automatic and sometimes the software may have assumed that they did things as the software expected them to do and, if they didn’t, then there would be a problem. The Helpdesk had the dilemma, it didn’t understand, first of all, how the Post Office, how the postmasters did their normal operations. They were simply responding to “I’ve got a problem with my printer” or “I can’t balance” or something like that. They would follow a script but they didn’t – that was in no way a substitute for 20 years’ experience of doing that type of thing manually and so I don’t think the Helpdesk was capable of doing that.
Mr Blake: In terms of the training then, were you involved in the training in the early stages?
Stephen Muchow: No, not involved in the training. I was involved in negotiating with Peritas and I think earlier it was called ICL KnowledgePool.
Mr Blake: Yes.
Stephen Muchow: I think there were three names – ICL Training Services, KnowledgePool and then Peritas – which they were the professional trainers and we simply negotiated contracts with them and they learned their input from Post Office Counters Limited.
Mr Blake: This is slightly out of order but, just reflecting on that training, do you think it was sufficient, given your experience of subsequent issues with the Helpdesk?
Stephen Muchow: Well, I wouldn’t have said it was totally inadequate. That’s a very loaded criticism. But how can – it was sufficient to talk through the process of operating the equipment to perform a specific transaction. Where I think it failed and was not adequate was that you couldn’t imagine the sort of things that a postmaster or member of the public had done even to disturb that perfect expectation of the software.
So software is written to some rules and the rules are that you do this, this, this and these are the sort of – you’ve seen them, the sort of drop-down options on a spreadsheet, for instance. If you do something that’s not there, then it’s the lack of robustness of the system that causes the problem and I think it was not clever enough to anticipate all of the different ways in which the operators and the environment, you know, communication systems included, could perversely affect their sort of ideal expectation of events.
Mr Blake: I’m going to move back in time and talk about the early stages, early issues, Acceptance Incidents. We’ve heard a lot about those in Phase 2 and I won’t spend too much time on them, but there appear to be three particular Acceptance Incidents during the contractual stage that you were involved in.
Can we look at FUJ00119869, please. This is a note from an acceptance workshop on 9 September. Do you remember what acceptance workshops were at all?
Stephen Muchow: Yes, yes.
Mr Blake: Can you tell us very briefly what their purpose was?
Stephen Muchow: Basically, Acceptance Incidents were things that got in the way of Post Office paying – accepting the system and paying Fujitsu for what it had done. So there were some very strict rules of – I can’t remember precisely what they were but you had to have zero of these and no more than one of those, and so on, and these Acceptance Incidents were those keenly discussed at these meetings.
Mr Blake: We have your name there down as a representative of Pathway and we have three numbers after your name 408, 412 and 298. I will use this document just to refresh your memory as to what those were.
If we look at page 3, we have there 298 was “Systems Stability”. Do you remember systems stability being an acceptance issue?
Stephen Muchow: Yes, yes.
Mr Blake: Very briefly, are you able to remind us what that was?
Stephen Muchow: Well, things would go wrong without any clear explanation at the time. There might be a blue screen, which I remember that this was a Windows NT system and Windows NT was notorious for blue screening; things would go slowly; there would be a scheduling problem within the software; when the system for – unexpectedly simply didn’t work properly.
Mr Blake: Can we look at page 13 which addresses Acceptance Incident 408. It has there “408 [Horizon System Helpdesk] Performance”. Can you remember in brief terms the issue there?
Stephen Muchow: Yes, yes. I was very, very disappointed with the Horizon System Helpdesk performance not because they weren’t trying but because we couldn’t get the right staff, the right quality of staff to stay in the Helpdesk. This was part of the work that was contracted out to another division in ICL and it was always the case that the Helpdesk was blamed for something, whether they’d given false information or wrong information – not false. Sometimes I would say they gave misleading information.
There were a number of occasions when I felt that the Helpdesk was not performing as it should and I think, in fact, we raised two red alerts on the Helpdesk.
Mr Blake: We will come to speak about those red alerts in a moment. Can we look over the page to incident 412. That’s described as “Service Performance Ad Hoc Reporting”. Do you remember that at all, very briefly?
Stephen Muchow: I don’t remember it from the top of my head. I’m just reading it again.
Oh, ad hoc reporting, yes. This was the situation where we felt – my MIS team and the business support unit team felt that Post Office were being a little free with their requests for information and they were demanding things, ad hoc reports, and I think we were probably snowed under, just keeping ahead of – or keeping abreast, not ahead – of what we had contracted to do. I think we had underestimated the volume of Post Office asking for analysis of data, and so on.
Mr Blake: Thank you. I want to focus today really on 408 and can we look at POL00028468, please. This is a plan for the resolution of 418 and it’s dated 8 September 1999. That’s the top right-hand corner. Do you remember this at all? If we scroll down, it has your name as somebody who reviewed the document. Is this something that you remember?
Stephen Muchow: Sorry, I will remember the words when I read them again but it’s not something that’s sort of fixed in my mind, no.
Mr Blake: Let’s look at page 5, please. It’s the bottom of page 5 and it sets out there the Post Office’s position. I’ll read those briefly for the purpose of the transcript and to refresh your memory. It says:
“Based upon the minutes of the Acceptance Board meeting of 18 August 1999, POCL contended that:
“‘Production of scripts is not complete’.
“‘It does not take account of activities such as the need to train staff’.
“‘Some items have already missed dates’.
“‘Call volume projections and staffing projections contain assumptions that POCL cannot agree based on experience to date’.”
Then it has some further points just over the page:
“POCL’s experience to date is that some scripts have resulted in inappropriate advice resulting in further calls to HSH and the [NBSC].
“POCL requires an explanation of how the call volume projections are produced and the logic that supports this process.
“POCL requires that the SLA rectification plan is produced and agreed.”
Do you remember those concerns and do you remember whether you agreed with them, disagreed with them, had a concern about that?
Stephen Muchow: Frankly, I don’t think there’s anything to disagree with. These are all truisms. I didn’t necessarily understand at the time how many of these things. When we put together our call volume estimates, the plan for sizing of the various services, some of it was a shot in the dark and missed. So we had to come together and produce a rectification plan, which is what this is all about.
Mr Blake: Can we go back to the workshop of 9 September. So that’s after this. So that’s FUJ00119869. If we look at page 13, I’m going to read to you that first entry. It says:
“Pathway will arrange a workshop aimed at giving POCL confidence in their resourcing model and to confirm their analysis that a level 3 expert domain for cash accounting is required. Report back outcome and issues to this group.”
Do you remember the issue about requiring a level 3 expert domain and what that might mean?
Stephen Muchow: Not specifically, no, but it seemed sensible.
Mr Blake: So you’ve described to us the various levels of Helpdesk. I that saying that there should be extra expertise in relation to cash account issues?
Stephen Muchow: Yes, in the SSC level 3.
Mr Blake: Do you remember why that might have been needed at that time?
Stephen Muchow: Because the first and second level support structure was inadequate to be able to resolve those issues and it would inevitably be escalated to level 3 and, if you didn’t have more expertise in there then where else? Well, you would have to escalate it to level 4 and they were doing development of the next release. So, no, we had to have level 3 expertise.
Mr Blake: Can we go to FUJ00119870. This is a bit later on, so 13 September, not too far on. Can we look at page 11. We return there to Acceptance Incident 408 and, again, on the second entry there:
“Pathway to produce outline proposal on Service Levels for the cash accounting expert domain.”
Do you remember that ultimately happening, the extra assistance for cash accounting? Did it happen? Is that something you have any recollection about?
Stephen Muchow: It must have done. I can’t specifically remember it from an event flag that – I just don’t remember that but it must have done because, ultimately, this was resolved.
Mr Blake: I’m going to read to you that final –
Stephen Muchow: Excuse me, and ultimately we did have more expertise in level 3 in the SSC.
Mr Blake: Do you remember when that was? Was that on –
Stephen Muchow: No, no, but it would be within this time period certainly.
Mr Blake: If we look at the final entry on that page, it says:
“Performance Service Level statistics for August have been reproduced by Pathway to exclude the cash account calls. POCL to assure that the statistics are being appropriately reported. Pathway and POCL … to meet to review the new service level report.”
Is that something you remember at all?
Stephen Muchow: Yes, I do. I mean, I remember Dave McLaughlin and Ruth Holleran saying “Well, we’ve got to make sure that you have not bundled a lot of other stuff in with cash account”. So what we were trying to do here was show that the performance of the Helpdesk had improved and the performance of the system had improved without the effect of the cash account calls. So this was – if you consider the cash account was very special and difficult topic, how were we doing on the rest of them, and that’s the purpose of that activity.
Mr Blake: Thank you. You have said that the cash account is a difficult topic. Can you expand on that for us a little bit?
Stephen Muchow: I wish I could. Cash account, stock units, the transfer of stock from unit to unit, I wonder sometimes if it’s just too complicated. Clearly, I mean, I think it’s probably been resolved by now. I don’t know. I’ve not seen what Horizon – what’s the new one?
Mr Blake: Online.
Stephen Muchow: I don’t know if that has resolved the problem but it was certainly very, very complex for the Legacy system.
Mr Blake: Do you remember at that time being told about particular problems with the cash accounts?
Stephen Muchow: I remember being – well, I remember there was a problem with – if you had voided a transaction but hadn’t meant to or had not allowed it to print, then there would be – it would be left in a funny state and, for instance, I think you could pay a benefit twice because the system didn’t think it had been paid but, in actual fact, you had handed over the money and that, for instance, would be a difficult thing.
I think there was another issue in small numbers of offices – sorry, small numbers of counters in an office where they might have – a different counter clerk would have his own stock unit but stock had to be transferred from the previous counter clerk’s – a bit like shift work and you have got to transfer. So I’ve got 100 stamps left and I’ve got to transfer those 100 stamps to a different stock unit.
If that hadn’t operated exactly as the software anticipated, then there would be a problem.
Mr Blake: Were those kinds of issues well known within ICL at the time or not?
Stephen Muchow: Well known within – not within ICL. Within Pathway, yes.
Mr Blake: Within Pathway, sorry, yes. When you say not within ICL –
Stephen Muchow: Well, no, ICL Pathway was separate from ICL.
Mr Blake: If I could just take you back to the first document we looked at, so it’s POL00028211. On that first page that’s the overall Pathway board and you have Mr Bennett there –
Stephen Muchow: Yes.
Mr Blake: – and you have Mr Christou from ICL –
Stephen Muchow: Yes.
Mr Blake: – and Mr Todd from ICL, they all reporting to the Chairman, Sir Michael Butler. Were those kinds of issues, as far as you were aware at the time, the kinds of things that would be discussed with ICL?
Stephen Muchow: Not in that granularity. Certainly, the board would be very interested in how we were doing, how we were performing in meeting the service level agreements. I mean, once it moved from a Private Finance Initiative where Pathway had all of the liability to an ordinary contract, then there were very, very specific targets to be met and failure to meet, say, those targets meant financial penalties on ICL Pathway and, therefore, on the board. They were certainly made aware of how well we were doing or how badly we were doing because, indeed, we did suffer penalties.
But they wouldn’t have known in such fine detail the reasons for those things.
Mr Blake: Can we look at POL00028509. This is on the same theme as the documents before. This is a 14 January meeting in 2000 – sorry, this is forwarding it but, if we turn over the page, it refers to it as a “Special Meeting” at Gavrelle House. Do you remember that meeting at all?
Stephen Muchow: Sorry, no.
Mr Blake: This seems to have been a meeting to decide on the recommencement of rollout and, if we look over the page, there’s a section that I can read to you at the top of the page. It says:
“Tony Oppenheim advised that ICL Pathway intended to move forward with POCL on the contractual agreement immediately following the meeting. The meeting between Andy Radka and Steve Muchow earlier in the day on the outstanding issues surrounding [Acceptance Incident] 408/3, and the level of agreement that had been reached would facilitate this contractual discussion. It was and intended that the summary of actions that had been produced as a result be incorporated as a working document, following review by the lawyers of both parties.”
So it seems as though there was agreement on that date to essentially go ahead with Horizon, despite issues with Acceptance Incident 408 still continuing. Do you remember that at all?
Stephen Muchow: I don’t remember the degree to which the outstanding issues with 408 impacted Post Office’s perception of the viability of continuing the rollout but, clearly, we did continue the rollout and so I must assume that we’d come to an agreement that it was okay. I can’t remember the details.
Mr Blake: I’ll just read the final paragraph on that page. It says:
“Agreed that if actions in place to address the outstanding elements of agreement worked, and no further issues arose prior to signing the third supplemental agreement, there was no requirement for a further meeting.”
Do you remember agreement to work on the issues relating to Acceptance Incident 408 going forward? It hadn’t come to an end in January at the time of rollout or just before rollout?
Stephen Muchow: They never came to an end is the honest answer to that. I mean, these things – it’s a matter of degree and risk. The customer needs to decide what he’s prepared to accept in terms of risk, quality of service, performance, and so on, and if we had been able to persuade them it was acceptable then they would go ahead. But they would need to make that decision for themselves. It was not – we couldn’t insist. So we worked constantly to try and improve.
These things – there will never be zero. You notice in some of the requests for performance there’s a target level of zero. Well, I’m sorry, but we never, ever achieved zero, not – except by good fortune in one particular month. It’s an exponential curve approaching zero, the more mature that the product becomes and the more experience that the support teams and the users have in the characteristics of the product itself.
So I think what this is saying is that we did come to an agreement that it was down to a sufficiently manageable level that didn’t pose a risk to going forward with the rollout.
Mr Blake: Can we look at POL00028512. This is very shortly after and it’s before the rollout resumes again in January. This is sent to you by Paul Westfield. Do you remember who Paul Westfield was at all?
Stephen Muchow: Oh yes. I’m his son’s godfather – well, I wish I were.
Mr Blake: What was his role?
Stephen Muchow: Paul was in charge of a number of things, actually, to do with managing the service delivered.
Mr Blake: Can we turn over the page, please.
Stephen Muchow: I can’t remember his job title, to be honest.
Mr Blake: So this is, again, “Acceptance Incident 408: Cash Account Call Analysis Review – Week 1 & Improvement Plan”.
Stephen Muchow: Yes.
Mr Blake: Perhaps we could turn to page 6. I’m just going to read to you that introduction. It says:
“In accordance with the monitoring requirements …”
So it seems as though there were monitoring requirements going forward for Acceptance Incident 408?
Stephen Muchow: Yes.
Mr Blake: “… the [Horizon System Helpdesk] sites at both Stevenage and Manchester are recording all Cash Account calls for a six-week period from [3 December 1999]. The taped calls are then being reviewed by POCL who will make an assessment as to the [Helpdesk’s] ability to:
“Conform to the narrative contained within the Cash Account scripts.
“Give out correct advice avoiding a negative impact on the POCL business.”
So this seems to be along the lines of what you have just discussed, which is that POCL would be monitoring the progress going forward?
Stephen Muchow: Yes, and those calls were recorded and they were reviewed. They were.
Mr Blake: If we look down at the bottom of that page, it gives the initial results. It says:
“POCL reviewed 45 calls out of 177 recorded for Cash Account activity on 08 & 09 [December] 99. Out of the calls reviewed, 13 were deemed to have failed in that by incorrect advice being given by the HSH this could have a negative impact on their business, or the HSH deviated from the Cash Account script.”
Is that something you remember?
Stephen Muchow: Not specifically but, yes, that’s the sort of thing.
Mr Blake: If we turn over the page, there is a table there. It seems as though there’s a difference of opinion between POCL and ICL as to how many failed or not. If you look the second line, “Number of Calls Failed”: POCL after Initial Review, 13; POCL after Joint Review they came down to 8; ICL Pathway view after Joint Review was zero. So it seems as though there’s quite a significant difference of opinion as to what amounted to failure.
Stephen Muchow: But after joint review there’s a considerable coming together of minds.
Mr Blake: Sorry, can you just expand on that?
Stephen Muchow: Well, POCL view after Joint Review, five number of calls passed and only eight failed not 13. So … they’d moved their position. They were persuaded that it was not necessarily just the Helpdesk at fault. I think the scripts were largely to be examined to see whether or not they went far enough. I think there was – the scripts sort of ran out of steam. I think there’s some talk of that later on in this document.
Mr Blake: Shall we look at page 10 which is the improvement plan and I’ll just read to you halfway down that first paragraph. It says:
“The components of this improvement plan have to be developed, tested and implemented within the [Helpdesk] prior to the expected commencement of rollout on [24 January 2000]
“From the 13 calls analysed in this joint review, and from experience gained within the ICL Pathway Customer Service Management Information Reporting, specific areas can be identified as causing confusion either in the outlet or at the HSH, these are believed to be:
“1. Out-of-hours stock units (eg Lottery) and associated prize allocations.
“2. Discrepancies and dealing with the entire complex subject of reversals and suspense accounts.”
So this is something that you had briefly addressed before –
Stephen Muchow: Yes.
Mr Blake: – about a particular issue with discrepancies and cash accounts. Can you perhaps expand on the significance of that?
Stephen Muchow: I think what this tells me now is that we should have recruited postmasters who knew what they were talking about to do this role to help postmasters and, in fact, later on, with the introduction of the – what was it called – the Network Business Support Centre, which was another helpdesk manned by Post Office Counters Limited, these issues were dealt with there. I think that was a sort of admission that lay persons simply couldn’t handle that type of call with good effect to the satisfaction of Post Office.
Mr Blake: Can you assist us with that, actually about, the role of the NSBC (sic) –
Stephen Muchow: NBSC.
Mr Blake: – NBSC – and how that fit in, both at this time and, as you said, later on?
Stephen Muchow: I’m not sure whether the NBSC – yes, it is:
“Where a business rule needs to be invoked by the NBSC.”
So the NBSC was equivalent to the HSH for postmasters for Post Office-related things and it ultimately – I think it took on, if not all, a lot of the work to do with dealing with cash account balancing, and so on, problems that we had not been very good at. But the NBSC was – it provided support to the network and the postmasters were their staff, if you like.
Mr Blake: Where did you see software issues that caused issues with balancing to fit into that overall picture of help?
Stephen Muchow: Well, they wouldn’t be resolved there. They wouldn’t even be identified there. They would be identified in third line support software issues. We had a number of systems. I think you’ve heard of the KEL.
Mr Blake: The Known Error Log?
Stephen Muchow: The Known Error Log. It’s more a font of all – it’s somewhere you could dump useful information a sophisticated Frequently Asked Questions-type affair.
They could look in there and that would – they should be able to, or they should have been able easily to have found that this was a common issue, that somebody else had had this problem.
When somebody has a problem for the first time you’re on your own. I mean, everybody’s – we don’t know. When a problem arises for the first time you’re in discovery mode.
When it arises for the second, third, fourth, fifth, 25th time, then you know you’ve got an issue which is potentially an operational issue, an infrastructure issue, a software issue. All of these things can come together to make it fail.
Interestingly, there was a time – I remember when we had – oh, I think it was in NR – New Release 2. There were a number of sites had no issues at all and some sites had terrible problems balancing. There is a document in my original bundle which demonstrates this.
The assumption was that there was a fault on the network that was dealing with that place but, in fact, I don’t think it was a network fault. I think it was something that had simply maybe have been missed or miscommunicated in the training and this group of postmasters who were doing it differently to this other group of postmasters. So my question was “Well, why have these guys got problems and these guys haven’t?” There’s something markedly different between the two groups, and that’s where you need the SSC to delve in to find out precisely what was going on and to see what the root cause was.
If they could fix it – they couldn’t fix it per se with a software fix but they could pass that on to development and they could look at it and see whether or not it was reproducible on their test rigs and, if it were, then they could incorporate that into the next change for the next release or a maintenance release. Again, we’d have to discuss that with Post Office but that’s how the system worked.
So the Helpdesk itself would only basically know either what was in the script or what had been reported before that had been fixed with a known workaround or a reinforcement of procedure.
Mr Blake: So you spoke about the Known Error Log. Who had access to that?
Stephen Muchow: I believe just the SMC and the Helpdesk and I think fourth line would have done but they were more interested in PinICL.
Mr Blake: Would the Post Office have had access to it?
Stephen Muchow: I don’t believe so. They might have done. They did when they had staff in Feltham working alongside the test teams. So, yes, they would have had access then.
Mr Blake: Who were those teams?
Stephen Muchow: Sorry, which?
Mr Blake: From the Post Office?
Stephen Muchow: I don’t know. Probably –
Mr Blake: What was their job, though, in Feltham?
Stephen Muchow: They would be looking at model office rehearsal and – yes, model office rehearsal, I think. MOR1, MOR2 from recollection.
Mr Blake: Your understanding is that they would have had access to something – to the Known Error Log?
Stephen Muchow: Perhaps that’s too strong. Maybe I should say they were not denied access but it was there and –
Mr Blake: So they would have access to ICL internal network or internal systems?
Stephen Muchow: I don’t think they will have had access to internal systems, no, because these were shared systems sometimes and had information on them which wouldn’t have been right to share with the outside.
Mr Blake: So something like the Known Error Log may have been something they could have requested, for example; is that your evidence?
Stephen Muchow: I think they could have done, yes.
Mr Blake: But it’s not something that they would have made available to them as of right?
Stephen Muchow: I cannot recall mandating that Post Office should have their own access to the Known Error Log but I don’t believe they were ever denied access to that and I’m pretty sure that PinICL and Known Error Log was used in communication with Post Office when we were discussing problems and, in fact, in many of the boards, I think even in the CAPS board, there were PinICLs discussed there.
But the PinICLs were likely to have been, if you like – I don’t like using the word “sanitised” because it suggests we’re hiding something but there would have been extracts exported from PinICL to give to the management teams who were deciding when to go forward or whether not to go forward.
Mr Blake: Thank you. I’m going to take you to another document. FUJ00118186.
This is the third supplemental agreement that was between Post Office and ICL Pathway on 19 January 2000. Is this something you had any involvement with?
Stephen Muchow: I think I was involved in meetings but I’m not sure I can remember –
Mr Blake: If we go to –
Stephen Muchow: They were very dry meetings!
Mr Blake: Page 7 of that agreement is schedule 1 and it concerns Helpdesk improvements.
Stephen Muchow: Yes.
Mr Blake: Do you remember Helpdesk improvements being a significant part of that agreement?
Stephen Muchow: Oh, yes, yes.
Mr Blake: If we look at, for example, “Call Scripts”, it says there:
“The Contractor and POCL agree that separate call scripts shall be introduced to be followed by Helpdesk staff in relation to:
“out-of-hours stock units … and
“discrepancies and dealing with reversals and suspense accounts.”
Those were the two concerns that we spoke about just before –
Stephen Muchow: That’s what we were discussing earlier. Yes, it is, yes.
Mr Blake: If we look at –
Stephen Muchow: I mean, we drafted them and, as this says, POCL reviewed them and said they were okay or not.
Mr Blake: Can we look at page 9, please. It goes through other agreed improvements and one of them is the “Horizon Guide to Balancing”, and it says:
“The Contractor shall review all cash account scripts in use at the date of this Agreement and shall ensure that they are consistent with the guide produced by POCL (and provided to the Contractor prior to the date of this Agreement) called ‘Balancing with Horizon’.”
Stephen Muchow: Yes.
Mr Blake: Is that something you remember?
Stephen Muchow: Yes. I don’t remember the content of it but I remember that specifically because what we wanted to do was “To get a definitive statement, this is what you should be doing”, and that’s what we hoped Post Office provided.
Mr Blake: This was all shortly before the national rollout resumed on 24 January. What do you recall of the Post Office’s attitude towards those kinds of issues, the Helpdesk issues and the issues that you were involved in?
Stephen Muchow: Well, Post Office’s attitude was always one of getting the best for Post Office from the contract. I mean, these guys were quite good at driving a hard bargain. It was my job to staff up the people and manage the information, management information, which enabled us to see how well we were doing and to persuade Post Office because – of how well we were doing because in that distillation of information resided the reward. I mean, we were paid a sum of money but then we had to give back for all of the failures that we had and so it was in Post Office’s interest to make sure that they were very well documented on what we had to do and that they were assured that when we said we had done something, that it had been done because, if we hadn’t done it, then we would owe them some money.
I think it’s a typical contractual relationship.
Mr Blake: We’ve seen there, in terms of required Helpdesk improvements, focus on discrepancies and focus on balancing.
Stephen Muchow: Yes.
Mr Blake: Were those issues quite prominent issues in your discussions?
Stephen Muchow: I think particularly on balancing, yes. Balancing was a big issue. Cash account discrepancies, a big issue. I cannot imagine – I mean, the whole business revolved around selling products for themselves and for other of their clients and they had to level up, they had to settle up at the end of the month, or whenever, and so it was important that the information was correct.
Mr Blake: What was the atmosphere like? Was there anger, upset?
Stephen Muchow: No, no. I mean, I think irritation sometimes but I think we tried to do business in a professional way. We didn’t fall out about it. But we didn’t get our own way and we had to fight for every improvement that we thought we’d made.
There were things, for instance, that the Post Office did that made life difficult for us. I mean, consider reference data. If you issue reference data to the post offices and say that 10 penny stamp has changed to become a 10 penny stamp, and that’s what happened. So there was huge volumes of reference data that we had to process unnecessarily and that degraded our performance capability and we possibly hadn’t allowed for that level of work in our assumptions of the volumes early on when we struck the contract.
So, yes, there were – there was some give and take to be had pointing these anomalies out and trying to do a quid pro quo, I guess.
Mr Blake: I’m going to go on to talk about technical issues, software issues with Horizon. Was the link ever drawn between these issues that postmasters were having and the Post Office was recognising on the Helpdesk, insofar as balancing is concerned and technical issues –
Stephen Muchow: Yes, they – that’s why they took to insisting on the new scripts, validating those scripts and recording the conversations. So, yes.
Mr Blake: Were those aimed at improving the way in which a postmaster would go about using the system or were they aimed at identifying actual technical problems with the system itself?
Stephen Muchow: I don’t think the postmaster can do any more than follow his instructions and, when things go wrong, report a problem and that problem to be escalated through the support chain to – eventually to become an incident which is recorded on PinICL and then resolved by a software change. Hopefully, there might have been a workaround to mitigate his situation at the time and to keep things moving but I don’t think that the postmaster could have done any more than that.
Mr Blake: As the person who was responsible for the Helpdesk, you were seeing these workarounds for example, being put in place and you, at the same time, were being blamed for failing to meet certain objectives.
Was there ever a thought in your head that actually the problem is the software, rather than the Helpdesk?
Stephen Muchow: When the problem was the Helpdesk, I sorted out the Helpdesk – well, except I didn’t. I sorted out the contractor for the Helpdesk. When the problem was the software, then we sorted out the software.
There was no problem within Pathway between customer service and development identifying problems. All developers want their products to be as good as they can be. It would be lovely to have – impossible but it would be nice to think that one day there would be no need for a Helpdesk. You know, that things don’t go wrong but they did and they will and they continue to go wrong.
Mr Blake: So was it always envisaged that there would be these software issues and that was the purpose of the Helpdesk?
Stephen Muchow: No, the purpose of the Helpdesk was to help the postmaster operate the system. It also – I mean, to capture complaints to – whatever call came in – it could have been a member of the public in the early days with the Benefits Encashment Service. A member of the public could call the Helpdesk and say that they had not been able to pick up their Benefit Payment Card or whatever.
So it was the first point of contact to gather together all the things that were wrong, as perceived by the operators of the system, the postmasters, the members of the public, the users, and we occasionally got calls from Post Office as well. Anybody could call the Helpdesk. It was a published number.
The filtration of those things and the distillation into specific problems that were capable of being fixed by changing the software was the job of the System Support Centre and development and the test teams. We had test rigs in the SSC that could reproduce the fault. If we could reproduce the fault we were happy because then we could show concrete evidence to development, “Here, chum, you’ve got a problem here, fix it”, and that was always the best way.
The intractable problems the ones where we couldn’t reproduce it. I’ll give you an example. On communications faults, there were several occasions when comms would go down and miraculously return; nobody had done anything. So it was – it’s an amalgam of skills and effort and expertise to try and resolve issues and get them fixed as soon as we can. You can’t simply fix it in the Post Office at the time because it’s an estate and you have to do a rollout.
We did occasionally put a fix to a specific post office but then that would have been overwritten by the next – that would be there to say “Did this actually cure the fault as seen by the postmaster?” But that then would have to be incorporated into a change, a new release – a maintenance release or a new release to affect the whole estate.
Mr Blake: Can I ask you how that happened. So to an individual terminal, for example –
Stephen Muchow: To an individual?
Mr Blake: Terminal.
Stephen Muchow: Terminal.
Mr Blake: How would you go about making that fix?
Stephen Muchow: Well, there wouldn’t be – this is a bit technical for me but there wouldn’t be an individual terminal except in single-counter offices where we had then an extra disk which effectively – because we always had a backup of the message store and then there was a copy on the correspondence server in our data centre.
So we would have to make a connection and, on occasion, particularly, say, for instance, when we had a communications fault, we would open the connection from the data centre and keep it open, so that we could put down a fix to the PC, which was the counter and if it were a multi-counter office that would then be replicated – I can’t remember the term but it would be propagated to all of the counters in that post office and –
Mr Blake: Who would do that? Who was responsible for doing that task?
Stephen Muchow: The only people that could do that would be the SSC and development working together.
Mr Blake: Could they do that to, for example, a cash account?
Stephen Muchow: In what way?
Mr Blake: Could they implement a fix that might impact on the cash account to a single post office?
Stephen Muchow: Yes and no. They could make a change to – a balancing change but it would be a new transaction. It wouldn’t be – I don’t believe they could alter a transaction. They could put in a new transaction. So, for instance, there was – how can I put it?
I’m just running out of my comfort zone here but I think, if there was an imbalance, they could insert a balancing sum to correct that so that the postmaster could rollover to the next cash account period and carry on work. I mean, this was a requirement because, otherwise, he would be stuck. He couldn’t do any business. And we would do that with the knowledge of Post Office, with the NBSC, that that’s what we were doing.
In fact, I think they had to agree that process because Chesterfield had – I can’t remember the name of it. Is it TPS? Transaction … there’s a –
Mr Blake: TIP?
Stephen Muchow: TIP, maybe it’s TIP. There was a Post Office Counters Limited system that would read in all the transactions and it would get one which would – we had to tell them why we’d done that. So I think that’s how it worked, yes. Yes.
Mr Blake: I’m going to ask you about technical issues now, insofar as you’re able to. You have addressed incomplete transactions in your witness statement and we’ll briefly look at those. Can we look at POL00028100, please.
Sir, before I move on, is there anything that you wanted to ask in relation to that access point?
Sir Wyn Williams: No, thank you. But since we’ve got this very short break in your line of questioning, in about ten minutes could you engineer a short break for me, please?
Mr Blake: We will take a ten-minute break today if that is sufficient.
Sir Wyn Williams: Yes, that’s fine.
Mr Blake: Can we look at page 146 of this document, please. So we’re moving back in time now to 1998, I’m afraid, and this is a time when the Benefits Agency was still very much involved. You’ll see this is a letter to Mr Vince Gaskell of the CAPS programme and it’s a letter from yourself dated 15 September.
Stephen Muchow: Yes, I remember this.
Mr Blake: I’m just going to read that final paragraph. It says:
“You may note that as overall transaction rates increased, the problem diminished. In August, the success rate was 99.98% – with less than 3 transactions per 10,000 being incomplete.”
Do you remember approximately how many transactions might take place in a day or a week or …
Stephen Muchow: No, I’m sorry, not offhand, no.
Mr Blake: “Our target is to continue to reduce the number of incomplete transactions towards zero and we are confident that where the cause is a systematic error or where a systematic preventative measure can be devised then this will be achieved.”
You said there “towards zero” and that’s an important point that you raised in your evidence earlier, that you will not get to zero; your aim is to go towards zero. Have I understood your evidence correctly?
Stephen Muchow: Absolutely, yes.
Mr Blake: “There will always remain a residual ‘human element’ for which there is no ready answer except that with increasing experience of the behaviour of our end-user community we will be able to reinforce the application of correct operational procedures through focused feedback and transaction re-engineering.”
Stephen Muchow: Yes.
Mr Blake: Can you tell us a little bit about that and what you meant by that?
Stephen Muchow: Yes. This was very dear to my heart.
What I was striving for was, if you like, hostile testing. Human beings don’t always do what they’re told to do and programmers always – well, they are supposed to – always do what their specification says they must do. So when a program is written to say “Take the numbers out of these three boxes, add them together and give me the sum”, it expects them to fill in three boxes. Now, imagine one of those things was “Divide by this number” and they’d not filled in that but divided – and left it as zero, we would have ended up with divide by zero.
It’s something that we didn’t expect because it wasn’t written in, it’s not a specification for what to do, it’s a lack of a specification of what not to do.
So it’s – all we can do is anticipate what sort of anomalies might be introduced by the human operation of these systems (and we’re all human, we all make mistakes, we all type things in in the wrong boxes now and again) and I wanted the system to not fall over in a flap when that happens. And if it’s a ridiculous answer, for instance, if it divides by zero and creates an infinity number, then, you know, I don’t want the balance to say infinity because that’s – I’m not saying that’s what happened. This was something that we tried to get across particularly in the contractual discussions with Post Office about setting targets that were literally never going to be achieved and what’s the point of doing that?
So, as I say, there’s a – it’s like an exponential curve. It approaches zero. You may have periods of months and months and months with no errors at all and think, yes, we’ve cracked it, but then a spate crops up. So that’s what it was about.
Mr Blake: You refer there to the human element.
Stephen Muchow: Yes.
Mr Blake: Is it just the human element –
Stephen Muchow: No –
Mr Blake: – that might not make it zero or were there –
Stephen Muchow: No. As I said, the human element is that it may have been coded incorrectly.
Mr Blake: Yes.
Stephen Muchow: Where human beings are involved, there’s always going to be errors.
Mr Blake: Thank you. Sir, might that be the appropriate moment to take the ten-minute break? So if we come back at 20 past?
Sir Wyn Williams: Yes, that will be fine.
Mr Blake: Thank you very much.
(2.12 pm)
(A short break)
(2.22 pm)
Mr Blake: Thank you, sir. We are back.
Sir Wyn Williams: Very good. Thank you.
Mr Blake: Can I bring up on to screen POL00090428, please. This is a very long second supplemental agreement. I’m only going to take you to one page. But is that a document that you were familiar with at the time, the second supplemental agreement?
Stephen Muchow: I think there was a third as well.
Mr Blake: Yes. Was it something that you played a part in?
Stephen Muchow: I might have done if there were changes to requirements.
Mr Blake: Can we look at page 21. This addresses the TIP interface and I’m just going to read to you that first paragraph. It says:
“during the period from 3rd October 1999 until 14th November 1999, the percentage of Cash Accounts received by POCL across the TIP Interface containing Cash Account Discrepancies shall not exceed 0.6 per cent of all such Cash Accounts.”
Is that the kind of thing that you were talking about before when you say you can never get to zero so you need to be somewhere above zero?
Stephen Muchow: Well, it’s one example, yes, but even before Horizon, I remember there was a huge department in Chesterfield – I think there were about 400 staff there – who were trying to resolve issues with the old-fashioned paper account – cash account. So, yes, I mean, Post Office had to reduce the cost of that activity and hopefully Horizon would have helped them by eliminating a lot of those faults but, clearly, they anticipated them still being there and 0.6 per cent, I think, is still quite a large number of faults to get through.
Mr Blake: Was that an acceptance that there would be discrepancies in the cash account going forward, irrespective of how hard either side tried?
Stephen Muchow: Well, I can’t speak – I’m pretty sure that it was, yes. I can’t speak for what they actually felt. I mean, they had aspirations of it being zero. They were running a business and if they could do without some costs then all to the good.
If it minimised their expenses on dealing with these discrepancies, then, yes. But 0.6 per cent is still a substantial number I would think.
Mr Blake: I’m going to move to issues post rollout. Can we look at POL00029158, please. This is “Service Review – Performance Statistics” for January 2000. It’s dated 7 February 2000 in the top right-hand corner.
Stephen Muchow: Yes.
Mr Blake: You were on the distribution list and you are named as the approval authority.
Stephen Muchow: Yes.
Mr Blake: Can you tell us what were service review performance statistics or what was a service review?
Stephen Muchow: Well, if it moved you measured it and I think you see in the next few pages these and …
Mr Blake: The names there, are they all ICL or Pathway names?
Stephen Muchow: They are all my team.
Mr Blake: They are all your team?
Stephen Muchow: Apart from Tony, who’s contracts director, finance director.
Mr Blake: Would this kind of a document have been shared with, for example, the Post Office?
Stephen Muchow: Not in this form, I don’t believe. Oh, it might have done with service management review forum, yes, maybe.
Mr Blake: Can you expand upon that? Why is the service management review forum there? What did that mean?
Stephen Muchow: Well, when we – we would share our performance with them and they would have to agree and so, yes, it would be shared.
I’m not sure whether this document was the one that was shared or whether there was something a little more elaborate.
Mr Blake: Who formed part of the service management review forum? I don’t need names necessarily.
Stephen Muchow: Well, I think – well, Andy Radka’s name and Ruth Holleran’s name come to mind with me and my team, particularly Richard Brunskill, who was instrumental in doing many of these analyses, and Peter Robinson who designed a lot them as well.
Mr Blake: Can we turn to page 7, please.
Stephen Muchow: I think –
Mr Blake: Page 7 is the management summary. Sorry, did you want to say something else?
Stephen Muchow: No.
Mr Blake: This is the management summary. If we look that top, we have there the date of 31 January 2000, 2,000 live outlets and 4,485 operational counters. I’m just going to read to you a few passages from there. So it starts:
“As National Rollout recommenced in January, there were 2,000 Outlets in Live operation by the end of the month. However, despite the increased number of Outlets, there was a reduction in the total number of calls logged with the HSH (7,017 calls in Jan 2000 as compared with 7,556 calls in Dec 1999). This in turn caused the ratio of calls per Outlet to drop to 3.5 in January, compared with 4.1 in December 1999.”
Then it goes on to talk about certain issues and I’m going to start with the BT bills issue. It says there:
“On 27th January a large number of incidents were raised because BT Bills could not be scanned. This was the result of a Reference Data Process fail and a subsequent overrun during the previous night.
“This particular problem was resolved by advising counters of a workaround and transmitting the missing Reference data later that day.”
So pausing there, you have mentioned issues with reference data. Can you briefly tell us what kinds of issues you had with reference data and whether this is typical or not.
Stephen Muchow: Well, it’s one of many different problems. Reference data is the heart of the configuration of Horizon’s system. It basically says what can be sold, where and when and what the parameters of that sale might be, for instance the price of stamps, and so on. For instance, not every post office could sell – not every post office could do a passport, for instance, and so there would be reference data that pertained to that particular post office and sometimes there are quite a number of errors in the reference data.
Mr Blake: Who provided the reference data?
Stephen Muchow: The reference data came directly from Post Office Counters Limited.
Mr Blake: There’s a reference there to workaround for the time being until it was resolved. Were workarounds quite common scenarios?
Stephen Muchow: It’s a word – it’s a term that’s used quite loosely. It means “How do you get over this problem for the minute”, and I don’t know of any specific examples. So I’m only guessing, really, but if there were one type of transaction and it was similar to another type of transaction and you had the reference data for one and not the other, you could say to Chesterfield “How about calling it this transaction so they can perform the role but, in fact, it’s one of these”.
I don’t know if that’s a good example. But workarounds, generally speaking, were not what we were looking for. We were looking for corrections to the reference data. But that meant it had to go through a lot of testing and it could have been a – it could have been a delay that Post Office would not have liked, because of the inability to transact that type of product and that meant a loss of business to the Post Office, to the postmaster and, potentially, to the client as well.
Mr Blake: Thank you. Then it goes on to refer to an issue with blue screens and you have talked about blue screens already.
Stephen Muchow: Yes.
Mr Blake: Then we have “Girobank transaction report”. Could we highlight that, please, or blow it up a little so it’s a bit bigger. It says:
“A report fix was delivered to 1,100 Counters which caused the following scenario to occur in a number of Outlets who were attempting to reverse a transaction. When a transaction was reversed, on a lower numbered Counter node, there was no evidence on the Girobank summary that this reversal had taken place, although the correct information did go to POCL TIP. Some Outlets realised this to be the case and altered the Girobank summary to reflect the correct transactions. Some Outlets however, completed the reversal again, which resulted in a discrepancy for the value of this reversal. MSU have advised POCL of all Outlets where we know a problem has occurred (after calls were received by the HSH) and a fix was delivered to the affected Counters on 31st the problem with Giro reports on 26th January.”
Is that something you remember or are you able to assist us with that?
Stephen Muchow: No. I can’t remember the specifics but I do know that it was important that TIP had the transactions in the right sequence and the right counter. So it may have been there case, for instance, that they tried to do the reversal on counter number 3 when it was performed originally on counter number 4 but counter number 4 had failed. Maybe it had a disk error or something, so you have lost a counter or you’ve lost the communications. So they tried to do the reversal somewhere else and I don’t know whether the fault was in TPS or reference data or TIP but that particular impact happened and we discovered it.
Mr Blake: So we have here, on the page before – we don’t need to turn back to the page – but it says “operational counters by that stage 4,485”, and it said that a fix has been delivered to 1,100 counters. Then we look on this page and it says “MSU have advised POCL of all Outlets where we know a problem has occurred”.
Now, are you able to assist: would the fixes occur just to those that you knew occurred, so only a quarter, let’s say, of these counters have been fixed, is that because a quarter would have complained to the MSU or –
Stephen Muchow: I really don’t know.
Mr Blake: I mean, let’s say that a subpostmaster hadn’t called the Helpdesk because they hadn’t realised that there was a problem. Typically, would they receive the fix or, typically, would the fix go to those who had raised the issue with the Helpdesk?
Stephen Muchow: They would eventually receive the fix. I think what would happen is that the Helpdesk would recognise when this had occurred but, if the postmaster hadn’t reported the problem, then the Helpdesk would have no record of that and they would not receive the fix until the next maintenance release was distributed to the estate in general. But where this had happened, then what we’re trying to do is correct a discrepancy and – so that that fix would have been delivered to those post offices. But there may well have been other post offices where they failed to – sorry, not failed. It’s not – where they hadn’t reported it and so they would suffer for that.
Mr Blake: How would that process work? In terms of would the Helpdesk gather names of post offices or was there some other kind of process to notify those who were providing the fixes of the affected post offices?
Stephen Muchow: As far as I recall, what would happen is that this would be a pattern developing and the pattern developing would clang the bell of the SSC who would look at it and raise the PinICL and either establish the workaround in conjunction with development and apply it, apply the fix, but I don’t – it’s not something – not everybody dealt with these things society, so it was not something that you would blanket apply. It’s not a sticking plaster for everybody. It’s just for this specific thing.
Mr Blake: You mentioned earlier that the third level of support weren’t great when it came to this like balancing or –
Stephen Muchow: Initially, they didn’t have any experience of it. I mean, all they had was what they had learned from going on the course with – they received the course from Peritas and I think they may have even visited some post offices. At one stage we had an adopt a post office, so they would go through the process with them.
But they were not experts in balancing to the Post Office’s rules.
Mr Blake: Would they have the expertise to understand and spot those kinds of trends that you’ve talked about?
Stephen Muchow: Yes, because they had an impact. There was something – there was a signal that something had gone wrong and that is something they can focus on and then find out why and what needs to be done to correct it.
Mr Blake: Can we go to FUJ00079350. This is a “Live System Performance Report” for February 2000 so, again, it’s after the rollout or after the rollout has resumed. You are a recipient of this document.
Stephen Muchow: Yes.
Mr Blake: Can we look at page 9, please. There are various issues that are mentioned throughout this document. I’m going to take you to them. Here we just have one, which says:
“Network – Two periods very long calls have been experienced on the ISDN network. Mitigating actions have been put in place whilst the Riposte bug is resolved.”
Stephen Muchow: Yes.
Mr Blake: Are you aware of what that’s a reference to?
Stephen Muchow: Not specifically. ISDN was not my favourite network protocol.
Mr Blake: The reference to a Riposte bug there, were bugs with Riposte common?
Stephen Muchow: Oh, yes, as common as with any other software, yes.
Mr Blake: Were they more common with Riposte? Was there a particular problem with Riposte?
Stephen Muchow: I have to be a little guarded here, not because I wish to conceal anything but because I wish to be fair to other people’s software. If I can’t see the code, I’m always upset. I can’t – I don’t like not knowing what’s going on and when – if it’s in – like with Windows NT, the famous blue screen problem, we didn’t have access to Microsoft’s code to go and fix it.
We didn’t have access to this code to fix it. We had to work through the reporting process, register a fault, get Riposte to work it into their busy schedule and wait for it to be tested, come back, test it again and deploy it. That was always an element of delay that doesn’t help anybody. So …
Mr Blake: Can we look at page 46 of the same document, please. If we scroll down, it says:
“Riposte System Messages
“The number of messages generated by Riposte functions eg:
“Log on/log off
“End of day reports
“Session transfers
“etc
“is significantly greater than the prediction which was based on the CSR(NR2) Live Trial system. The prediction was that 200 messages per counter per day would be generated. Data from the live system indicates that the number currently exceeds 500 per counter per day.”
Is this something you are able to assist us with at all as to what that means?
Stephen Muchow: I’m afraid not. I think you might be better to talk to the development team on that.
Mr Blake: Scrolling down, “User Lock Requests”. It says:
“CPs to remove unnecessary messages are being raised starting with CP2253 which significantly reduces the number of User_Lock_Requests generated by the counter. This will both reduce the number of messages in the message store and significantly reduce the load on the Persistent Object Index …”
I mean, this is all quite technical but is that something you recall?
Stephen Muchow: It sounds like – I do recall something like this when – the “lock” is only requiring if you are going to write. What’s you’re locking is the data from being changed whilst it’s in use but if you are reading it, you needn’t lock it. If it’s locked because somebody might be changing it then, fine, you have to wait for the lock to be released. But I think there were – there was a criticism that they were locking everything and that created too many requests.
Mr Blake: Riposte is mentioned there and we’re also going to talk about the EPOSS system. You laugh –
Stephen Muchow: No, I’m not laughing.
Mr Blake: Perhaps you can –
Stephen Muchow: I’m holding back a tear.
Mr Blake: I’d like to talk about your instinct on the mention of EPOSS then. Can you tell us what was the reputation of EPOSS in the office?
Stephen Muchow: It’s – I think there are too many young people in the room, actually. EPOSS was never an ideal system.
I’m sure it worked well in places where it was designed for smaller numbers but I think it had – we had too many bugs with EPOSS. It just – I can’t remember a time when EPOSS was the darling of the family. It was always a problem.
Mr Blake: And –
Stephen Muchow: I mean, there was a time when we were thinking about rewriting it completely but it’s – there was a system that post offices used, which I can’t remember the name, but it was developed, I think, by an ex-postmaster – I’m sure somebody will know him.
Mr Blake: Is this the something Jackson?
Stephen Muchow: Oh, that’s it, Jackson. Now that seemed to work and had the support of quite a lot of postmasters but we had Riposte, and that was – we had either to integrate with Riposte or completely change. Now, if we completely changed we’d change everything and I don’t think that was either in Post Office’s interest or in our interest. What we had to do was work with Escher and try and come up with a Riposte solution by them, which met the requirements and I’m not sure it was ever wholly successful, and I’m pretty sure that the next generation Horizon or Horizon Online changed that.
Mr Blake: How widely held was your view, that view that you just expressed to us, of EPOSS effectively not being fit?
Stephen Muchow: I didn’t say that.
Mr Blake: No, well, that’s why I used the word “effectively”. Please do –
Stephen Muchow: No – hm. I can only measure it by “Does it make my life simpler or more difficult”, and it always made my life more difficult. So I was never happy with it. It was a very complicated system on which to – we talked a moment ago about reference data and reference data being very specific about Post Office’s products’ price, and so on, circumstances in which those things can be traded. To build that in to something which was designed for – I think, An Post in Ireland used it but were they anything like Royal Mail, you know, Post Office Counters Limited? I don’t think so.
So it was always adapting and it was possibly – I don’t know whether we were big enough to warrant the attention from Escher.
You know, they had tremendous ambitions around the globe for this Post Office system. So I don’t know.
Mr Blake: I will return shortly to EPOSS and some correspondence between yourself and Terry Austin but, before I do that, can we just look at FUJ00058190. This is the ICL Pathway monthly report for February 2000 and it’s page 24 that I would like to look at. I am just going to read to you that second bullet point under “Acceptance Loose Ends”, so if we could scroll down slightly and just highlight that second bullet point. It says:
“We have dealt with queries from POCL concerning [Acceptance Incident] 376. 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.”
In Phase 2 we were told by Terry Austin that he thought that you had written that particular paragraph or at least had provided that content; is that right?
Stephen Muchow: No, I think it was John Dicks.
Mr Blake: Is it something that you – I mean, it refers there to “CS”, so customer service.
Stephen Muchow: Yes. Well, CS would be the ones charged with spotting the incident and if we couldn’t spot it, then we’d be – we would certainly be hampered.
Mr Blake: Is it a concern that you recall or something that you’re able to assist us with?
Stephen Muchow: No, I’m afraid not. Could I look at the rest of this document?
Mr Blake: Yes, absolutely if we can –
Stephen Muchow: Where is it? Is it in –
Mr Blake: If you would like the hard copy, it is your D18.
Stephen Muchow: D18.
Mr Blake: It may be better – we can come back to it at the end, if that helps.
Stephen Muchow: Just scroll on the screen would be fine.
Mr Blake: Where would you like: above, below?
Stephen Muchow: Well, start from the top. I’ll just have a look. Yes, this is – I could not possibly have written this because this is written by John Dicks, it’s “Customer Requirements Monthly Report”. Well, he wrote his own reports. I wrote the customer service monthly report.
Mr Blake: Thank you very much for clarifying that. In relation to the issue that it raises, is that something you remember: issue spotting incidents?
Stephen Muchow: Well, John was always very sympathetic to the problems that we face. I mean, we were working, really, with one hand tied behind our backs, really, because we – we can’t see what’s not reported and there could well be problems, I’m sure there are problems, even today, that have not been discovered yet. There are always bugs. So I think he was being sympathetic to – trying to stop people saying “Well, customer service should have spotted it” and, in fact, we probably couldn’t have spotted it but …
Mr Blake: Is that because you were reliant on people calling the Helpdesk to say “I’ve got a problem”, or it’s something more than that?
Stephen Muchow: No, I think it starts with that and then it’s a question of understanding in the system and if these were in Riposte then it’s over the Atlantic and trying to get them to explain what went wrong.
Mr Blake: Can we look at FUJ00079333, please. This is the correspondence between yourself and Terry Austin in April 2000.
Stephen Muchow: Yes.
Mr Blake: Perhaps we should start from the second page and if we zoom out there’s an email to yourself and others from somebody called Pat Lywood. Could you tell us who Pat Lywood was?
Stephen Muchow: She’s my Rottweiler. She was, I think, the epitome of defending the product, defending the user, defending customer service. She was wonderful at getting to the bottom of problems. I remember going through a session one evening when she said “I’m not going to be beaten by this bleep, bleep piece of tin”, and it was when we were trying to get the – it’s the blue screen problem and some other problems to do with the counter terminal equipment. But, no, she was tenacious in her job.
Mr Blake: So she would identify for you –
Stephen Muchow: Yes.
Mr Blake: – technical issues with Horizon?
Stephen Muchow: Indeed, yes.
Mr Blake: Were you her line manager or did she report to you?
Stephen Muchow: No, she reported in to the SSC and in to – in to the SSC.
Mr Blake: Who, other than yourself, would she routinely express those kinds of concerns to?
Stephen Muchow: Oh, to Mik Peach, to Peter Jeram, to Terry Austin, to me. Pat would make sure that we knew when there was a problem.
Mr Blake: This correspondence that you’ve recently seen is concerning the CI4 implementation, which was an intended improvement to the EPOSS system. Is that something that you remember?
Stephen Muchow: I don’t remember the specifics of what was in it but I do remember CI3, CI4.
Mr Blake: She says there:
“All,
“The following details were supplied by Phil Hemmingway …”
Do you remember Phil Hemmingway?
Stephen Muchow: No.
Mr Blake: “… at a CI4 implementation meeting on 26th April. This email details the current issues of which Phil is aware.”
She raises a number of issues. Towards the bottom there we see “Performance issue”, and then we see “Risk of code regression”. It says in relation to code regression:
“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”, et cetera.
Stephen Muchow: Yes.
Mr Blake: If we go to the page before, there’s an email from yourself passing up concerns to Mike Coombs and Terry Austin. If we look that bottom of that page, you say:
“Mike/Terry,
“Please see below, report from Pay Lywood on CI4 implementation.
“I am particularly concerned with the risks of degraded counter and cash account performance and of code regression between CI3 and CI4. Also, given the dependence on [Post Office] Backfill Training but without the benefit of the experience of PONU’s track record on this activity – there must be significantly increased risk that HSH performance against SLAs will be severely impaired.”
There are a few concerns you raise there. Can you just take us through each one of those, please.
Stephen Muchow: Okay. So CI3 to CI4. PinICLs that had been included in CI3, if they had not gone forward to CI4, then we might expect to have problems recur that we had thought we had fixed and that is, you know, very bad.
The changes – there were some changes, I believe, to the cash account without the benefit of Post Office Network’s track record on this activity, Helpdesk performance against SLAs will be impaired. Yes, I can’t remember what specifically they were but does it not say over the page?
Mr Blake: Over the page, the original email? Yes. The performance issues are slightly further down, if that assists?
Stephen Muchow: Wait for a moment. So we’ve got a new process introduced to the cash account process, every office will be required to declare non-value stock. The backfill training had to be done by Post Office, I believe. If they don’t do it, then he won’t be able to balance or complete the cash account.
Length of time to do cash account was always an issue. I mean, postmasters used to spend an inordinate amount of time, late into the night, to try to get the system to balance.
I think all this is saying, Mr Blake, is that I was simply responding to my team’s nervousness about what had been produced for CI4 and that it wasn’t what we expected and we wanted to make sure that development and the programme team knew about it. We weren’t going to just sit there and allow it to happen both to us and to the Post Office.
Mr Blake: If we look at the page before and the bottom, your email, the particular concern that you raise about code regression, can you tell us a little bit more about that?
Stephen Muchow: Well, regression, there are two forms of regression. One is that you introduce problems that weren’t there in the first place because you’ve made so many modifications. Secondly, you don’t include fixes that you have already tried and applied to the earlier release and they’ve been missed out. So, for instance, if there’s – there’s a first release and then there’s a maintenance release with some of these things in and then, if the subsequent release – real release, not a maintenance release – doesn’t include the fixes that maintenance release had, then you have regressed. So that’s what I mean by regression.
Mr Blake: Were you aware, I think you have mentioned something of it in your evidence already, that in 1998 there was a proposal – an EPOSS PinICL Task Force, which raised serious concerns about, for example, the code within the EPOSS system?
Stephen Muchow: Yes, I’m aware of it.
Mr Blake: Were you aware of it at this time?
Stephen Muchow: Yes.
Mr Blake: If we look at Terry Austin’s reply that is dated 10 May. Can we scroll up slightly. Thank you very much.
I’ll just read to you briefly from that. It says at the beginning:
“Steve, I share your concerns regarding counter performance and code regression.”
He goes on in the next paragraph to say:
“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.
“I also have no faith in PO backfill training …”
Pausing there, can you just tell us what that meant, the Post Office backfill training? I know you briefly touched on it.
Stephen Muchow: Post Office backfill training, I believe, was what we gave to the Helpdesk staff and to the Post – well, to the Post Office staff to make them aware of how the system would deal with new features or changed features. So it was backfilling the training they’d already received. So it’s new stuff basically and … I don’t think that Post Office were very good at getting that across.
Mr Blake: Thank you.
Mr Austin’s reply went to a number of people. One of those was Gareth Jenkins. Is that somebody that you were aware of?
Stephen Muchow: No, Gareth was – I think he was part of a Kidsgrove group, sort of architect types. I may have met him but I don’t know him.
Mr Blake: Thank you.
Were you aware that on that same day, 10 May 2000, Mr Austin sent a response which confirmed that – it recorded that a decision had been taken not to rewrite the EPOSS system?
Stephen Muchow: I’m not aware on which day that was, no.
Mr Blake: On the same day. Let me take you to that. WITN04600104 and it’s page 10. So if we look at the response to you about code regression, et cetera, was 10 May and then if we look at page 10 of this document, so it’s the page before, there’s an email there. I think you’ve seen the evidence of Mr Holmes, haven’t you, and I think this is a document that was brought up on screen for Mr Holmes, but if we can focus on the right-hand side, and – sorry?
Stephen Muchow: Keeping his options open, isn’t he?
Mr Blake: This concerns the rewrite of the EPOSS system and, actually, it is the next page. It’s the top of the next page, which is the final – that’s page 9, yes, so if we go over the page to page 10. So there we have 10 May, so the same date that email was sent to you, and it says:
“Following response received from [that’s Mr Coombs] …”
Stephen Muchow: Yes.
Mr Blake: “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 CI4 codeset into live usage in the network. PJ [that’s Mr Jeram, I believe] can we make sure this is [significantly] covered in our reviews of the B&TC test cycles.”
Do you remember this at all? Were you consulted as to the closing of the recommendation to rewrite the EPOSS system, rewrite and redesign the EPOSS system?
Stephen Muchow: I remember the decision was that we were going to press on regardless because the alternative was too expensive and would have created huge delay in the programme, in which case let me put my hand up to be the sacrificial lamb and me and my team would have to battle through the problems and cope with it. But I think Terry was between a rock and a hard place there. He didn’t – he really had a very, very difficult choice to make between proceeding with what we had or starting from scratch and, if you start from scratch, then. The further ramifications of that change, I think, would be unconscionable.
I mean, as a management team, this was the accepted approach.
Mr Blake: The reference there to a management team, Terry Austin was asked about who would make up the management team and he gave your name as part of that management team. Did you have a role in that particular decision? Do you recall having a role in that particular decision?
Stephen Muchow: No.
Mr Blake: Do you think you were part of the management team so described in that correspondence?
Stephen Muchow: Yes, I was part of the management team. We were – the managers were all part of the management team. As I explained earlier, we had our blinkered view. It’s not entirely blinkered. We did see sideways a little but we were focused on what our responsibilities were and to try and do the best in that – this was not – we didn’t have the luxury of trying to create something in advance of trying to sell it. This had been sold and agreed, the Post Office had requirements, we had agreed to meet those requirements and we had an issue here of whether we stick with the product we had and try and make it work or ditch it at great expense and start again, and who knows what other consequences there might be.
So even if I disagreed with it, and I probably did, and you know I did from the point of view me raising the issues earlier, the team decision was that we had to proceed with EPOSS. I mean, they did change the approach. It was called Rapid Application Development, which was – there weren’t enough exponents of that approach available to us to be able to make that work properly I don’t think. It’s not my department but it’s what I remember.
Mr Blake: So is your recollection that Rapid Application Development had a role in causing the problems with the EPOSS system?
Stephen Muchow: Well, I think it might have delayed the changes we made, ultimately, I think, which was to go back to Riposte – to Escher and get them to make the changes. Rapid Application Development was not new but it was a way of doing things which required you to understand exactly what you were trying to produce, whereas what we had was a customer who decided what they wanted and we had to – we were much better off working from the specification requirements and working through the whole process formally.
But that takes a long time and, having started where we started, I don’t think there was any choice but to proceed.
Mr Blake: Thank you. I’m going to move on slightly in time to May 2000 and can we look at FUJ00003682, please.
These are minutes of the board of ICL Pathway and you’re there in attendance. Would you routinely attend the board?
Stephen Muchow: I attended a few. Particularly now you notice Mr Hirata was there and Kurokawa San. These guys were looking at investing a huge amount in ICL and I think there were some flotation concerns at one point. So they were very keen to make sure that their very – a important project, such as Post Office Counters Limited Horizon, went well and they were very attentive. I was called along to explain how well we were doing or how badly we were doing. It’s always the case.
Mr Blake: I mean, I said moving on in time but, actually, 9 May, so this is just the day before the decision was taken not to rewrite the EPOSS system, or certainly the day before it was communicated to Mr Holmes and others.
Stephen Muchow: I don’t know the significance of that.
Mr Blake: No. Well, the significance is that that’s not mentioned in these board minutes but if we scroll down the focus of the board minutes, or a focus, is on issues with the Helpdesk rather than software issues.
Stephen Muchow: Yes.
Mr Blake: It says there:
“Mr Stares reported the rollout was going very well at more than 300 individual Post Office implementations per week. The principal issues related to Helpdesk and other service issues which were addressed later in the meeting.”
Do you remember that at all, the whole focus being on the Helpdesk? Why was the focus on the Helpdesk at that time?
Stephen Muchow: Because – I mentioned earlier penalties. Penalties were hard-earned money that we had to give to – well, it was deducted from what we would get from Post Office.
Mr Blake: Perhaps if we turn over the page, then, this is the presentation you give – sorry, over the page to page 4. It’s the presentation that you give to the board on service levels and it says:
“The principal issue was that service level agreements were not being met and service activity, particularly on Helpdesks was deteriorating.”
There are mentions here of the red alert and that’s something you mentioned earlier in your evidence.
I’m happy to read you more from there but if you remember, then I’m happy to go with your recollection or allow you some time to just flick through that?
Stephen Muchow: No, I presented the service performance statistics. We in customer services had invested quite a time – a lot of time and effort in looking at the evidence from the systems about how each individual transaction had performed. We were counting how long – you know, counting the time, how long it took to answer calls to fix calls, and so on. So we had quite a range of service level performance statistics, all of which were cash-related. If you don’t achieve this minimal acceptable level then you pay. I can’t remember – there was another calculation for what we would pay and I’m afraid I was firmly on the hook for that one. It was my team that had to improve it, find ways of improving that performance.
Mr Blake: What in particular was the problem at that stage?
Stephen Muchow: Well, the Horizon System Helpdesk. I don’t think we had, as I said in my witness statement, the quality of staff and management in the Helpdesk. They were also remote as well. This is a bit of a lame excuse and forgive me for that but they were not with us in the same sense. I couldn’t walk around the corner and ask them what their problems were. I could go and I did meet them sometimes in the evening when the problems were there, but it felt remote.
I also felt that they were – they could do better. They were performing disappointingly and I don’t think their management team felt proud of what they were doing either. It was just maybe the complexity ty of the product, maybe the complexity of the customer estate to get to grips with but we felt seriously let down on two occasions, to the point where I raised a red alert on ICL Operating Systems Division, and that’s very serious thing to do, because it brings into marked focus the state of affairs in a particular division.
It’s up to that division to get itself out but it puts a great deal of emphasis on every other division in ICL – it’s called the ICL red alert system. It’s probably changed now. But it meant that all other divisions had to offer whatever help they could to recover the situation.
We were losing – we were in danger of not just losing money it was terminating the contracts. That was issue.
Mr Blake: Where, in your view, looking back at it, was the problem? Was it expertise? Was it experience? Was it work commitment? Was it something else?
Stephen Muchow: I don’t know, but I think it would be unfair for me to think that they could become experts. They were expert in dealing with problems to do with PCs and printers, and so on, but when it came to Post Office processes, they are far more intricate and involved than I think we could have expected them to have been familiar with, and it look them some time. I think, ultimately, we lost the contract. I can’t remember. I’d gone by then but I think it went to Atos. Somebody will help me there.
Mr Blake: In terms of burdens, was there too great a burden on the Helpdesk? Were they receiving an unexpected level of calls or calls that related to technical issues of a significant or magnitude that wasn’t expected?
Stephen Muchow: Well, there were periods when – actually, I think you showed a graph earlier where the calls actually reduced quite markedly. We put that down to the counter staff becoming more familiar and experienced in using the equipment and that’s, I think, to be expected. I think – well, I go into my post office regularly and they have no issues in operating it now. It’s very slick.
But how long did it take them to get to that stage of comfort, confidence, ability to be able to perform like that? I think we probably underestimated the time it took them to come up to speed and we certainly underestimated the time it took the Helpdesk staff to come up to speed.
Mr Blake: I’m going to take you quite quickly through the issue of reference data because you have already talked about it but can we look at POL00028564, please.
This was a letter of 28 October 1999 from John Meagher. The complaint there, I can summarise it, I think it’s perhaps the major concern that’s mentioned on the screen there. So there were some concerns about the quality of reference data and it goes on to say:
“… they had a major concern with a fundamental aspect of the reference data design and their ability to support it.”
Is this issue an issue that you recall, October 1999? There’s a reference, if we scroll down the page – sorry – to yourself, a meeting with yourself, Mike Coombs and John Dicks, and it says:
“… and noted the following in addition to the concerns above:
“Pathway are concerned with POCL not maintaining the agreed lead times between receipt of data … and activation of data …
“Pathway are waiting for a Reference Data business rules document …
“… most significant issue for Pathway is that the current design (agreed by all) for the provision of data changes from the Post Office to Pathway results in the delivery of large volumes of data which contain no actual change for Pathway.”
That’s something you mentioned before about it.
Stephen Muchow: I mentioned earlier, yes. Take bullet point number 1 with bullet point 3 for a moment. So the situation was that Post Office would give us a huge amount of reference data that we had to process and a lot of that data was – I don’t like this word but it’s nugatory. It added nothing to the operation. It was simply saying you know – there weren’t changes, they were basically regurgitating the reference data and that meant a huge amount of transmission of data across a pretty shaky network, as it was.
When I say “shaky”, it was ISDN. It was as good as it could be at the time. It’s not nearly as good as you find now with modern internet connections. But, yes, that was …
Mr Blake: What impact would that have on the end user, so the subpostmaster?
Stephen Muchow: Well, if they didn’t have the right reference data they couldn’t sell the product properly. If you update – if you have changed the price of a stamp from 10p to 20p, all you’ve got is 10p in your reference data. You can’t sell those stamps anymore.
Mr Blake: Did the change of reference data or the volume of change have any other impacts that you recall? So would, for example, sending a lot over the ISDN line have other impacts?
Stephen Muchow: No, we had to do that anyway. But if they were to have consolidated it and, if you like, contracted it, zipped it, to the size where only changes were going out, then that would have reduced markedly the volume of data we had to transmit in the timescale, because there had to be – we had to have – there was a lead time that we had agreed between the receipt of the change and the activation of the data. The activation means getting it to the counter and saying “This is now your reference data, so that you don’t look at that table you look at this table”.
So, yes, quite a – I mean, I did have a team of people who were quite dedicated to handling reference data and they worked mainly evening and night-type shifts because that’s when it all happened.
Mr Blake: Can we look at POL00028561. This is a letter from John Dicks, which you’re copied into, to John Meagher on 5 November 1999, and I’m just going to read to you the very final paragraph. It says:
“This experience demonstrates ICL Pathway’s concern that the end-to-end reference data process is not sufficiently robust.”
Was that something that you shared – a concern that you shared at the time?
Stephen Muchow: It wasn’t sufficiently robust, it was distinctly shaky and we needed improvements.
Mr Blake: Did it improve?
Stephen Muchow: I think incrementally, yes, it did and it must have for the system to have worked and to have been finally accepted. But I don’t know the timescales.
Mr Blake: If we look at POL00028552. There appears to have been a reference data review in November 1999. If we go over the page it says there – it explains how the reference data is provided and it expresses there Pathway’s concerns. It says:
“Recently, Pathway have raised concerns that various aspects of the end-to-end reference data process would appear not to be operating as efficiently as they need to in order to support rollout and the ongoing live operation.”
Now, this period is before rollout. In terms of ongoing live operation, do you recall ongoing concerns about reference data?
Stephen Muchow: I can’t remember when concerns about reference data subsided. So I can’t be more explicit than that. I’m sure that – I’m sure there were changes in reference data processes.
Mr Blake: Thank you. If that could be taken down I’m going to move on to an entirely different topic, which is involvement with prosecutions and investigations.
I think it was Jan Holmes’ evidence that in 2001 your department, the customer services department, became responsible for audit extractions. Is that something you remember at all?
Stephen Muchow: Yes. We were – there was – oh, is it a request for information? There was an RFI, I think, process. Post Office would ask us to produce an extraction of data from – I think, from a message store of the correspondence servers and we would do that and package it up and pass it on to them.
Mr Blake: Do you remember why it was your team that was tasked with that?
Stephen Muchow: There was no other team that could do it. I mean – well, development might have been able to do but – no, no, development couldn’t. They didn’t have access to the live system. No, it was only the SSC team that could do that, yes. We set up a special security system – let me think – Jan Holmes actually commented on it. Our security was improved. We had special card access. Even I was not allowed onto the floor – onto the floor where these terminals were.
We had multiple – you had to have two people involved, so it was, I think, Mik, who was the SSC manager. He wanted – I think he said he wanted a developer there as well as the SSC man, so that they could together assure them what they had done was right.
Mr Blake: So who would typically be involved in that process of data extraction for the Post Office?
Stephen Muchow: I think – well, the request for information would come from the Post Office to Martyn Bennett’s team. I’m trying to think of our security manager.
Mr Blake: Graham Hooper, who was –
Stephen Muchow: Graham Hooper was one, yes. There was another guy.
Mr Blake: – security function. Does that ring any bells?
Stephen Muchow: I do remember Graham Hooper. There was another chap who – I can’t remember his name but the security team would receive the request for information and validate it and it would be passed to Mik’s team, not sure whether – it would be Mik probably, and he would assign it to one of his team and somebody else, or to two of his team, or one of his team and the developer, one of the development team, would go and extract the information.
Mr Blake: Were you aware that extracted information was being used for the purpose of prosecutions?
Stephen Muchow: Not while I was there. I did when I heard about this I looked up – one of you gentleman at the front will remind me – Tracy? Who was the first – there was a first lady in the time I was there that had been prosecuted but I’m not aware that any request came through to me or my team to provide that information.
Sir Wyn Williams: It may have been Mrs Pamela Lock. That happened in 2001.
Stephen Muchow: Forgive me, I really don’t know, but I do recall there was one but I don’t know what happened and I didn’t know that they were being prosecuted. But I did know about a request for information.
Mr Blake: Did you have any conversations with the Post Office about their use of data for the purpose of prosecutions?
Stephen Muchow: No.
Mr Blake: Did you ever provide a witness statement for any criminal prosecutions?
Stephen Muchow: No.
Mr Blake: Were you involved in any way in identifying those who were to give witness statements to support the extraction?
Stephen Muchow: Never, no.
Mr Blake: Thank you. I’m very briefly going to take you to a document, FUJ00079790. This concerns the Business Support Unit and the RED Audit. Can you tell us very briefly who the Business Support Unit were. Is that something you recall?
Stephen Muchow: Yes, it was one of Paul Westfield’s team. They provided – they were people who had provided information to management, Post Office or Pathway, about the business. They’d support the business and this particular case is where we had to correct a reconciliation exception database and the BSU operated that.
Mr Blake: What was the purpose of the reconciliation database, the RED?
Stephen Muchow: I can’t remember whether it was – there was a stage where we were responsible for – when I say “we”, Pathway was responsible for some of the errors and had to pay and I may be mistaken but I think it was to do with finding exceptions in the data.
Mr Blake: If we look at page 4, the introduction there may assist. I suppose my simple question is: did this unit have anything to do with the prosecution of subpostmasters relating to discrepancies, so far as you can remember?
Stephen Muchow: I think absolutely not, no. No. This would be more dealing with the Chesterfield team, I believe.
Mr Blake: What do you mean by that, sorry?
Stephen Muchow: Well, where there were errors, reconciliation errors, you had to trace the information back to source and I think that was all part of what happened in Chesterfield with the Post Office.
Mr Blake: Thank you. There’s one final document that I would like to take you to before, I believe, Mr Henry has some questions and that is FUJ00001329. This is Pathway’s release policy. If we look at the abstract, it says:
“This document defines Pathway policy for the identification and planning of new Releases of Software and Data.”
I believe this fell – if we look at page 4, I believe you were listed there as an approval authority for this document. This release policy something you remember at all?
Stephen Muchow: No, it’s not – I’m sure – I mean, it was – in the back of my mind, yes, it’s there, but I can’t remember what went in it. This is what we did, when would we make a release.
Mr Blake: Can I ask you to look at page 3, which concerns the document history, so the way in which this policy was drafted. There are various entries in this document history that relate to comments being applied by Post Office Counters Limited. If we look there at, say, 26 November 1996, 27 November 1996. If we look down to the bottom, version 5.0, it says:
“Amended to reflect comments from Horizon/POCL review.”
To what extent do you recall the Post Office having input into a document such as this, the Pathway release policy?
Stephen Muchow: Well, I think – I seem to recall that Post Office had to approve our releases. I mean, performing a release is no mean thing. It has potential for disruption of the whole estate. So there is a process to go through to: number 1, prove we can put it out there; number 2, prove that it works once it’s got there and it would go through a number of stages to assure both Post Office and Pathway that we were not – you know, it’s do no harm. So these things were quite important.
Mr Blake: So –
Stephen Muchow: It would cover things like when two types of release, a major release and a maintenance release, and the timing between them and the amount of testing and the nature of the testing that would be done. Very, very important.
Mr Blake: So that’s the situation of sharing information with the Post Office when it came to software releases?
Stephen Muchow: Yes.
Mr Blake: We spoke earlier about the Known Error Log. When it came to the minutiae of the detail of errors within the system, that wasn’t something that was interacted in this kind of a way?
Stephen Muchow: Not until – I think the problem there was with PinICL, we couldn’t share the PinICLs with Post Office because of data that was proprietary because I don’t think it was entirely – well, it hasn’t been – it wasn’t for outside consumption.
But PEAK, I believe was. That was – I wasn’t there when they did PEAK but I remember Mick and I think Steve Parker and others were going to, were talking about developing a system which could enable better searching and allowing it to be available to the likes of Post Office.
Mr Blake: So your recollection – it’s not something you were aware of actually happening but your recollection before you left was that they were moving towards a greater sharing of those errors –
Stephen Muchow: Yes, yes. I mean, indeed, we shared the errors verbatim, if you like – what’s the … word-for-word – with them and you’ll see as early as 1998, I think, the CAPS board before Benefits Agency resigned from the programme, there were PinICLs mentioned in there. And wasn’t it about PinICLs I was relating to Vince Gaskell in my memo?
Mr Blake: So some of the content of some of the PinICLs would be relayed to the Post Office but not the PinICLs themselves?
Stephen Muchow: Yes.
Mr Blake: In terms of the Known Error Log, I think your evidence earlier was you’re not aware of there being a formal sharing mechanism, albeit they could have asked for it, I think?
Stephen Muchow: I believe they only had access when they were on-site but they were not denied access, yes.
Mr Blake: Thank you very much. I don’t have any further questions. There are some further questions. Sir, shall we – we potentially have time for a very short break before or we can just continue.
Sir Wyn Williams: I’m obviously anxious about the transcriber, in particular. I think if the questioning is to take longer than, say, about ten minutes we should take a short break. So I’d like some guidance from the questioners.
Mr Henry: Sir, I think if we do therefore take a short break.
Sir Wyn Williams: That’s not to – how long do you think you’ll be, Mr Henry?
Mr Henry: Well, I’ve been given quite some leeway but Mr Blake has very helpfully addressed some matters which means I can deal with them quicker, but I think I could be between 20 and 30 minutes.
Sir Wyn Williams: Then we had better have a short break.
Mr Blake: Shall we say ten minutes?
Sir Wyn Williams: Let’s fix a time because then I’m –
Mr Blake: 3.40.
Sir Wyn Williams: 3.40. Fine.
(3.34 pm)
(A short break)
(3.43 pm)
Mr Henry: Sorry, sir, I didn’t see you were on the screen.
Sir Wyn Williams: That’s all right. I’m here. And I’m glad you are speaking into the microphone.
Mr Henry: Rather too breathily, I fear. If I may be permitted, sir, through you, to just thank Mr Muchow for his openness, if that isn’t inappropriate. I just wanted to – I have been given permission to go to a number of documents but it may be easier if I just deal with the subjects and only go to the documents if I really do need to. Thank you.
Sir Wyn Williams: Whatever suits you, Mr Henry.
Mr Henry: Thank you very much, sir.
Questioned by Mr Henry
Mr Henry: Sir, would you agree that although Mr Austin was in a very difficult position, the decision to rewrite inevitably led to subsequent code regressions and repeated errors?
Stephen Muchow: I’m not qualified to respond to that. I only know from my own experience of software development, which is a long time ago in another life, that these things are always very challenging and that – I don’t believe he was wrong but nor do I believe he was wholly right. There was a balancing act to be had and the impact that might have ensued on the estate probably would have had an equally severe impact on the fortunes of ICL Pathway.
So I have to support Terry in the decision that he championed.
Mr Henry: But I’m just – I realise that you mustn’t go outside the boundaries of your expertise but just developing what you actually told us when Mr Blake was asking you questions that code regression, you said, was where problems get introduced.
Stephen Muchow: Yes.
Mr Henry: That is because there are purported solutions which introduce problems.
Stephen Muchow: I have never come across any coding situation where changes to the code did not introduce new problems.
Mr Henry: Thank you. And also previous remedies, as you mentioned – although you didn’t use those exact words but I’m just trying to, as it were, tease it out – previous remedies were, let’s say, overlooked. So forgotten fixes or patches meant that the errors cropped up again later on.
Stephen Muchow: They may have done. I can’t say that they did but what my team pointed out was a concern – this was one of the last elements of Mr Blake’s questioning. I was talking about the CI3/CI4. Is that what you’re referring to?
Mr Henry: Mmm.
Stephen Muchow: Yes, I think there was a concern in my team that CI4 was not exhibiting the remedies that had been applied to CI3 effectively. So whether they were identical I doubt, because you’ve changed the mix of the software. The recipe’s changed. Whatever you do to it, you don’t expect – unless you make exactly identical, then you can’t expect to get the same result.
So if the team had found errors in CI4 which they thought had been cleared by fixes to CI3, then that indicated that CI3 had missed some of those, and that’s all that we were trying to highlight.
Mr Henry: And you also mentioned that rapid application development that there weren’t enough staff.
Stephen Muchow: As far as I remember, there was only one.
Mr Henry: Really.
Stephen Muchow: I wasn’t development director but it wasn’t the sort of development process that had been used before and so if some bright spark said, “Well, why don’t we tried to use rapid application development?” it’s very tempting to say, “Ooh, that’s a new idea. Let’s try that. It might give us something” and I don’t think it did.
Mr Henry: Now, could I ask you, sir, about the phrase you used about your team becoming a “sacrificial lamb”.
Stephen Muchow: Yes.
Mr Henry: Would that be because development were essentially encountering all of these problems and not perhaps addressing them satisfactorily and you were being left, in your role from the point of view of customer services and the Horizon Service Helpdesk, to sort of pick up the tab?
Stephen Muchow: No. No, I don’t mean that at all. Those things should have been resolved by testing. When the development team makes the changes, they do unit tests, module tests. They might even get as far as a – they won’t go as far as a system test. They’ll hand that over to the test team who will put those things together piece by piece and they will have a set of scripts which they follow to try and prove that it’s operating as per the current specification.
When I said “sacrificial lamb” what I meant was had there been any of those things left behind or ignored or – no, not ignored, overlooked, then my team would have to cope with it. And there were never – there weren’t penalties per se that directly resulted from development. It was always the customer service side. So that’s what I’m talking about. I paid the money –
Mr Henry: Yes.
Stephen Muchow: – when we got it wrong. So that’s all I was trying to elaborate.
Mr Henry: So, in other words, forgive the biblical illusion but the sins of development were visited upon the Helpdesk –
Stephen Muchow: To all of us because we were not backward in coming forward with our criticism of development. I mean, there’s a traditional friction, tension, love/hate relationship between developers and supporters because the support team always seems to get it in the neck when things goes wrong and it’s the developers who say, “Oh well, they did it wrong”.
In fact, it’s all of the team that had to work together to give the feedback back to the development team to be able to make the changes and that’s what Pat was doing in that letter. She was saying, “This is what we’ve found, we need to” – and so it goes up the chain of command and that’s where I wrote to Terry.
Mr Henry: So without wanting to trivialise this in any way at all, but were the difficulties that you were experiencing with your department, as it were, having to pay the bill but it was a little bit like whack-a-mole in that one problem was apparently solved and then another one would spring up?
Stephen Muchow: No, that is trivialising it, with respect. The company paid the bill.
Mr Henry: Yes.
Stephen Muchow: Customer service calculated how much we had to pay. Some of customer service was responsible for the failures (for instance, the Helpdesk call to fix this and so on) but we, as a team, would have to fix it. It wasn’t anything like whack-a-mole. Whack-a-mole would be good if you could find all of the problems simply by testing.
But what I mentioned earlier what I wished we’d done was a little more hostile testing. So instead of following a script, which is basically how we would like the operative – the operator of the terminal follows a set of rules that they’ve been trained so to do. The system is a program which is software, unintelligent. It follows a set of rules that it’s been trained to do. If there’s a mismatch, something has gone wrong and it was always the difficulty in finding out what potential things could go wrong that we hadn’t envisaged.
So, for instance, a line dropping out in mid-transaction. Well, if it happens at 10 milliseconds into the transaction it will have one effect if it happens 40 milliseconds into the transaction it may have a completely different effect. Now how many problems have I got?
So that was our – so the sacrificial lamb is really more to do with we were the ones sorting that problems.
Mr Henry: I see. Thank you.
Arising from your answer that you’ve just given about the operator having to perform a certain sequence and the unintelligent program also having, as it were, in tandem a certain sequence in response, would you be able to help me because you talked about from 2001 that your department was responsible for audit extraction.
Stephen Muchow: Sorry, carry on then.
Mr Henry: Well, I want to know about ARQ data because you raise this issue about providing information under RFIs. Would the ARQ data not give the keystrokes that had actually been entered by the operator?
Stephen Muchow: I don’t know, to be honest. When you say “ARQ” can you … ARQ.
Mr Henry: You weren’t familiar with that term? Don’t worry. If you weren’t, then I can move on.
Stephen Muchow: It’s evaporated from my ever-diminishing brain cells, I’m afraid.
Mr Henry: Well, don’t worry then. If you’re not familiar with that term, then I’ll move on.
Stephen Muchow: Is it somewhere documented in my bundle?
Mr Henry: No, it’s simply from the point of view of the data that would actually enable one to analyse what the operator had actually done but if you’re not familiar with that, then I’m going to move on.
Stephen Muchow: A log of the keystrokes?
Mr Henry: Yes.
Stephen Muchow: I don’t know what it was called but I think there was a log of keystrokes, yes.
Mr Henry: Could I ask you please, though, arising from the word “Tracy” that you mentioned, if I give her name as “Tracy Felstead” does that help you –
Stephen Muchow: That name rings a bell, yes.
Mr Henry: It does ring a bell?
Stephen Muchow: Yes, not from the point of view of being part of an investigation but from what I read in one of – because I went back over the transcripts and testimonies of postmasters who had been prosecuted during the time I was there, and the only one I seem to remember was Tracy Felstead, but I don’t know why, and she wasn’t part of any – I don’t think we ever received a request for information for her.
Mr Henry: So that isn’t necessarily a recollection of what happened in 2001, is it? You’re just saying that the name has become familiar to you –
Stephen Muchow: Yes.
Mr Henry: – during the course of the Inquiry? Is that fair?
Stephen Muchow: Yes. Yes, I wanted to see if I remembered a person to sort of refresh my memory but, in fact, I don’t believe there was ever not one single request from Post Office during my time there.
Mr Henry: Not one single request?
Stephen Muchow: No, not that I was involved with, no.
Mr Henry: Can you help – and I realise I’m not going now specifically, since given the previous answer you have given, but can you recall if there was ever any discussion in respect of financial compensation for the provision of such data in connection with prosecutions?
Stephen Muchow: Yes, yes, yes. There was in one of the contract meetings because this involved work which had to be funded and so there was an agreement made that Post Office would pay for each request. I don’t know how much it was but there was certainly a sum of money to be paid.
Mr Henry: I appreciate that and thank you. I’m just trying now to, as it were, probe a little bit further. Did it ever come to your attention that perhaps somebody accused of, let us say, fraud (whether it be theft or false accounting) would have to pay Fujitsu for the provision of information?
Stephen Muchow: That’s ludicrous. Sorry, no. No, no. Our customer was Post Office Counters Limited. Post Office would be required to pay to provide that.
Mr Henry: So that would have been, as you say, ludicrous and completely irregular?
Stephen Muchow: Yes.
Mr Henry: Sir, if you can help –
Stephen Muchow: Furthermore, we in Fujitsu ICL Pathway never had dealings directly with postmasters, to my recollection. Never did we speak to them about these things.
Mr Henry: Well, thank you, sir.
Could I ask you please – you’ve just indicated that you have reviewed certain of the proceedings, and nothing wrong with that at all, quite properly. Did you look at Mr Simpkins’ evidence back in November?
Stephen Muchow: Andrew Simpkins?
Mr Henry: Forgive me?
Stephen Muchow: Was it Andrew?
Mr Henry: John Simpkins.
Stephen Muchow: John Simpkins?
Mr Henry: Yes.
Stephen Muchow: No.
Mr Henry: Well, I won’t ask you any questions arising from his evidence.
But could I ask you this: to your knowledge, were there any tools or processes that you had to help level 3 staff, SSC staff, identify when there was a distinction between a problem with the system itself or whether it might have been user error?
Stephen Muchow: I don’t know. The SSC were a peculiarly clever team who would work magic, I think, on looking at the system. They had to be in order to find out the root cause. There was no point in having a System Support Centre that would simply say to development, “You’ve got a problem, mate; sort it out”.
What we had to do in the SSC was try and replicate the fault and get to the point where we understood exactly what the postmaster had done, what the system had done, what the communications, the infrastructure, the hardware had done, to generate that outcome and that was something they were – to my recollection, I’m very proud of them. They did that very well.
Mr Henry: How familiar were you with, to use your expression, the “magic” that they conjured up?
Stephen Muchow: Now, now, that, sir, is - right –
Mr Henry: Forgive me if that’s loaded but –
Stephen Muchow: It seems to be magic to somebody who is not familiar with the methods that they use but if you were to look at somebody writing code today and somebody writing code ten years ago, you’d understand. They were very, very professional, very clever. Some of these people were what we used to call dump crackers. They’d look at binary bits, binary 1s and 0s and work out how things had gone wrong in the program. But no.
Mr Henry: I think – sir, I didn’t mean magic pejoratively.
Stephen Muchow: Good.
Mr Henry: But were you aware that SSC sometimes inserted or injected, edited or deleted transactions to implement fixes and that was done without the knowledge of the subpostmaster in question?
Stephen Muchow: Deleted transactions I don’t think they did. I believe what they were able to do – with the NBSC’s approval, by the way, with Post Office’s approval – would be to inject a balancing transaction. They couldn’t modify what had been done but if a postmaster had got into the position where he couldn’t rollover to the next cash account period because of some problem and it could be rectified by a balancing transaction – so, for instance, if he got something which said £900 and it needed to be zero then, I think the SSC could inject a minus £900 transaction. But that would be done with the authority of Post Office.
Mr Henry: How closely involved were you in that process or were you at one remove?
Stephen Muchow: No, I was quite more than one removed.
Mr Henry: Substantially.
Stephen Muchow: But I do know that – I mean, I wandered around in the evening sometimes to talk to them, and I think the balancing transaction came up as an idea to help as a workaround before a problem was fixed; so that it was an idea that we put to Post Office that we could do but I was never involved in actually doing it.
Mr Henry: But you weren’t aware of the actual Post Office’s communication with the subpostmasters about that and whether it took place or not?
Stephen Muchow: I don’t know if they did. I would have imagined that Post Office – I would have thought the NBSC (Network Business Support Centre) would speak to the subpostmaster and say, “This is what we’ve done; you can now roll over onto the next period”.
Mr Henry: I see. Were you directly involved in the removal of that rolling over and the removal of the suspense account yourself as a result of negotiations between the Post Office and Fujitsu?
Stephen Muchow: I really don’t understand what you mean but I wasn’t but –
Mr Henry: There came a point, sir, when a postmaster could no longer, as it were, park disputes in a suspense account and had to accept Horizon as being accurate before being allowed to continue to trade on; in other words, the right to question the data that Horizon had rendered, the books that Horizon as it were had generated, was removed.
Stephen Muchow: It beggars belief that that actually is true but, if it is, if that’s what you say, it’s true, then it’s …
Mr Henry: You weren’t aware?
Stephen Muchow: Not just not aware: I can’t see why you would want to do it.
Mr Henry: This is my last question to you, sir. You formed the view that the negotiators on behalf of the Post Office drove a hard bargain?
Stephen Muchow: Yes.
Mr Henry: And they knew what they wanted, not necessarily from the point of view of giving you a plan for the system in advance, but they knew the commercial objectives they wanted to achieve.
Stephen Muchow: 100 per cent, yes.
Mr Henry: 100 per cent. And the priority was automation, reducing costs at Chesterfield, manual balancing of books, correct?
Stephen Muchow: I think they are three of, yes.
Mr Henry: Thank you very much.
Stephen Muchow: I think a lot more as well.
Mr Henry: Yes.
Stephen Muchow: But that’s it.
Mr Blake: Thank you very much, Mr Muchow. Is there else that you would like to add or clarify?
Stephen Muchow: I thought about this before. Frankly, no. I think the questioning today has given me ample opportunity to express my opinion.
I’m very sorry that this Inquiry has to take place at all. And, having listened to some of the postmasters’ testimonies, I’m quite distressed by it. I never imagined that some company as respected as Post Office could take, as Mr Henry just pointed out, away the ability to challenge what is true. I mean, if you know there’s a problem, then you shouldn’t have to sign it away. So I was quite, quite – quite surprised by that statement, sir.
Mr Blake: Thank you.
Chair, is there anything else that you would like to ask?
Sir Wyn Williams: No, I’m very grateful to you for coming to give evidence and answering a great many questions and also for your comprehensive witness statement. Thank you indeed.
Stephen Muchow: Thank you.
Mr Blake: Thank you very much, sir. We will be back at 10.00 tomorrow. We have two witnesses: Mr Gilding and Ms Parker.
Sir Wyn Williams: Thank you very much. See you in the morning.
(4.08 pm)
(Adjourned until 10.00 am the following day)