FUJ00243267
FUJ00243267
Filename: End-to-end peak process changes overview-20210812-Matt Swain.
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
STEVEN BROWELL: OK, right, so let me get going. A month or so ago, we had an
all-hands and I shared that there were seven streams of work that we were kicking off.
And they were, because as we had done some recent Horizon audit work with Post Office
to explain certain ways of working, and as we'd responded to some of the questions from
the public inquiry, we had managed to respond well, but in so doing had identified some
areas of weakness that certainly needed to be looked into. So they were parked. And then
when we finished all of that work, we decided we would put it into streams of activity
and work with various members of the teams on the account and just make sense of those
observations and check whether or not they warranted anything to be changed.
And I'm only going to cover four of them today, and they're the four I mentioned at the
last all-hands, which relate specifically to TFSNow, Peak, the ways of working in both of
those systems, the ways of working across and between those systems because they are
intertwined in some places, and then how we use the information that we put into the
system to drive the reporting we give to certain key meetings, like Business Impact
Forum, Customer Business Impact Forum and the Horizon Defects Review. All of this
really around much more clarity in handling faults from perceived to actually confirmed
and then released. That was the thing we were struggling to articulate because it touches
so many teams as it moves through the account. We didn't have a nice joined up way of
working.
There is, in fact, quite a lengthy document, which is on the channel that I published. I'll
put the link in at the end of this session for you as well. You don't have to read that
document, but you're very welcome to. The reason you don't need to read it is the
intention is to turn that into a new document that will be placed into dimensions called
Live Defect Management. And any other comments made in that document about
changes to ways of working should be reflected into updates to local process documents.
So you don't have to read the document itself. It should make its way into things that you
naturally refer to. And then a new artifact, the Live Defect Management document, which
will be in dimensions.
So the emphasis here was trying to get to process agreement and consistency between
many different teams that play a part in making this all work, because by doing that, we
would get to a confirmed way of working that suited us and we could get rid of the little
gaps and niggles that we'd spotted, and therefore we'd be a bit more efficient and working
better. So we needed to get the processes from the very beginning to the very end, better
aligned, so things naturally followed through instead of getting stuck in different parts of
the business or different teams.
We also were keen to make sure we had a common understanding of the usage of
TFSNow and Peak in relation to fixing of defects, faults, and recording and progressing
them so that we could rely on those tools.
FUJ00243267
FUJ00243267
Filename: End-to-end peak process changes overview-20210812-Matt Swain.
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
Then we needed to improve the data reliability. So what we put into a TFSNow incident
or a Peak ticket matters, and it needs to be something that we all do the same way,
understanding the importance of the same field so we can start to track and validate
what's going on. And I'll show you that. That's the whole point of what we're going to
cover in a moment.
That would give us enhanced management reporting. The difficulty we were finding
when we were trying to explain this, particularly for the inquiry, is that extracting data
out of Peak in particular was quite problematic because of the fact that people had
updated things in their own unique way. And although the detail perhaps was great, the
truth is you couldn't pull a report to say how many have we got of this type that are in this
state that need the following doing to them. You just couldn't do it. I think you can now,
but that's been quite some hard work by many, many people.
The other thing was that it would allow us to find areas of improvement. You know, this
is certainly an opportunity to do things better. We've got obviously the court case
comments that have been made alleging we were good or bad at different things. Whether
they're true or not, it's not really important. But where there are things that we know we
can just do better, this was our opportunity. And this is definitely one of the areas that we
were challenged on, and I think we've now made the improvements.
[00:05:00]
And we needed to build out our confidence in sharing information with Post Office. They
have an increasing appetite to know and to see and to be involved, which we would
applaud, assuming we're happy to do it, of course. The difficulty was we couldn't
necessarily do it by sharing information out of our systems because of its inherent flaws.
So it's all very well them asking how many defects are there and what's going on. But if
we can't confidently pull a list and then pull the list the next week and show change, then
it would be difficult. So that was important. And if we can give them confident reporting,
then we can reasonably expect them to share some of the responsibility in the decision
making. It isn't all on our shoulders. It needs to sit with them. But if you don't give them
something that they can make a meaningful judgment from, it would be unfair to then
expect them to make a decision. But we are seeking to be a bit more transparent than we
have been so that they feel far more engaged and we can ask them to make some calls.
This is relating to the Belfast HNG-X infrastructure and environment. This is not yet
covering Post Office cloud. That will come, but we're not there yet. And the other thing
to point out is we intended to take the Peak and TFSNow platforms and evolve them
rather than fundamentally change them. So it's about evolution, not revolution, because
so many teams are dependent on the systems. It seemed far more sensible to improve
what we've got than to think about changing them for something different.
Filename: End-to-end peak process changes overview-20210812-Matt Swain.
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
The arrows are not a new process. They're just a picture of what I believe the current
process is. And it’s shared because we need to make sure that things go left to right as
efficiently as possible and we know where they are along that continuum. So we start on
the left. We may get a TFSNow incident or we may raise an Investigation Peak because
something doesn't look right. At that point, we have a Potential Live Defect, if it relates
to the Live System, of course. That needs investigating, qualifying, and it may well result
in no action needed or that we do actually need to make a change. Or we need to initiate
the whole software delivery lifecycle and initiate a fix.
So at that point, we've got a Confirmed Live Defect, and that would exist as a Defect
Peak in our model. That is how we manage Live Defects from confirmation through to
deployment.
Then it goes on to the developers or architects so they can identify the solution options
and choices, quantify it so that they can then take it to BIF for an approval, or to customer
BIF if we need customer input. That goes to PTF for targeting. That then goes to the Dev
or Ops teams for the actual fix to be created. Then it gets tested and then it gets released.
And I'm realizing there are probably subtle additional steps in here, but in simple terms,
that's it. The difficulty was knowing where a particular logged incident or ticket in the
system was on that journey. Where have we got the most tickets? Where are we slowest?
Where could we get the most improvements? Where are the gaps? And that's what it was
all about. Making sure that that end-to-end process was something that we were confident
worked and that we could report and show progress on. And that each handoff from
function to function worked and nobody was making up for deficiencies in someone
else's part of the workflow. So that's what this was about.
So there are some new terms that come about that I want to just cover off here. So firstly,
I've said Live Defect. So this is a fault that is present on a Live System. Not a test system,
not a system we use, a Live System, the counter or data center infrastructure. It is, or it
appears to be, inconsistent with what we've agreed the design or service specification
should be. In other words, it shouldn't be like that. Therefore, it's a fault that's likely to
need fixing. If that is true, and it doesn't matter if there is a workaround -- the
workaround is great because it helps us, buys us time really -- but we still need to fix it.
It's still a Live Defect. And if it is a TFSNow ticket, there's a configuration item called
Live Affecting Defect, which is attached to the incident. Or if it is a Peak, it will have a
collection added of ##LiveA ffectingDefect. So we can be very clear when we're looking
at a Peak or a TFSNow ticket that it is in the category of a Live Defect. It doesn't matter
if we haven't confirmed it yet and we qualify it out later. But at the point we believe is
present on a Live System, it is inconsistent with the design or service spec, so we should
probably be putting it right, it's a Live Defect and we tag it so it's very easy to find and
report on it.
[00:10:07]
FUJ00243267
FUJ00243267
FUJ00243267
FUJ00243267
Filename: End-to-end peak process changes overview-20210812-Matt Swain.
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
There is a second level. So not all defects are discussed with the customer. Many of them
are with us to just sort out in our own way, our own pace, as we see fit and as is right. But
if that defect could affect branch operations, because it can affect the branch financial
outcomes, or it can affect the way a postmaster is required to use the system, so there's
some feature, some user interface deficiency; or it would affect the experience of a Post
Office customer, perhaps you or I going into a High Street branch, then we are required
to declare those. They go to the Horizon Defects Review Meeting. It's held weekly. We
have to tell them any Live Defects that meet any of those three sub-bullet classifications.
And the way we do it on the system is we use configuration items in TFSNow and we use
collections in Peak. And there are two: HDR for Horizon Defect Review, hyphen, and
then Exp if it affects the experience of the postmaster or a customer, or Fin if it affects
the financial outcome. So if we think it affects a branch, we have got to mark it with one
of these HDR tags. And it doesn't matter if we've got a work-around, all the better if we
do. And it doesn't matter if we're not sure if it really is a defect. If we're still investigating
at that point, we suspect it's affecting a branch. We have a duty to mark it and share it
with the customer. And Post Office share these with their postmasters in these new ways
of working and being a bit more transparent about those things that really affect them in
their day-to-day work. So you will see all the collections and see our configuration items
that are necessary for us to be able to provide our reporting. And if you've seen any of the
emails or documents, it's all collapsed into one view, I just broke that out into two slides.
But in essence, that's a Live Defect and an HDR, Horizon Defects Review defect.
So other things to point out in terms of terminology. We've covered the top one already.
The second one, Investigation Peak. If we have a Peak that we are still not sure what the
cause is and we're investigating, we're looking into it, we're trying to make sense of it and
determine the cause and any required action, that is an Investigation Peak. It might be
linked to a TFSNow incident if it was raised in our TFSNow platform. But the rule is, if
we're working on something in Peak that the customer should be aware of, we cannot do
that unless there is a TFSNow incident also open and linked. So we would have to stop
work, create a TFSNow incident, which would create a new Peak, and we would have to
work that Peak. Again, this is the spirit of transparency. We cannot be working on faults
that the customer should know about if we are not transferring the information through
TFSNow, because it can be linked to their Service Now. So that's an important change to
the ways we work.
A Defect Peak is different to an Investigation Peak. So when the investigation work has
concluded and we therefore have declared something that is not right that we wish to fix,
we will then have a Defect Peak. And I'll show you a diagram in a minute that might
make this make a little bit more sense. That Defect Peak will have no links to TFS. So we
can update it, edit it, and do with it as we see fit to take it through our processes, safe in
the knowledge that any of our updates will not be flowing back to the customer, because
at that point it doesn't matter. We've told them there's a defect and we're going to go fix it,
and we take it through all of our processes.
FUJ00243267
FUJ00243267
Filename: End-to-end peak process changes overview-20210812-Matt Swain.
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
And then Live Defects can be too, they can be potential because we don't know yet. And
in Peak terms, they'll have a different call type. They'll probably be “L”, but I realize
there are some others, but mostly “L”. But when we're absolutely confirmed that there is
a defect, then it'll have a different call type, a hash. So there are different stages we can
go through.
OT1 is just the interface between TFS now and Peak. If you hear it referenced or you see
any markers for it, it's just to show that you've got a Peak that is linked back to TFS.
The bit I want to mention here is Knowledge Base Article. We used to use the word KEL.
That has been slowly decommissioned, if you will, the phrase, not the data store, because
we now wish to refer to this as Knowledge Base Articles.
[00:15:00]
It is misleading to use the word Known Error Log because most of the content in the
Knowledge Store is, in fact, hints, tips, guidance and good ideas and things we've seen in
the past that we keep for record and reference. So I'd like to see us stop using the three
letter acronym KEL and instead move to saying KBA. And you'll see that starting to
appear in some of the changes we've made to the system to get rid of the references.
So here's a picture. Let me talk through a scenario. So the customer may raise a ticket on
their system in service now. If they want our input, they can bond it, which means it
creates a TFSNow incident on our system. And if that's all it needs, our two teams, Mac
in this case and their IT digital service desk, to interact, then we can update each ticket
and it flows nicely between the two. They're bonded, it replicates and the information
flows across the two.
If we need our third and fourth line teams to take a look, then we can assign our TFSNow
ticket to a resolver group, which is in Peak, and that creates a new Peak ticket linked to
the TFSNow ticket. And in the same way as previously, if you make an edit to the Peak,
it flows into the TFSNow ticket. It flows into the ServiceNow. And if the customer does
the same, it comes back. So what we've got is a flow going on, which is all very helpful.
Now, if we have been working with the Peak, it's a third line investigation piece of work,
maybe it relates to the counter application and we realize that that is, in fact, something,
there is a Live Defect here. This is not right. We will then reach that stage we have to
clone that Peak. We clone it so it keeps all of the same attributes, but we give it a
different call type. This is “#”, because it is now the Defect Peak. This is the item we are
going to take through our release management and software delivery lifecycle processes.
This Peak will be updated with the reference number of the Defect Peak that we've
created, and then it will be closed. This TFS ticket will be closed. And, well, the
customer theoretically will close theirs, but that's not our problem. And what we've then
got is a Defect Peak with all of the attributes of the previous one, but not linked to
FUJ00243267
FUJ00243267
Filename: End-to-end peak process changes overview-20210812-Matt Swain.
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
TFSNow. So we can now work on it at our leisure and in ways that suit us. That's our
Defect Peak, Call Type “#”.
Now, we can create a Peak ourselves, usually at third line, fourth line, sometimes in test,
if we see something that doesn't look right. Provided that that does not need to be notified
to the customer, we can continue to work on it as a Peak itself. And if at the end of that
investigation work we determine that it is, in fact, a defect, we can simply change its call
type because it is not linked to a call type of “#”. Because it doesn't matter, we have no
links to break. Both of those would be then different types of Defect Peak. But if we've
created a ticket here in Peak because something's not right and the customer should
know, we have to stop. You must then ask Mac to create a TFSNow ticket, which they
bond so that the customer can see it. We escalate it back to third line and we have to
manually move the relevant content across to this, the ticket that's now linked to the
TFSNow incident and we shut down the other one. Again, we must not work on incidents
that the customer should be aware of without it being something that is in their system.
This is how they find out what's going on in the service management tool sets, TFS and
ServiceNow.
So I'll probably do this bit a little bit quicker, but I'll pick out some points that are
important. What we're not doing anymore in TFS is allowing Knowledge Base Article
references and Peak references to be placed into the ticket. We've obviously got a link
because that's how we manage our ways of working. But if it's bonded to the customer,
we no longer use those references because that way they do not need to ask for a copy of
them, because they do. And the way we're making sure that they don't need to is we're
putting the content that would have been in a Knowledge Base Article or a Peak that we
would have referred to, we're putting the body of the content into the actual TFSNow
incident so they can see it. There is no need for them to ask for copies of things that sit in
systems that are ours.
Some work going on actually trying to get the Summary field better worded. I'll cover
that when I go over to the Peak piece. And again, the statement applies to Peak as well. I
would like to think we would put any information we have about the progress of an
incident in the incident itself, not a separate email to the customer or somebody else
explaining our view of it. Get it in the ticket. So that when anyone says what's the latest
status, you can say, well, it's in the incident or it's in the Peak. And then there is an ask
which carries through to Peak.
[00:20:00]
Please use language that would mean someone like me as an example or someone who's
even less knowledgeable about the system would have a fighting chance of
understanding. We do have a lot of jargon on this account, but if we can write plainer
written English that other people would understand, it will really help. And I'll give you
some examples of where that's important when I get on to the Peak section as well.
FUJ00243267
FUJ00243267
Filename: End-to-end peak process changes overview-20210812-Matt Swain.
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
These, I think I have covered and as you’re TFS users, I'll skip past this one and move on
to the next.
So diving into the Peak space. So there are some new fields in the system. There is a POL
problem reference. So if we know that this is a something that Post Office is tracking. So,
for example, we've created a Defect Peak. It's one of the defects that affects the branch.
So we have declared it to them in the weekly Horizon Defects Review Meeting. We will
hold their problem reference on our Peak ticket because that way when we run reports,
we can see where they have an interest. And when they see the content, they can see
where it relates to theirs. So that's a new field only really being filled in for these Horizon
defects, which is not many of our total. It is approximately 10 of the overall number that
are in the system. So it's not many.
We've also added a Fujitsu problem reference. So Matt Hatch can see which Peaks are
directly associated with problem records that he's managing. Just helps us keep these
things joined up.
Key field that's new: Workaround. We've always looked for a workaround so we can help
buy us time for a fault that's been detected. But unfortunately, it was in the body of the
text that wasn’t written in the details and I couldn't find it. So we've created a new field.
If there is a workaround that mitigates the impact of the defect whilst we work on the fix,
please put “yes” in the field. It just means that we can moderate our degree of worry.
And then there is a Release Management tab. It's the one top right if you're in Peak. I
know this looks like small text, so don't worry, reading all of it isn't the point. But what
we've done with the Release Management page tab is we have incorporated BIF, CBIF
and PTF into the list of fields. And we can now capture the dates of those meetings and
the outcome of them. Therefore, we can always go back to the Peak and find what
happened at BIF or PTF. And we do not need to open up separate minutes and try and
find the Peak and when it was discussed in order to then determine what the outcome
was. It is now stored inside Peak. Eventually, that might mean the minutes are not
needed. But either way, the minutes should be a lot easier anyway, because they could
pull the data straight out of Peak by running a query.
And the other thing we've changed is if certain criteria are met and they're listed here,
then that means we have to engage with the customer. If that criteria is not met, we do not
need to. So that doesn't need to go to customer BIF. The example might be there are
choices about how we solve it. Therefore, we need a customer decision. Or if we do it
like this, they'll have to train the postmasters to work slightly differently. So it will affect
their operations. Those are the kind of circumstances where we need their input. We no
longer care how big the job is. We used to count the number of man days and use that.
We don't anymore. It doesn't matter if it's a big or a small job. It doesn't need a customer
approval. It's our decision that determines it moving on. So that page is quite
FUJ00243267
FUJ00243267
Filename: End-to-end peak process changes overview-20210812-Matt Swain.
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
fundamentally different. But the only people that will probably need to fill it in are the
people who chair the BIF, CBIF and PTF forums, not the individuals who join those
sessions. So that's kind of Mick, Adam and James who would mainly fill this in. So it's
just so you know it's there.
There are also some new field values in Peak. So we've added a call type of “#”. It didn't
exist before, we'd used up most of the other letters in some form so we added a new one.
And this allows us to specifically identify a Peak, which is an actual Live Defect that we
wish to progress and fix. So it will have a different Call Type “#” when we are confident
that we know it's a defect.
There are also collections for live affecting. So that's if it's a Live Defect or HDR, Fin or
Exp if it affects branch operations or could affect branch operations. So those are new
collections to add if you're working on a Peak.
And there are a few target release values that were never used. I only found two or three
tickets with “Requested For” and “Released at,” so we're going to get rid of those or
certainly stop using them.
[00:25:00]
It's now “Reported In,” “Proposed For” and “Targeted At” are the three main ones. And
that matters because when we're trying to work out where we are on that left to right
flow, it tells me things. These other two here weren't really being used, so we're going to
retire them to simplify the list.
Also, because we're now doing reporting from Peak for our own management and for our
own team leads and managers, and also for Post Office reporting, some fields are much
more important. Call Type, obviously. That tells me if it's a confirmed Live Defect or still
a potential Live Defect. So that helps me understand where it's at.
The Summary field, in some cases, is set by the customer when they bond it, which
means it's the Summary field that goes into TFS and the same one goes to Peak. But if
you find yourself creating something and you have the choice of choosing what the
Summary is, please make it as clear and ambiguous as you possibly can. I'll give you an
example in a minute of something that's just plain confusing.
There is also an Impact tab at the top of Peak. It's one of the middle ones. I think it's just
about third one in. And we have amended the structure of that so that it captures three
things. And I'll zoom in on my screen just so you can have a better view of one filled in
whilst I talk. So we're asking that particularly for those that are Horizon defects, those
that we're declaring to the customer, we need a business impact. So how is this affecting
them? Status update, where are we up to? Next action, what are we doing next? And if
we get this right, the customer will read it, say thank you, and move on. If we get it
FUJ00243267
FUJ00243267
Filename: End-to-end peak process changes overview-20210812-Matt Swain.
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
wrong, they will ask many more questions. And that's when it gets slightly more
complicated because then you need different people in it. So if we ever declare a Peak, a
Defect Peak, as one that we are now going to provide reporting on weekly to the
customer, we will be making sure that the Impact field is well written. So if it hasn't
already been done, someone like myself will spot it before the report is generated and
sent to the customer and we'll work with whoever to make sure it's well written. But if
you just build that into your general thinking, it's very hard, you probably all find it. You
open up a Peak or a TFS incident and think, “Where are we at?” Sometimes you have to
read a lot of content to try and figure out where we're up to. And sometimes even having
done that, you'll get it wrong because somebody hasn't put an update in or meant
something different. So I would encourage this as a new habit. If the time allows us, we
should always be able to describe what the impact is, what the current status is and what
we're going to do next. All of it just gives everybody confidence that we know what's
going on. But for now, the Horizon Defects Review, those we declare to the customer
that they share with Postmasters, those are the ones where this field is critical and we'll be
making sure that's filled in. That's about 10 out of 180 marked items in Peak currently, so
it's not a lot of them.
The Priority field is really important. That affects some of the decision making we'll
make. The priority typically doesn't change if it started out as an incident, maybe Priority
A or Priority 1 or such like. But obviously, if you put a workaround in, then permission to
reduce the priorities is obviously granted. And that's helpful because, again, it gives us a
chance to see whether we've got really serious matters to deal with or if they're all
relatively low level.
And then there are some others like the Assigned Team. I think you all know this, but if
it's in your stack, I assume it's yours to action next. And therefore, anything we create on
the system to give people nudges, we'll use that field. So if it's not with you and it's not
your action, put it in the right person's stack.
And Product Group and Product have always been there, but we're going to use those to
get better visibility of the areas of the solution that seem to be the more problematic or
the more volatile and dynamic, if you like, and need changing more often. It just helps
with management reporting and statistics, and we can get better visibility of the inner
workings of what's going on.
This is an example of an extract we now share with the customer for the Horizon Defects
Review, and I'm going to zoom in because it's quite small. So we give them the call
reference, which is the Defect Peak number, the Summary field. So now you can see why
it matters, because if it's not worded very well, like this one here, it's quite difficult to
understand what we're actually talking about. What is this fault? If there's a workaround
and then, oops, I didn't mean to do that, so apologies. Let me get back to where I was.
OK, user error back in the room. Oops, right. That's my own fault. Excuse me. Zoom
FUJ00243267
FUJ00243267
Filename: End-to-end peak process changes overview-20210812-Matt Swain.
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
back in. Right. And then we give them the business impact, the status update and the next
action so that they can see what's going on. And that's what we share.
[00:30:00]
So they don't get a copy of the Peak. They don't see all the other fields. They don't see all
our inner workings and all our thoughts and good and bad ideas. They just get this. And
it's supposed to be sufficient for them to understand. I know what the defect is. I know
what its reference is if I need to ask for further information, but I've been given a status
update and that is it. The meeting takes minutes because they read it and go, “OK,
thanks.” It's that quick. Newer ones take a little bit longer because sometimes we just
have to talk them through what we've written. But we don't share a lot. We share
sufficient to give them the confidence that we have it under control and we are
progressing it through the system.
There are some other fields in Peak that are becoming more important. Root Cause. It's
not always filled in. I wish it was. It would give us a better idea of the kind of things we
have to do to put something right. There are certainly some categories of root cause
which would tell me that there was nothing wrong. So when we've closed it out as a user
error or procedural error or knowledge issue rather than because the system wasn't
working, I consider that no fault found. So I'll ignore those when we run reports of
defects.
And then there are Response Categories below. None of those that you can see there are
new. They're all existing settings, all existing values that you can use. But they have
different meanings or they have more importance than they had before. So if we've
marked it as “program approved, no fix required,” I will assume that is a no fault found,
no action required. Don't need to follow it through to conclusion. It has been closed
because we do not need to take it any further.
And there are a few others in that list there that have a similar meaning, although you
would use them for different reasons. But they have the same meaning as in if it was an
Enhancement Request. So it's not a fault. It's something that needs to be asked for to be
added because we don't currently...it doesn't work like that.
So pulling all of those together, those are effectively the No Fault Found categories and
they are already defined in the application support strategy. So there's nothing new here.
We're just saying that they're actually extremely important to consider. And you'll find
that you may get asked to use these codes if other codes have been used that would mean
I'd have to count them if in fact there was nothing wrong. So keep using the system the
way you did and hopefully be consistent with the document that's referenced there. But
the support strategy, it's all as it is currently.
10
FUJ00243267
FUJ00243267
Filename: End-to-end peak process changes overview-20210812-Matt Swain.
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
And then finally, candidates to go to BIF will be driven by the BIF action being set.
That’s not a new statement, it's an existing one. However, if it looks like we have a Peak
that has been declared as a defect, it's defect identified. It has the Call Type “#” and it
does not appear to have been sent to BIF and it's been open for a while, the system may
force the flag on so that it gets discussed. That avoids us having things stuck with the
developers or architects chatting about what they wish to do about it. It needs to move to
the next step. So sometimes the BIF flag will be set and it might feel a bit out of place,
but it's to force a discussion at the relevant forum to make people think “I do need to do
something with this.”
And if at that forum we determine that it meets one of those checkbox criteria, so that's
on the Release Management tab, so we do need customer input, it will be asked at the
BIF meeting, then that will determine whether it goes to the customer BIF. So it won't be
a question of “do you think we should tell the customer?” There are some specific
questions and the answers to those determine whether it goes to the customer business
impact forum. And again, the system can be queried and we can determine what goes to
that forum and the Post Office should be told.
And what we're also doing when we do that, and we haven't submitted any for the last
three weeks because there haven't been any. But if we did, we now have a mini proposal
form, which is a bit like a small CWO, so that we can give Post Office a clear and
articulated view of what information they should have and expect a decision. We won't
be opening the Peak on screen and chatting it through. We won't be sending separate
emails or having off the cuff discussions. We will have a record of what we shared with
them, what they made their decision on, and then this is recorded for posterity. So that
will happen to any candidates that are spotted early midweek. We'll then ask the relevant
experts to create this one-page proposal form that we can then take to the customer for
their decision.
And as you saw on the Release Management tab screenshot earlier, we now record BIF,
CBIF, PTF meeting dates and minutes, if you will, or the updates within the Peak ticket
itself so that we can query it or check it or look back on it at any point.
[00:35:00]
And we also now pull the defects that have got the certain collection types for the
Horizon Defects Review meeting. It comes out of the system. It isn't a question of, “oh,
we need to mention that one. I must make a note.” The system determines what goes to
the customer. And that again, that report is pulled on a Thursday. We check it and it's
sent to them on a Friday. So we will make sure that it's correct and reads well,
particularly the Impact field where we describe business impact status and next action.
But the better thing about this now is we are more confident in our data and our progress
and updates to the system, which means when we present the information to the Post
11
FUJ00243267
FUJ00243267
Filename: End-to-end peak process changes overview-20210812-Matt Swain.
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
Office, we can do it confidently. But we can also say to them, “I'm sorry, but you don't
seem to have taken the latest update. It's in the incident. It's on that report. Why are you
not using the content we're sharing?” And we've done that a few times because they have
a habit -- or had a habit -- of coming to conclusions themselves or using information from
different sources. And we're saying, “No, you will get a report out of Peak for those
things that we wish to update you on. And if there is anything going on that is still being
investigated, you will have a ServiceNow ticket because we will bond ours and you will
see the updates. Therefore, Post Office, there is no reason why you do not know the state
things are in and the action that's being taken. It's visible to you now.” They obviously
don't see PTF minutes and BIF minutes because they're ours, but they do for Customer
BIF and for the Horizon defects, all system driven. That gives us a better chance of
getting the reporting right for ourselves and obviously better reporting for Post Office.
So here's where we are. We're explaining these changes. This is one of those sessions.
You may have heard some already through your existing management lines. We've been
doing this now for quite some time. And many of you have been interrupted and bothered
to update Peaks and change values and check things. So thank you for doing that. We've
brought most of the data now up to the new standards, particularly for open tickets in the
system. We’re not bothered about historically making changes. I don't want to do that.
But the current set of information in Peak and in TFSNow is now up to date, almost. So it
is reasonable then to start to query it and use it.
What we now need to move on to is embedding some of these changes into relevant
documents, standard operating procedures or whatever documents you have, work
instructions locally, so that it's clear how it affects your teams because it doesn't all affect
you in the same way. And then we've got to ask people to work that way. This is new.
They say it takes 60 days to create a habit. So it will take a little bit of time to continually
ask people to make sure they use the right configuration items or collections, that they tag
things correctly, that they fill in the impact fields, that they put the root causes in place.
It'll take a little bit of time. And to enable that, we need to help management by getting
oversight and asking for a bit of reinforcement of process and guidance. So various views
are available, which will be shared shortly. It will tell me why is a Peak in a certain state
and why hasn't it moved from box one to box two and why has it been closed with a
reason that doesn't seem to make sense? All of those things are starting to be more
routinely looked at so that we can get it consistently better.
But I think we've spotted a number of process blocks and process inefficiencies in doing
this. We've made a few changes. I think we resurrected the 3 node or 3 tier release
numbering system. We also hold release numbers now inside the system, inside Peaks, so
we can actually cross reference go live dates for Peaks. And we've got certain state
changes that affect the way the test teams get their information sent. So there's been all
sorts of things you spot when you get more confident in the information you're looking at
that have helped us make a few initial improvements. And I'm sure more will come.
12
FUJ00243267
FUJ00243267
Filename: End-to-end peak process changes overview-20210812-Matt Swain.
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
But the important thing is we now need to start to include this in one of Dan's
management packs and Wendy's management packs. We're going to start to show that we
have control now of the whole Live Defect management process end to end for ourselves.
And equally, we're obviously now formalizing some of that reporting with Post Office.
Again, out of our systems. Not individuals cobbling something together and putting a few
slides. It comes out of the system. And that was always the goal. Get the systems to do
the work. Keep the systems up to date. Get the processes clear, because then it's nothing
to do with an individual. They’re following process and using the tool. And then you can
actually use the content.
[00:40:00]
And that is a whistle stop tour of the things that we have been doing and changing. And I
guess I will invite questions if I can be clearer on any part of it.
GEOFF: Hi, Steve, it's Geoff here. Just a quick one. I'm not sure if it's maybe out of
scope for this presentation, but you say that this obviously applies to HNG and it's not
quite in scope, obviously, for POL Cloud.
STEVEN BROWELL: Correct.
GEOFF: I'm obviously aware that they use Jira for POL Cloud and whatever. So are you
saying that potentially Peak will be used and TFSNow will be used going forward to
perhaps interface with Jira in some way? Or is that not being decided yet?
STEVEN BROWELL: Definitely not decided. Honestly, I don't know. I want to take
some time to figure out how it works in that new environment. It may well be perfectly
OK, in which case we'll have two processes. That'd be a shame. But we may have two. Or
it might be actually that we've lost control of something that we'd like to bring back.
Honestly, I really don't know enough. I know that Tommy's been doing something in
terms of the release process. But in terms of management of defects and their
progression, I don't know how that will work yet.
GEOFF: To be determined.
STEVEN BROWELL: Yeah, absolutely. But first off, we needed a confident position
with the majority of the things that we're dealing with. It might be that the way that Jira is
being used in Post Office cloud is entirely OK. We just need certain views or reports
pulling from it to tell us what's going on. Or we might need to integrate them, or we
might need to duplicate it, or goodness knows what, I don't know. But we have to be able
to defend our position strongly, I think, and explain the state of things.
GEOFF: Yeah, that's fine. Thank you.
13
FUJ00243267
FUJ00243267
Filename: End-to-end peak process changes overview-20210812-Matt Swain.
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
STEVEN BROWELL: OK. Any others? I realise I didn't personalize this to each of
your teams and I'm relying on your leadership to do that, because some of it will be more
relevant to some of you and less in other parts. So I do need that local interpretation
applying.
MATTHEW: Yeah. So is everybody clear on what they would need to do if they
received a Peak, which was part of the development? So presumably, I guess I think most
of our Peaks, they get triaged by the development team before they actually come to
integration. So it would be [PH 00:42:30] Tarik’s team who would actually look at them
and go, “Hold on a minute, this is an underlying problem with the system.” Maybe
something, I don't know, like a permission or something like that is where the integration
team get involved.
STEVEN BROWELL: Okay.
MATTHEW: So we would think that most of those Peaks would have been dealt with
by then, so that it would have been cloned and the original Peak closed.
STEVEN BROWELL: And I think it will also have the attributes. Yeah, the collection
should have been set well before you get it. But it is possible you get one and go, “Hey,
why hasn't this got a mark on it?” But it should probably have been done if process has
been followed properly.
MAGNUS: So do we have to make a decision, possibly, if it's a live effect in Peak that
we receive?
STEVEN BROWELL: So it probably will. And I say probably, I mean, if it's come
through from TFS and it's gone through to third line, then someone will have probably
spotted that immediately. However, if it was raised just by an internal team, say an
architect, developer, a test person said, “hey, I think this looks a bit off” or “can someone
have a look at this?” then, of course, it might be the person investigating it that comes to
that realization and they would need to set it, set the value on it. And whether that could
be one of your teams, I don't know. I don't know if you are involved at that stage, but
potentially you could. All I'd say is the two antenna I'd ask is if what you're looking at
relates to the Live System and it's something that's not quite right, just check if it's got the
collection. And if you think it will affect a branch, the way a postmaster works, then
check the collections are on there as well, because they're the two conditions that we're
concerned about. And if you miss some, you miss some. It's all right. You know, there's
enough other processes like BIF and PTF and what have you. And the relevance
crosschecks that are running with the reporting and system locks that we're doing will
probably catch it at some point, earlier the better. So just have that in mind.
MATTHEW: Most of our stuff will be collaborative, so we would be checking with Test
probably. They would give us a steer as to whether they think it would affect live, for
14
FUJ00243267
FUJ00243267
Filename: End-to-end peak process changes overview-20210812-Matt Swain.
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
example, because the integration team is just mainly involved with the packaging and the
underlying stuff.
[00:45:00]
So we wouldn't necessarily know because we don't use the system from that point of view
as to whether it is live affecting, but we would be relying on either Development or Test
to help us get that information and update the Peak with it.
STEVEN BROWELL: Yeah.
MATTHEW: And the other thing to state is we don't actually get that many. There's a
few, but not huge numbers because it's not really about changing logic and such. It's
usually more about, as I say, underlying infrastructure that we deal with.
STEVEN BROWELL: Yes. OK.
15