FUJ00243263
FUJ00243263
File name: Updates on ways of working PEAK-20210804 - Chris Maving team
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
STEVE BROWELL: Normally you get a message popping up, don't you, saying this is being
recorded? And it looks like it is. Ah, there you go. I've just seen the message. You probably saw
it too. Now, am I right to think that the team is predominantly based around the use of Peak more
than TFS, or would that be wrong?
MARK ASCOTT: Solely peak. TFS we don’t use. We are using JIRA as part of the future
work.
STEVE BROWELL: Right. Okay. In that case, although there are there are aspects of this that
dovetail with TFS, I will go quicker through those to spend the time on the parts of the system I
think are more relevant to you. But I can't dismiss them completely, because of the linkage it has
to some of our works in Peak. So allow me to make a start. So a few all hands ago, I played back
that as a consequence of some activity I'd done around, or we had done around the Horizon audit,
which was a piece of work POL commissioned us to do, the public inquiry questions and various
other things, probably from KPMG and post office new starters and the likes, we were being
asked all sorts of questions, and we were doing our best to answer them, but in so doing, we
identified some things which probably could be better. And all that happened is a list was made,
and then when all of those pieces of work concluded, the list was broken into streams of work,
and those streams of work were then kicked off with various people in the organization to make
sense of the observation and prove it to be true or not and decide so what we're going to do about
that, then. And the focus really for me now is on four of those streams, which relates to TFS,
Peak, the processes within TFS, the processes within Peak, the processes into TFS and Peak, and
then how we use the systems and the data within them to drive the meetings that we operate as a
community and, equally, our communication with the customer.
And the goal is really about finding a way to be clear we work to ways that suit us, that we are
more system and process driven rather than by people and their personal contribution, and that
management reporting for ourselves and for the customer is something that is more naturally
producible and trustworthy as content that we can make decisions on. So we set about these
streams, documented the observations, kicked around the ideas, threw out some daft ones, added
in some new ones, and hopefully collided on a whole series of strong statements about better
process, better data usage, better interactions between our teams that would allow us to therefore
get into a new way of working. When this concludes, although this document thumbnail here
shows the latest iteration of the document, there is a newer one that I'm working on, it will
eventually land in a live defect management document, which will be a new artifact. I'm
assuming there isn't one already, but I assume it'll be a newer updated artifact.
And then a series of other amendments to any local documents you have, work instructions,
processes, procedures, strategy statements, etcetera, so that the content is lifted and placed into
things that you would more naturally refer to and use. And that's the intention. We're not entirely
there yet, but the goal, the emphasis we placed on it was we wanted to get process agreement and
consistency within and across teams, so that we had a clearly understood way of working that if
we fix the issues as we went along, would therefore be better. We're not doing a complete end to
end time and motion study of every team. We're not. We're looking at the management of
FUJ00243263
FUJ00243263
File name: Updates on ways of working PEAK-20210804 - Chris Maving team
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
incidents, defects and team interaction in terms of process. We looked at the TFSNow and Peak
systems, the tool sets that we all rely on. We looked at the data and the reliability of it. We
needed to build that up, because we need to be able to report on it, see it, make judgments based
on it. So we can track and validate, so that therefore we can move on and get enhanced
management reporting, so we can see what things, what's going on, spot areas of improvement,
build confidence in the reports that we deliver for post office, and equally build a greater
involvement of post office into the processes we think they should be involved in, because we
can manage it through the data. So if they're seeing live defects, they know the state of them and
feel they can contribute to the decision making. And that's an increasing appetite of theirs to see
more. And if we have an equivalent appetite to share more, then we just need to be confident that
the content shows us in the right light. And that's where all of this collides. That's the emphasis
that was placed on the work we did and what we were seeking to achieve.
00:05:07.0
So this is Belfast specific, the HNGX systems in Belfast, not post office cloud yet. That will
come, but we're not looking at the ways of working for post office cloud at the moment. And the
equal thing to acknowledge is we could have done some wholesale review of all the tools and the
ways of working, but that felt onerous. So we've gone with evolution, not revolution. So making
a number of changes to what we've already got to hopefully make a greater impact on our ways
of working. And I shared the box--sorry, the arrows at the bottom. That is not a new process, by
the way. It's my simplification of one that exists already. But the important thing from that
emphasis that was just shared is I need to know or the business, the account needs to know where
are things at, where are they on that continuum, where are things getting stuck? Where's the
bottleneck? Where are we? You know, where are we good, bad, or indifferent? And it starts at
the beginning with an incident, whether that's a TFSNow incident or an investigation Peak. So
we have at that point a potential live defect, if it relates to the live system, of course. If it doesn't,
I'm not as interested. If it's a test system, an internal system, then that's not in my area of interest.
It's live incidents here. So we have a potential. We don't know what it is, but somebody said
something's not right, so we need to investigate and qualify it, and that might mean that there's
nothing needed to be done, no fault. It needs a change raising, cause actually, yeah, there's
something not right there, or it needs a fix writing, creating, at which point we have a confirmed
live defect that needs action. That would exist as a defect peak. I'll explain more about that in a
minute.
That then needs to be quantified in terms of effort to remedy with development of architecture,
who then need to take it to BIF for discussion about potential solutions and approval to proceed.
That might lead to and the customer should be involved, so customer BIF. But it might not. Then
it leads onto the peak targeting. Then obviously, once that's done, we can then consider, when
appropriate, starting the development work, followed by the testing work, followed by the
release. And the goal in all of this is to go as fast as we possibly can from left to right, but
especially once we've hit confirmed live defect, to go as efficiently and as quickly as possible to
fixed, not a new continuum, but one that I was anxious that the work we do allows us to better
see where things are at. And that's what we've been doing. And that's the impact, hopefully. First
FUJ00243263
FUJ00243263
File name: Updates on ways of working PEAK-20210804 - Chris Maving team
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
thing, I'm talking about live defects. What I mean is it's present on a live system. It is or it
appears to be inconsistent with the agreed design or service specification. In simple terms, it
shouldn't be like this, and is therefore a fault that is likely to need fixing. And I say likely, cause,
of course, we may still be qualifying, but if it's on the live system, it looks to be inconsistent with
the design or service specification and it looks like we're probably going to have to do it, it
would need a fix if it turns out to be true, that's a live defect by the definition. And that will carry
in Peak a manually added ##LiveA ffectingDefect collection marker. And it will probably be call
type L, but it could be other call types as well. But the important thing is it will have that marker.
If this is in TFS, there's a configuration item that has a similar name that can be used. It doesn't
matter if we have a workaround or not. A workaround, great news. That means that the
experience is managed, but it is still a defect, a live defect, whether there's a workaround or not.
So if it meets that criteria, those three sub bullets, it is a live defect by the definition we're
currently working to.
ANDY PAVIS: Question, if we find a problem in a release that has already gone to live, but we
find it on a test system, we know it's gone to live, so it is a live system. It is present on a live
system, therefore that is also a live defect.
STEVE BROWELL: Correct, because what you've seen, you might be testing, I don't know,
release, I'll get all the numbers wrong. Let's suppose 71, no, 2094 went in, didn't it? And then we
found all sorts of odd things later. If what you find whilst testing maybe something utterly
different looks to be something that would be present in some live code, then it is a live defect,
and it needs to be managed through the qualification assessment process.
00:10:04.7
But if it's just in that release, because it's something you’re testing, and it didn't seem to meet the
brief that you thought they were supposed to, that is not a live defect, that is during testing, test
phases or development phases, and that does not need marking. You can manage that as you do
today. Yeah. There is a sub classification of Horizon defect, HDR, the Horizon defect review,
which is a forum that the customer now chairs, we use to chair it. And this is for live defects that
have additional attributes. In simple terms, they are affecting or could affect a postmaster in their
daily duties. So if it could, if it affects or has a potential to affect the branch financial outcomes,
it needs to have a HDR-Fin collection added, financial, HDR financial. If it is affecting the way
the postmaster is working with the system, whether that be cause of the user interface, a report or
a function they perform is compromised because of this, then that's the HDR experience. Or if it
affects a customer, me or you, perhaps as we wander into a branch, cause the receipt looks a bit
odd or the product category or something is a bit off, that is a HDR experience. Those two
classifications for three conditions are super important, because we report those to the customer
every week, and we track them and report progress every week. And post office communicate
those to their postmasters.
So if we are--if it could or is affecting branch operations, we have to tell them. And we do that
by marking the Peak or the TFS ticket with an appropriate tag that we've set up, and they are
FUJ00243263
FUJ00243263
File name: Updates on ways of working PEAK-20210804 - Chris Maving team
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
reported on. Again, it doesn't matter if there's a workaround. If it is present on the system, we are
duty bound to disclose it. Just to give you some context, there are currently only 10 carrying that
marker from incidents that have come in. There are further 18 as a consequence of deferred
Peaks through releases, cause, obviously, if you defer a condition and it goes live, it is therefore
a live defect by default. So that means that those are added, but those are at all approved and post
office is aware. So if it could affect the branch, then we are duty bound to mark it and report it.
And that's really important, because that will be visible, perhaps, to inquiries and other people as
well, because our management of live defects was criticized in various court reports. Whether
fair or not doesn't matter. But it's obviously a topic of interest, and people are asking the question
how many are there, what state of the art, how are they affecting postmasters, do post masters
know?
All of these teams came up during the public inquiry, and will probably come up again when it
becomes a statutory inquiry. Well, it is a statutory inquiry. So that's it just smashed together.
That there's a live defect. Within that, there is a category of Horizon defect. You cannot have a
Horizon defect review HDR candidate that is not a live defect. By logic, it doesn't work, cause
obviously postmasters are not living and working day by day on test systems. So that's an
important new definition. So Horizon defects review is a critical meeting in our new mutual
timetable. Investigation peaks is another new language. This is where we're investigating the
cause or action. And we don't know yet if it's a TFS incident. Could well be linked. It could've
been triggered by an inbound from the TFS platform. But if post office should be aware, we have
got to tell them. We've got to alert them. We cannot just work on it independently if it is
affecting post office operations. The call type in Peak is probably going to be L for that, although
I have seen various others. There's a system test category and others. It doesn't really matter. But
if it is a live incident, then it ought to be category L. And if it's a live defect, it'll have other
attributes, like ##LiveA ffectingDefect. Defect Peak is one which is not linked to any TFS
incident. And it is a ticket that we are now managing through our process, BIF, CBIF, PTF
development release test. I did that back to front, doesn't matter. But that's the one that we will
manage through our process. It is not linked to TFS. Anything we put in it and how we manage it
is of our interest only, not the customer. And, of course, you can have a potential live defect,
because you do not know for sure if the condition is true and proven. You can have a confirmed
live defect, cause it is definitely proven.
00:15:08.4
OTI you may see in documents is the interface between Peak and TFS, and KBA, the term KEL
is defunct, gone. We now use the word, the phrase knowledge based article. This is not new, by
the way. This was introduced years ago. But depending on how long you've been on the account,
KEL is embedded in your brain, but we wish to remove said definition and gravitate quickly to
knowledge base article. It can still be action information or fix a fault, sorry, but it's a knowledge
base article, because it wasn't really. All of them were not known errors. Some of them were
hints, tips and guidance for support. In fact, many of them are in that category, or things
observed and how to deal with it if it happens, or hint tips and guidance for SMC when they see
a condition arise. So these are not errors, which was a sadly misleading title. So KBA is the new
FUJ00243263
FUJ00243263
File name: Updates on ways of working PEAK-20210804 - Chris Maving team
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
KEL, please. So pictorially, if I can just talk you through this, so if the customer raises an
incident and they want us to be involved, they bond it and that creates a TFS incident, and that
might be enough. The relevant Mac and other resolver groups, network security, whatever, just
work on it, and the updates flow between the two systems and that's all good. However, some
will require the involvement of our third and fourth line teams. And that'll be done by assigning
it to a Peak resolver group, which creates an investigation Peak, a call type L Peak linked to the
TFS incident. Anyone who updates this, it flows back to TFS. It flows back to service now and,
hey, presto, everything is kept in sync. There can actually be an absence of a service now
incident if it's just from RSMC to us, and then the flowing goes backwards and forwards, which
is fine. At the point the investigation concludes with a confirmed defect, this needs fixing. This
Peak must be cloned. The clone must be given a call type of hash. The clone Peak number must
be added to this investigation Peak. Then this investigation Peak is closed. This incident is
closed. And, frankly, post offices can do what they like because they will have a reference to the
defect Peak.
What happens next is Fujitsu internal. How we take that forward, the pace at which we do it, the
state it's at, the updates we apply to it is us, us, us. It is not linked to TFS. I know there are many
scenarios where you, the test teams and our development and architecture, will raise peaks
because something looks off. So that's an investigation peak. It doesn't have a TFS incident. It's
an investigation peak. It's something we're looking into, and that is fine. But if that fault or
condition is something post office should know about and should know we're looking into, we
must not continue to work on the Peak, stop. We must have an incident raised, bonded so post
office can see it, which will be escalated back into Peak, and a new Peak will be raised. And we
need to move the content, copy it, into the one that's linked to the TFS one. Otherwise edits to
this will not appear in any system that the customer can see, and we cannot keep them appraised
of progress. That doesn't happen a lot, but if it does, so only if the customer should be told, do
we need to stop and create a TFSNow incident. If the customer does not need to be aware ,we're
having to look at something because there's a weird message that we're a bit curious about that's
affecting us, then we can leave it just like it is. It's an investigation Peak. And when that
concludes that there's something that needs to be fixed, you don't need to clone it, cause it only
exists in our world. You simply change its call type, and it falls into the confirmed defect stack,
visible to us only. So there's just some subtle changes to the ways we operate. The big one is the
defect Peak has a call type hash and is created when we are certain a fix is needed. Everything
else is an investigation Peak, and we are simply getting to the bottom of what is going on. So I'm
going to pick out and highlight some of this. This is mainly the TFS stream. We no longer share
knowledge base article and Peak references in the body of TFS bonded incidents. That is our
system for our benefit. But we will include content from a KBA or a Peak that should be
embedded into the incident, so that post office is informed, not the internal stuff, not our own
workings, nothing of the sort, only the bits that are relevant, so that the TFS incident is integral
and then replicates to service now.
00:20:08.6
FUJ00243263
FUJ00243263
File name: Updates on ways of working PEAK-20210804 - Chris Maving team
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
If it is not bonded to post office, carry on doing whatever you like, because it's internal to
internal. Most people who work the peaks in third line know this now and some of the fourth line
teams, so this shouldn't be an issue. It's not relevant to defect Peaks. It's only investigation Peaks.
And if it's missed, then the Mac team will intercept it anyway. So that's just a change. So we no
longer have any appetite from post office to see copies of things we've referenced as knowledge
base articles or Peaks. The links are still in our systems. The external internal references are still
in our systems. But post office should not be aware that they exist. These are our artifacts in our
platforms, but we must share the relevant bits in the incident. We're not seeking to mislead or
hide. We're just seeking to remove the dependency on the systems that we use. I've asked them to
try and do a bit more on the summary field. That's the bit that eventually creates the summary
field on the Peak, if it's new. The reason is that's one of the fields that we will be pulling on
standard reports, and if it's full of tacky bubble, it is sometimes difficult to understand what the
Peak is all about. You will all have experienced that. And I'm trying to get away from the need to
have to read every Peak end to end to make sense of what it really is talking about. So I'm
encouraging, where we can, a better discipline on the summary field, so that it flows through to
us. And I'm also actively discouraging the use of emails to give additional progress or
information that relates to something which is logged in our system as a peak or a TFS incident,
because if you have more information to add, put it in the ticket. This is not your view then, it is
a matter of system information, that everybody knows it.
Again, to avoid these sidebar discussions that seem to kick off with can you please look at this,
what do you think, all of that has to stop. And we should just put it into the incident or the Peak
so that everybody can see it. And my other ask from them and the same of us is there are people
like me less qualified than people like you that read these and try to come to conclusions or
understand what's going on. The better worded they are, the less likely you are to be pestered,
and the better worded they are, the less likely the customer, if they see any of the fields, is likely
to challenge and question. So just think, if I'm writing something that is personal jargon, maybe I
could add a few more words, and it would read like a sentence, and maybe someone like Steve
would understand it. That would be my ask. Let's move on. These are not relevant to this session,
so I'll skip this slide. I did skip it. It moved on. Right, now onto the bit that's much more relevant
to the world of Peak and Peak specifically as well for live defect management. So we've added
some new fields. You will probably not need to use the first three, so POL problem reference,
Fujitsu problem reference is a mechanism for us to add in external reference fields, so we can
link Peaks to other systems. So if post office is tracking this defect because they've got it as one
of their own recorded defects, they do that by a problem reference number, we can add it in. It
means that when we pull reports and extras, that can make it easy for them to stitch together our
data with their data.
The FJ problem reference is to help Matt understand which Peaks he has an interest in, in
progressing the problem records that he's working on. Matt [INDISCERNIBLE 00:23:39], that’s
our team. Workaround is a new field. It should have been set before you see it, but you never
know. It should be added by third or fourth line as part if they determined that a work around
applies. If it isn't, it'll be challenged at BIF. It'll be challenged at PTF, such that it is correctly set.
We always did this. We used to write it in the body of the text. I'm just asking that it's now
FUJ00243263
FUJ00243263
File name: Updates on ways of working PEAK-20210804 - Chris Maving team
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
placed in an independent field, cause I can query that. And obviously great news, if we can
always find a work around for everything, that would be brilliant. It takes the pressure off the
pace at which a fix is needed. There is another tab which I don't think any of you will need to
complete. So I tell you it's there just for information. But we now record the dates of BIF custom
BIF and PTF meetings and the outcome of those meetings within the body of the release
management tab at the top of the screen. It'll be done by people like Mick Reynolds and James
Guy, not you, but you're obviously be able to read it, and if at BIF they think the customer
should be alerted, there are six criteria that we have determined would warrant that, and they just
tick the one that applies. That allows us to say which BIF meeting did this particular Peak go to?
I can check the date range, and I can find it.
00:24:58.1
What did we say at that meeting? I can find it here and not in the minutes on SharePoint. Why
did it go to customer BIF? I can find out why. What was the decision made at any of those? It's
in the minutes, as in it's in these fields. So I don't need separate documents in separate meeting
folders to try and stitch together what happened. I can see it all in the system. So that's helpful.
So that's a FYI. You won't have to edit those, I don't think. Somebody got some new field values.
Now, there has always been a call type. It never had this one at the top here, hash defect
identified. And this is for when we have confirmed we have a defect that we now necd to fix, it
will be derived from the clone of a live incident that was bonded to a TFS record, or it will
simply be the change of state for an investigation peak we raised internally that was not linked to
TFS that we were working on in ourselves. But that, to me, is an emphatic statement, defect
identified, this needs fixing and needs to go through our process. It will also have the
##LiveA ffectingDefect, cause it is a live defect as well. It will have both. It will have had the
LiveA ffectingDefect probably earlier when it was called type L, and it will maintain it as it
progresses to be a confirmed defect at call type hash.
Really I’ve covered that double hashtag. This is on the field, you pick the drop down and you
just say add to collection, same with the Horizon defect review. If you think it affects branch
financial or experience conditions, set it on. If you do, I get an alert. So if you've done it and you
are wrong, I'll probably ask you, and we'll fix it together. If you've done it and you're right, thank
you. I'll be alerted, and I'll know to build it into the weekly report to the customer, to post office.
So but these should have been set well before you see them, I would expect, on the basis that
they’ve been set while it was investigated or confirmed as a defect, therefore at BIF or PTF and
should happen before you touch it. But if you're raising a new one found in test that relates to the
live system, you may need to think about should I set this, but if you don't, third line or fourth
line will. So there's loads of people who will be cross checking this and making sure that we
don't miss it. So they're new field values, but not new fields. There are some existing fields that
now become much, much more important, because we use them for reporting purposes. The call
type we've probably covered with its hash defects identified is important, and the
##LiveA ffectingDefect collection, they really matter.
FUJ00243263
FUJ00243263
File name: Updates on ways of working PEAK-20210804 - Chris Maving team
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
Summary, you probably can't always affect that, but certainly if you raise something new, you
could give it a better description or the best description you can think of that would help
understand what it is. Impact is a field that was there all the time. It used to say, I think, either
just business impact or problem statement, risk of fixing, risk of not fixing ASM utilization, I
think it was, but it has evolved specifically for Horizon defects. So that's the ones we share with
the customer to be business impact, status update, next action, so that they could read it and
understand what the implication of what we're sharing with them is, where we're at and what
we're going to do next. And that helps them see everything in one place and avoids the need for
them to have a copy of a Peak or a KB or anything else that they feel might be useful. And then
these fields, priority A, B, C, D, Z, I think, assigned team, that's the people I will pester, as Chris
knows well, and the product group and products so we can get start to get a bit more granular
information about the problematic areas of our system or those that seem to require the most
attention. They've always existed, these fields. They've sometimes been filled in, but not with
any particular rigor. And the ask from this point forward is that they are. Again, in the main,
these will have been filled in before you necessarily touch them, but you may be able to help
with contributions to the impact statement.
And if your update to the Peak is clear, if you have updated it with a status update, whoever
writes these, and we're only writing 10 of them currently, will probably be able to work it out for
themselves, if it's reasonably well written. This is what we report to the customer when we do the
Horizon defects review for them. They get the call reference, the defect peak number, the
summary field, whether there's a workaround from that new field that's been set, and that impact
field, that's what they get. So you can see FAD19 St Annes Bureau Preorder Transaction, node
two. I mean, what does that mean? Hence my comment about, if the summary can be more
eloquent, the better. I do think that this bit’s well written, cause we make a real effort to make
that eloquent. So I'm okay with that. And those of us who sit in the HDR forum, we'll pre-extract
these and make sure they're well worded, so we look good when it's submitted. And this
workaround is checked throughout BIFC, BIF, and PTF to make sure that if there is one, we
record it. So that's what we're sharing. And that's why those few fields are really important for
customer reporting currently. There are some other fields that are important. Root cause isn't
particularly well used, if I'm honest. It seems a bit sporadic and seems to have some repetitive
values in it. I'm asking that it is given a bit more thought, because it will help us look at patterns.
There are certain values which I will treat as probably no fault found, because they relate to
either user knowledge, user process or the user. So I will qualify those out. We will, of course,
then pick those up and drive them forward as an enhancement request to the customer, so we
won't ignore them.
And response category is the kind of the stage it's at, which is either open, pending, fixed, final
or closed. There are many of those which should be continued to be used exactly as you did
before. But these few are not new. They are existing, but they're important, because I use those to
determine--I qualify them out. So if anything is changed and says program approved, no fix
required, no matter what tag it's got on it, I'm going to say no fault found. Equally, if we say it's
it was closed because of advice after investigation, I'm saying no fault found. And this is
consistent with the SVM, SDM Pro 0875, the application support strategy document. These are
FUJ00243263
FUJ00243263
File name: Updates on ways of working PEAK-20210804 - Chris Maving team
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
defined as no fault found conditions that can be set in the category, in the response category
settings. I think it's just called category when you pick it, but it is actually response category is a
field name. And I acknowledge that this one is not a no fault found, it’s just a normal work
needed in Peak. It passes to TFS, and it may have gone to a different resolver group, but I have
reports that have TFS that can complement this that allow me to get a complete view. But those
are in--
ANDY PAVIS: We don't get to set final response categories now. We only route to an internal
theme, and then somebody else deals with the closure lease management.
STEVE BROWELL: Yes, that is correct. Cause what we've said is it should be moved to final
by release management when they deploy, and it should be moved to closed by the originator
when they see it's moved to final and are happy it's right. So, yeah, you’re right. Yours are all
mostly pending, aren't they, in terms of state changes.
ANDY PAVIS: Yes. There are a couple of useful pending categories, though. One second. I
think it's 95 and 96 or something like that is pending categories.
STEVE BROWELL: Yeah.
ANDY PAVIS: And they are effectively--this peak is now targeted as a release. It's ready to go
to live.
STEVE BROWELL: Yeah, I think they're 76, 75, but yeah, unfortunately, the numbering
system is a bit [INDISCERNIBLE 00:33:23], cause there are some numbered ones in the eighties
that are pending and so on than earlier numbers, cause we've slotted them in. But yeah, you’re
right, yours would be pending. So they would sit on the RMXQ or in your own whilst you're
completing your work, and then they would progress to final as a consequence of deployment.
You're right. However, there may be some where you do not need to go further, and these codes
might matter, but you're right. These are probably less relevant to you. Okay. So final comment,
then is so BIF is now driven by the BIF action flag. And if the BIF action flag is not set and the
attributes of a Peak would appear to be that it's it stuck, and an investigation or defect identified,
but no further steps have been taken, we may have forced the BIF flag on to cause a discussion,
which Mark will attest to, we did this morning. I figured I pinned it on 10 that I just was not
happy, we're making sense. Now, I realize that's a primitive way of finding out what's going on. I
could have does rung all 10 of them up and asked, but I decided to be lazy and put the tag on it,
because, actually, I think some of them do need to be discussed. Things should not get orphaned
or held or lost. So the BIF action flag will determine what BIF discusses, and it may well be set
for the candidate, if they have not set it themselves, if the Peak has attributes that would imply it
is stuck to earlier stage, and that will cause a discussion. And that's the important thing. At least
it's in the machine, being actively discussed.
00:35:01.9
FUJ00243263
FUJ00243263
File name: Updates on ways of working PEAK-20210804 - Chris Maving team
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
BIF has now got criteria for deciding what goes to customer BIF. It is no longer the discretion of
the people who attend the meeting. It is a matter of formula. We don't use ManDays anymore for
what goes to customer BIF. We do capture it, but it doesn't matter whether it's a big, small or
medium job. It it's irrelevant. If it needs to be fixed, it needs to be fixed. The size of the job will
simply affect scheduling. We're also moving towards a proposal form for anything that goes to
customer BIF. If we're inviting the customer to make a decision, I think we should present the
facts in an eloquent manner. A form is a neat way of doing it. It should just simply state what's
the problem, what are the options, what do we think you should do, and what's the impact if you
do nothing? Most of the content is probably in bits of the Peak, but we should present to them
something on which they can make that decision, and we should keep a record of what that was.
Because we've had a history where we've read out bits of the Peak, we've supplemented it by the
expertise of the people in the meeting, and the customers then made a decision. I don't really
know what they made the decision on, cause it isn't in the system, and we're just trying to move
away from that logic. Let's get it in the system. We record meeting dates, and we record minutes
and updates in the actual peaks themselves now.
Any updates to the customer review meeting, the Horizon defects review, is driven by the
system. If it's got a collection of HDR, it's a candidate. Provided it's not been already fixed, it
will be considered for inclusion, and we will shore up the impact statement to make sure that it
makes sense, and that's what will go out. And it allows us, because of the confidence in the data
we've got, to say, as we have done at some of the Horizon defect review meetings, excuse me,
you just discussed a defect which is not on our stack. Is that a Fujitsu one? No, it's not, actually.
It's just one of ours. We just felt we'd talk about it here. Okay, make sure you make that clear in
future, because that is not something that we wish the audience to think is on our watch. And
there are things like that that we're doing more of, or they will tell us they think they know the
status of something, and we can go no. The last update we gave you said the following, and we
can tease out or bring in more rigor, both sides in fairness. So things are now system driven,
process driven, to the extent that we can. I think we've got some more defined interactions
between teams, and hopefully you're seeing it, or sensing it, if nothing else. We've made quite a
few changes in how we handle releases to make sure that we batch things up, put dates in the
system, so I can see when it's due to go out. I can challenge if there's no date on it. If it's
proposed for, but not targeted out, then I can go, why is that? Are we not sure what to do with it?
And if we're not, why not? What is it we don't know? Well, we've got tickets that are waiting on
Ingenico that used to go out through change, so we couldn't see that the peak closed. So that's all-
-that's changed. Lots of things going on.
And that, I think I'd already showed that with you, just tell you where we are then. So the stage
we’re at is having defined the changes, we're now explaining them in sessions like this, or
recordings, if you're not listening live. And obviously bringing the data in the systems up to the
new defined ways of working. So many of you have had lots of nudges about Peaks saying,
could you change this? Is this correct? What does this mean? Why is that not, and so on and so
on. That will tail off soon, but we're nearly, nearly there. And then when we do that, we're then
moving on to making sure we embed anything that we've said or the ways of working we've
proposed to change into local team instructions, standard operating procedures, whatever you use
10
FUJ00243263
FUJ00243263
File name: Updates on ways of working PEAK-20210804 - Chris Maving team
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
to help yourselves or new team members to work in a consistent way. We need to move the
content from being in a document and a slide pack into standard collateral. And then we need to
challenge and encourage everybody to try and adopt these ways of working, so that the data in
the system and the process we follow is one that’s a matter of record, and we can rely on the
data. And I'm hoping we're going to get to that point within the next week, maybe two,
maximum, at which point we'll move into the later stages, which is management oversight,
double checks, coaching and guidance help and all the rest of it, to make sure that things that
don't look right are spotted, dealt with. And if the process is wrong, it's fixed. And if the
individual was unaware, they're enlightened and whatever it takes to make it work. I think we're
going to see some other process blocks. I can already see one that worries me, which I'll explain
in a minute by way of example, but I definitely want to get to a point where management
reporting to Dan and Wendy on content of our systems is something we would stand by and can
measure week on week, month on month to demonstrate progress. And we can formalize the
reporting we do to post office in relation to live incidents, live defects, anyway, so that we can be
as confident as we are around other things we do, like test completion reports and test progress
reports, etcetera, which you also build.
00:40:07.4
But I want this to come from the system. I click room, I get my answer, I give it them, because I
know the system is telling me the truth. The process block was just one. We regularly will find
faults, identify the fix, and then it can be months and months before it is deployed. The outsider
could say we took ages to fix it. The insider says, no, that's process. And I want to figure that one
out, because I think I'm going to have to ask our business to challenge itself to say, are we happy
with that? And, equally, if we are, we need to make sure that post office is aware and included,
so we do not have a situation where it seems like we take ages. It's by agreement. And so these
things become apparent when you can look at the data. I realize some of you may go, hey, I've
known that forever, but I can see it in the data now, because I'm reporting on it and thinking,
why is that so far in the future? Anyway, that is the end of the story from me. I guess, are there
any observations, questions, blatant gaps? Please.
ANDY PAVIS: It’s Andy again, I’m afraid, Steve.
STEVE BROWELL: Thank you.
ANDY PAVIS: Peak is our primary tool, and you're asking for lots of extra things to be done as
we work with Peaks. How much of this stuff is actually going to be automated in terms of
prompting us to do it?
STEVE BROWELL: So if you at the user interface level, not a lot, is the truth. So the impact
field, if you click on it, will pre-populate the three areas, business impact, status update and next
action to advise you. But it will not say, have you thought about ##LiveA ffecting on this, have
you thought about all the others. What's happening is there are various checkpoint meetings like
BIF, PTF, etcetera, where there is a manual checklist that the chair of that meeting will go
11
FUJ00243263
FUJ00243263
File name: Updates on ways of working PEAK-20210804 - Chris Maving team
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
through that will hopefully catch those data changes if they've been missed. And then there are a
series of management reports, that for the moment only I can see, that is looking at a potential
inconsistencies in data to then allow people to say, could you just check that for me, please? So I
acknowledge it's manual.
ANDY PAVIS: I'm just thinking if perhaps when you're creating a new--or when I am creating a
new Peak and I click send, ifa little pop up popped up and says, does it need this? Does it need
this? Does it need this? Just a load of checkboxes. Then it goes away and sets all those fields for
you.
STEVE BROWELL: And when you say send, you mean you're reassigning it to a different
stack owner?
ANDY PAVIS: So we tend to create our own Peaks for our own work. So we click the new call
button, fill in a load of fields, and we will save that Peak, or we will root it directly from us onto
the first recipient.
STEVE BROWELL: Okay.
ANDY PAVIS: So at that point, none of those fields are set. If you add a little pop up screen
which said, here's a load of checkboxes, do you need one of these? Put a checkbox check in each
one you need, then it goes away and adds it to the right collection, adds this, does that, prompts
you to change defaults and business impact.
STEVE BROWELL: That's a good idea. I'm going to talk to John Simpkins, our system expert,
to see how much of this we could put in prompt, or, you know, reminders, notes, what have you.
Some of the fields already have controls on them, so you can't not set a call type, for example,
but you can set the wrong one, so it doesn't check that. But you're right, we could possibly pop,
even if it's just for a short period of time, to help learn the logic, just say if this is a live defect, do
this. If this is a--yeah, I'll ask him it's a good idea.
ANDY PAVIS: That’s quality input for you.
STEVE BROWELL: It’s outstanding. Give that man an award.
CHRIS MAVING: The easy ones come from me, Steve. So where's this slide pack? Can we
keep hold of it? Have we got, you know, cause generally speaking, anything to do with Peak--
STEVE BROWELL: It’s on my laptop, and you can just take a copy. No, I will put it
somewhere. I'm sorry, I'm being flippant. I will put it somewhere central, because you can come
back to it and have a look. I can also put the latest document that's been shared. It is being
updated ever so slightly, but I can do that too. My only ask would be account internal, please,
just so we don't end up with folk reading it that have not benefited from our input and they come
to a conclusion we did not mean.
12
FUJ00243263
FUJ00243263
File name: Updates on ways of working PEAK-20210804 - Chris Maving team
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
00:45:02.3
So yeah, I will find a place where we can all see it. I'm sure Teams is the answer here, but I'll ask
someone to help. You're not the only one to ask. Everybody is. Excuse me. That was an easy
one. Second easy one. Ready. Good. There maybe isn't a second easy one. Okay. Any other
questions?
ANDY PAVIS: Not for me. Thanks, Steve.
13