Filename: End-to-end peak process changes overview-20210809 - Matt Swain
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
STEVEN BROWELL: ...that can't join us. Or if, for some reason, I say something that
doesn't make sense at the time, and you want to go back and have a look at it. Am I right
to assume that most of you spend your time in Peak and not TFSNow?
MALE: No, everything I do, Steve, is in TFSNow. But I'm sort of from the change team,
not release team. So I'm just here to observe, really.
STEVEN BROWELL: OK. There are a couple of sections to this, and I was just trying
to determine where it would be best to go spend time or not. I'll judge it, and if we seem
short on time, I'll speed through a few bits. But a couple of all-hands calls ago, I
mentioned that there were a series of improvement initiatives being spun up. And these
were because, having completed something called the Horizon Audit, which Post Office
commissioned us to do to explain certain ways of working, and having answered quite a
few questions for the public inquiry, and also answered various questions from new
incoming Post Office employees and their chosen partner, KPMG, at the time, there were
all sorts of things that we were providing responses to, and good responses. But we had a
few things in the back of our mind which were, “that doesn't sound quite right,” or “we
should probably look into that.” So at the time, we just made a note. And then when those
pieces of work came to a conclusion, or quietened down anyway, the decision was, now
we should spend a bit of time looking at how we can make some improvements that suit
us, that improve the ways we work, so that if we explain anything in the future in certain
areas, we would do so far more confidently.
So I'm going to talk about just four of the streams. These are the four that I mentioned at
the last all-hands. In essence, they relate to the use of TFSNow, the use of Peak, the
processes that we use when we use those two systems, and the processes that connect the
two of those ways of working together, because they align, certainly for incidents and
investigation-type work. And then how we use the systems to then drive the decisions
around certain key meetings that we have, like our Business Impact Forum, the Customer
Business Impact Forum, and something called Horizon Defects, which I will explain
later. But the goal here is to find ways to use the systems in a more structured way,
whether that be usage instructions or processes, so that we can rely on the content in them
and use that to drive reporting on progress, direction, trends, activity, and so on. Because
to some degree, that was not happening well enough. I'd realize, in part, it clearly is,
because we're able to work every day and the teams function well. But there were certain
bits where it wasn't that clear. And I'll explain some of the key differences or changes
we're making.
It is all documented. Currently it's kind of a working document. So as we've had
discussions about the observations made, some of those observations proved to be wrong
so we crossed them off. New things came up because we were talking and we've been
building a picture of what we would like to evolve to become. That is documented. That
document is on one of the team's channels. I'll post the link after this if you've not already
seen it so that you can actually take a look if you wish. You don't need to though because
FUJ00243265
FUJ00243265
FUJ00243265
FUJ00243265
Filename: End-to-end peak process changes overview-20210809 - Matt Swain
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
the intention is that all of the content that we have written during the discussions will
become part of a new piece of collateral for live defect management, which is really the
heart of how Peak helps the account, and then other things will be embedded into other
documents that are relevant to your teams and the things that they refer to when doing
their work. So the intention is not that the document we wrote that captured all of our
thoughts, good ideas and actions is the only place this will be referenced. It's going to be
embedded into the standard procedures that you hopefully use in your own teams or areas
of work.
So the emphasis here was about getting process agreement and consistency. It became
very apparent to me, certainly in the discussions I was having, that although there was
quite a lot of common ways of working, there were certainly a heck of a lot that were
down to how people had chosen to work because they'd been on the account a while or
they'd done different things. And it wasn't that anyone's doing anything wrong, it was just
it was different and that makes it very hard to then rely on the content in the systems
because you can't be certain it was created with the same intent or by the same process.
So we needed to get a process agreement and consistency in place because that way we
are working in a defined Fujitsu way and probably working better together, which
hopefully is what will happen. Equally the use of the actual tool sets, TFS and Peak, was
not consistent, and what we thought it did and didn't do and where we could get
information from and the links between the two were not always as robust as they needed
to be.
[00:05:00]
So we were looking at changes there. Then the content of the things that we put into those
systems, the incidents particularly, or defect entries and related notes, were also of
varying levels of quality and scope and it meant that you couldn't rely on it. So we
wanted the data to be integral itself so we could run reporting for management, so our
own people, whether you're team leaders, managers or senior managers, it doesn't matter,
the truth is you should be able to rely on the information out the system and be either
reassured that everything is well or be highlighting areas that need a bit of attention and
therefore things that, you know, we could improve. And we've already spotted a variety
of things that seemed like gaps just from the discussions we've had so far, and I think as
we get going we'll probably spot a few others and that'll just mean that we get, you know,
faster, more efficient in different areas.
The other element of this is the customer is asking more questions. How does this work?
What's going on here? And sometimes we're very happy to answer it but we're not
confident in the data, therefore it takes a long time. So the goal here is to build
confidence into the reporting we do to our customer so that we can more routinely share
information. Because if we can involve them more in things we need them involved in,
we can be more transparent, which is a good thing given the criticisms of various court
judgments, but equally we can start to hold them a bit more responsible for things that
FUJ00243265
FUJ00243265
Filename: End-to-end peak process changes overview-20210809 - Matt Swain
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
they just allowed us to do, conveniently so, whereas they should actually be making a call
and be guiding the outcome. So that was what was motivating us. It's about working our
way, getting the data in the systems to be reliable, being much more confident in pulling
reporting for ourselves, and much more confident in pulling reporting for the customer.
That would mean if a future inquiry asks a question, we'd be much more able to answer
very confidently. Whereas previously we had to cross our fingers just a little bit to stitch
stuff together.
The diagram at the bottom is not new, it's a way of working we've had for some time. I
would point out we're talking about Belfast and the HNGX focus for now. Post Office
Cloud will come next, so we're not currently thinking about the ways of working in
relation to Post Office Cloud. And the mission was, with Peak and TFSNow, to evolve
rather than create a revolution. The tool sets are in place, they're embedded into most
teams. The goal was, let's see if we can use them better rather than change them. That
would just feel a little bit too onerous. So it's all about evolution, not revolution. And the
picture at the bottom is just to tell a simple story that, you know, when somebody raises
something that they think's not right or they need looking into, that is a potential defect.
It's a TFS incident or it's an investigation Peak, which our teams then investigate and
qualify. They may decide nothing is needed because actually it was a misunderstanding,
or it may be that we need to raise a change, or it might be we need to initiate some kind
of fix through our software delivery lifecycle. But at that point we've got a confirmed
defect, so we've got something we definitely need to fix. That then needs to be scoped by
the developers or architects, which then needs to go for approval to BIF, maybe on to
customer BIF, on to PTF for targeting, out to the developers for coding, into test for
checks, and through release and out to live. The difficulty was if we were trying to work
out where are all of the different things, all of the incidents and things we've logged,
where do they belong, which bucket are they in, which part of that continuum are they
stuck at, which ones are the busiest, which ones seem to get stuck the most, if we wanted
to speed anything up, where would we put our effort? And the changes we've been
making are to allow the position on this flow to be much more clearly visible so we can
decide are we happy with the way it's working or do we wish it to work a little bit
differently? And that's what we've been doing.
So there are some new terms, terminology, that's come into play and it's important we
understand it, otherwise we'll obviously be talking to each other at cross purposes. The
first thing is Live Defect. This is something, it probably will appear as an incident, but
it's, it'll be present on a live system. That's the first criteria. Not on a test system, an
internal system, it has to be on a live system and it has to be, or appear to be, inconsistent
with the agreed design or service specification. So it's not as it should be, in simple terms,
and is therefore likely to need fixing. Now obviously at the early stages we don't know,
we just have a suspicion. It's a potential live defect.
[00:10:00]
FUJ00243265
FUJ00243265
Filename: End-to-end peak process changes overview-20210809 - Matt Swain
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
And not until we have done the assessment can we be confident that it is or isn't one. But
to be classified as a live defect, it's got to be present on a live system, inconsistent with an
agreed design or service specification and therefore something we're likely to need to fix.
That will appear in TFSNow and should have a configuration item added of
LiveA ffectingDefect, or a Peak, which has got the ##LiveA ffectingDefect Collection
added. We need to do that so we can differentiate the various other things that exist in
those two systems and quickly spot those which are actual or potential live defects. And it
does not matter if there is a workaround in place, it is still something to fix. The
workaround is great news because it means that the impact is not as heavy, but we still
have to declare it and still have to find a way to work our way through it and fix it. So
that's one important new term: Live Defect.
The other is the Horizon Defects Review. This is a joint working group between
ourselves and Post Office where we have to declare defects that affect or could affect
branch operations. We have to report them weekly, discuss them weekly and the Post
Office communicate them to the postmasters. And these are a matter of high profile
because we were asked this question many times during both the audits and the inquiry
questions. So, first of all, it has to be a live defect. And it can't affect a branch if it's not
on a live system. But Horizon Defects Review, HDR as an acronym, applies if any one of
the following three things are true. If what we're dealing with affects or has the potential
to affect a branch financial outcome, then it's a HDR candidate and we use HDR-Fin for
brevity. But if it could affect the way that a postmaster or clerk interacts with the system,
so on how they use it, whether that be user interface, a report, or some function, then it's
an experience impact so it's HDR-Exp for experience. Or if it affects a customer, that
would be you or I as a member of the public in the branch. If the defect affects you as a
paying customer and using customer then that is also something affecting the experience.
Those have HDR-configuration items and collections depending on whether you're
talking TFS or Peak. And again I realize it's a manual tagging system but we need to do
this so that we can very clearly pick out those which we feel we should disclose to the
customer, Post Office, because they need to disclose them to their postmasters. And
actually, if we fix those fast then we aren't affecting the day-to-day operations of a branch
and that's really, really important, and again we're required to disclose them. As before, it
doesn't matter if there's a workaround. Hopefully there is, but it doesn't matter, it's still a
HDR defect if it is in relation to branch function. And it doesn't matter whether or not it's
still suspected or if it's been confirmed, we have to declare it. And we've been doing that
on lots and lots of Peaks and a number of TFS tickets to make sure that we've got a good
view that we can share with the customer.
Just to give you some indication of scale, there are approximately 18 that we have
recently deferred from releases. So they are defects that we were permitted to go live
with. And on top of that there are approximately 12 others that have been identified in the
course of working through incidents, of which about half of them are related to PBS
because of its partial rollout and therefore an expected number of defects would occur. So
we're not talking about big, big numbers but they're all important.
FUJ00243265
FUJ00243265
Filename: End-to-end peak process changes overview-20210809 - Matt Swain
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
And this is just the same information compressed together, because you may see it in this
written form in some of the communications you've had from your team leads and
managers, and you'll certainly start to see this phrasing in documents that will be
published.
So I guess other bits. So Horizon Defects we've covered but it's a key new term, it is this
joint working party with the customer. Investigation Peaks. The Peaks can exist for all
sorts of reasons as you all know. There are release Peaks, there are all sorts of different
things that help us run our business. But the key ones for me would be it's an
Investigation Peak if someone's logged it because they believe there is something wrong,
it's an incident, and we're still figuring out what's going on. It probably will have a Peak
call type of “L”, but we're still in the investigating stage, we do not know for sure that it
is in fact something that is not right that we should be responsible for.
[00:15:00]
The big thing to point out though is it is not allowed any more to simply create a Peak
that describes something that is wrong that Post Office should know about and not raise a
TFS incident, because that means they will not see it, and that's not in the spirit of the
way we're moving. A Defect Peak is still the Peak system, it's still a Peak ticket. But this
is when we are confident, we know that something is wrong, and we now need to set
about fixing it. It will have a different call type but it will be something we are going to
take through the various forums and processes we have that take something to Deployed
to Live and Fixed. So it’s different to an Investigation Peak where we're still looking into
it.
And then if it affects the Live System, which the important ones will, again, you've got
potential live defects which is something that is on the Live System is inconsistent with
the design or agreed service spec, but we aren't sure; and Confirmed Live Defect where
we are sure. And for a Confirmed Live Defect there will be a Defect Peak. And for a
Potential Live Defect there will probably be — well, there will be an Investigation Peak
and perhaps TFSNow on the linked incident as well.
I'll skip the OTI bit, but KBA, once upon a time we had the acronym KEL. We are
completely removing that language from our vocabulary as fast as we can because it is no
longer a fair and accurate term. It's title, Known Error Log, would imply that everything
is a known error, and it isn't. Many, many of the things in the database are actually
support, hints, tips, guidance, how-to’s, all sorts. They are knowledge base articles and it
is a knowledge base. So we wish to remove and decommission the acronym KEL as
quickly as possible from as many things as possible and move to a more appropriate
description knowledge base article. So I need your help to do that. Although I think if
you've been here a long time certain words become habit. But if we can slowly break
them that would help.
FUJ00243265
FUJ00243265
Filename: End-to-end peak process changes overview-20210809 - Matt Swain
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
So a picture to help tell a story. Let me see if my mouse is working. Okay, so a scenario
could well be that the customer has created an incident in their service management
platform, ServiceNow. They have determined they need our input, so they have bonded
it, causing a Fujitsu TFSNow incident to be raised. The two teams -- Mac in that
particular case if it doesn't need to go any further, and the customer -- can interact and the
updates will flow between the two systems. There is a technology that does that. If our
incident needs help from third or fourth line, then we will pass that on to a Peak resolver
group and that creates a Peak. This is an investigation Peak to have a look at something
or to delve a little bit deeper. It will have a call type of “L”, live incident, if you know it
by its longhand. And again, updates made in this Peak will flow into the TFS incident,
will flow into ServiceNow, and backwards and forwards that goes. It is possible to apply
updates to the Peak that don't go through that interface, but mostly they do. And that's on
purpose so that we can actually work, in essence, seamlessly, transferring status and
hearing feedback from the customer, and it all flows through.
At some point, we are going to come to a conclusion about this Peak. It might be No
Fault Found, misunderstanding, in which case you can close the Peak, which should see
the incident closed, which should see the customers close their incident. It could be that
we actually now need to decide to make a fix. That is, in fact, a defect. It is confirmed. At
this point, we are going to clone this Peak and create a mirror of it, but it will be a Defect
Peak with a different call type #Defect-Identified. And we do that to break the association
of the Peak we're now going to take through our processes and its integration with TFS
and ServiceNow. So having created this copy, which is the fixing defect, the Defect Peak,
we can then put the reference into the Investigation Peak, close it, the incident can be
closed, the ServiceNow incident, if Post Office want to, can be closed, because there will
be a reference at the end of it which says we have confirmed a defect, its reference is PC
12345, and that's the one we're now going to take through our processes. But any updates
we make to this Peak will not be synchronized with any other platform, it is Fujitsu
internal, as we take it through our processes.
[00:20:00]
The other thing to point out, I know that testing, even in release, anyone in the team may
say, “Hang on, can you look at this for me?” and just create a Peak. It is mostly where the
third and fourth line teams live and function and the architects, and that's okay, we can
still create an Investigation Peak for ourselves. However, if it describes a condition that
Post Office should be aware of, you must stop. It must be created in TFSNow, it can then
be referred back into a Peak resolver group. The content would need to be copied across
or reapplied by the person who raised this additional Investigation Peak, and we can shut
that one down. The point here is, we can't have an incident we're working on that the
customer should know about, where there is no flow back to them, or to our primary
incident management platform, which is still TFSNow. So in those occasions, if the
Filename: End-to-end peak process changes overview-20210809 - Matt Swain
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
customer should know, you must stop and use TFS, which will create the link to Peak,
which will see the replication.
If, however, the customer doesn't need to know, it's us needing to look into something for
our own benefit, then that's fine, you do not need to create a TFSNow incident, you can
continue to work as you currently do, getting teams and the specialist to contribute and
working our way through. We may come to a conclusion that actually there was nothing
wrong, we can just shut it, or we may decide actually that isn't a defect and we need to
add that to our to-do list. You don't need to clone that one because nobody else, it's not
linked to anything, so you can simply change its call type. And then what you have are a
series of defects that sit inside our world that are not associated with any other TFSNow
or ServiceNow tickets, which means we can progress them in our own way, at our own
pace, until we fix it. Okay, so let me move on from there. Now...
MATT: Steve.
STEVEN BROWELL: Yes, hi Matt.
Anyway, I'm just wondering, we're missing a number
of the release managers, is this recorded in any way?
STEVEN BROWELL: Yes, yes it is.
MATT: Okay, you're recording now, okay, that's good.
STEVEN BROWELL: I am indeed, yeah.
MATT: All right, great, sorry.
STEVEN BROWELL: Just in case it would help...No, no, no, I've recorded them all so
far, you never know, it might just be helpful.
MATT: Yeah, I mean they're busy with customer stuff, running releases and stuff, so
that's why they —
STEVEN BROWELL: Who could do that? How come that's a priority? Highly
understandable.
MATT: Okay, good, all right, thanks.
STEVEN BROWELL: Yeah, all right. So the first stream was really focused on
TFSNow in relation to incident and problem. I think I've already made the point that if
we're working on an incident POL should be aware of, it has to be a TFSNow incident
FUJ00243265
FUJ00243265
FUJ00243265
FUJ00243265
Filename: End-to-end peak process changes overview-20210809 - Matt Swain
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
and it has to be bonded, so that they can be kept up to date throughout the course of
whatever it is that we're doing to bring it to a conclusion. But the more important thing
we've done is we no longer add Knowledge Based Article references or Peak reference
numbers into the body of the TFSNow incidents that the Post Office see. We clearly still
have those links but they are private Fujitsu references. And the point is, the body of the
incident should contain all of the relevant information to allow the customer to
understand what's going on and what appropriate action needs to be taken. They should
not need to ask us for a copy of a KBA or a Peak in order to supplement what is going on
in a service management tool set to come to the right conclusion. So we are instead
adding the relevant bits of a Knowledge Based Article into the body of either the TFS
incident or the Peak. And if there are associated Peaks then we add the body of the
content so that the information that flows through the systems makes sense in itself and
we cease the need for the customer to ask for copies of entries in systems which are ours.
And that's an important distinction and the Mac team will be keeping their eye on that
and making sure that we stick to it. That only relates to bonded incidents, by the way, so
if it isn't bonded to Post Office we can continue to work exactly as we would see fit. But
just be aware if it is something that is linked to a ServiceNow incident the Post Office is
tracking, we are not going to be adding references to KBA numbers or Peak numbers. We
are going to put the actual content in there so they do not need to know that we're using
different systems to run different ways of working.
A few other comments here. The Summary field, which is the quick description, it's also
called the Summary in Peak.
[00:25:00]
Because we're now going to do increasing amounts of reporting out of the system that
people at management levels and even at the customer level will see, the ask would be if
you can please make it as clear a problem statement as you possibly can. I've read some, I
don't understand what they mean. You may do, but sometimes I don't. So my ask would
be, to the extent that it's possible if you're creating a new entry make it something that
everybody would understand not just you.
Equally, avoid providing updates independent of the systems by email and such like.
Please instead embed it within the Peak or the TFS ticket such that that is the full and
complete record and we avoid Post Office thinking that if] don't like what I read or I
want more information all I need to do is give somebody else a nudge and they'll give me
their view and that's the one I'll act on. I’d rather it was in the system, or systems, and
that that is what people were looking at. We all have a common understanding at that
point.
And the other one, is less qualified individuals are going to be reading all sorts now, and
I've read many incidents in both TFS and Peak recently, and I confess I sometimes don't
really understand what's going on. And I'll put that down to lack of skill in part but
Filename: End-to-end peak process changes overview-20210809 - Matt Swain
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
sometimes it is just so terribly worded that unless you were the person that wrote it, it
isn't clear. Just be aware, lots more people are now starting to pay attention and it would
be great if the language and style of writing considered the less qualified were reading it
and it was more helpful in that way.
And then there isn't a particular field in TFS that we can use to give a succinct single
summary of what's going on. Which means therefore you've got to read the summary,
you've got to read through all of the entries and come to what you think is your
conclusion. And that sometimes is wrong because of course you're not as close to the
details. So the ask is, not only write things that are slightly easier to understand for
anybody but don't be shy of embellishing an update -- rather than just check “looks okay
to me” -- with something a little bit more rounded that if somebody read that would go,
oh, I get it. So you may have to say, “I've now checked this, this, and this, and this looks
okay, I think the next sensible thing to do would be to pass it on to Fred,” or someone
else, because it makes sense then as a reader. So just be aware, if you can help the
ignorant like me understand something, then please put a few more moments in and fill it
in because it will really help. It also avoids Post Office asking additional questions when
we could have nailed it first pass. So that's the ask. Mostly it's about making sure that we
don't work on incidents that the customer doesn't see, if they should see it, we keep the
content of the incident as complete and integral in its own right, and we use, to the extent
that we can, plainer English to avoid misunderstanding or follow-on questions. Sounds
simple but it's important.
There are various other things that we can do with the system. If it's bonded you can't
touch category and subcategory or you'll break it, the bonding breaks, so we don't do that.
I don't think the system will stop you; however, I don't think it's something that most
people would do, but it's just a word of caution.
We do have open and closed categories. If you're in Peak, you're very familiar with
closed categories or response categories. Not so much in the case of TFS. But we're going
to increasingly use those to get better visibility of where our problems typically come
from. Problems with a small “p”, incidents, as something logged, so we can start to see
where we should focus our attention.
And we've added some new configuration items for the LiveAffectingDefect and for
these Horizon Defect Review candidates, so that we can tag things and make it more
obvious that they need to be considered.
The State field is also important now. That's a field that allows you to say, I think it says,
open, work in progress, researching, acknowledged, suspended, fix in progress. There's
various values. They're important. This field is not new, it's been there forever, but the
great thing is it allows us to work out from the earlier slide where you are on that
continuum. Is it being investigated? Is it confirmed? Are we in the fix stage? Have we
FUJ00243265
FUJ00243265
FUJ00243265
FUJ00243265
Filename: End-to-end peak process changes overview-20210809 - Matt Swain
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
fixed it? When did we fix it? All of that becomes you know trackable. So that field
becomes much more important.
I'm going to do some work around suspending of incidents because we've allowed things
to linger and I don't think we need to. So we're working on some rules that would give us
permission to close those suspended incidents which are of no value to us to leave open.
So we will not necessarily leave them open just because Post Office wants us to. We will
clear down the system so that it doesn't clutter. And obviously there will be various work
instructions and local procedures updated to reflect these comments that I've just made so
you don't have to remember the slide where this is just a summary of the things that we're
doing.
[00:30:00]
Dive across to Peak now. There are some new fields in Peak. Depending on what you do,
you may never need to fill these in, so if you're in investigation phase or you're in the
kind of third line, early fourth line teams, then the first few fields, the first three are
probably more relevant. But we are now able to capture the POL Problem reference. So if
we know that Post Office is tracking this Peak, perhaps because it's a defect that is on
their watch list, we can associate it with their reference number, which is helpful, because
it means at least we can see that they have an interest, and when we provide reporting,
they can quickly associate the report with their own views.
We now also have our own Problem reference, because as you know, although TFS
incidents can be linked with problems, Peaks can't, so we've enabled a new field which
allows Matt Hatch to see the association of a Peak to a problem record that he's working
on, which is also helpful.
And then a new field, Workaround. We've always looked for workarounds, and if we've
come up with any we've written it in the body of the messages and updates and we now
have a specific field so I can query it. So if we have managed to think of a workaround
that mitigates the pain that people are experiencing, the field needs to have a yes/no in it.
Well, a yes if you've got a workaround, a no obviously if you don't, so we can query it.
And then another tab, which I think for many of you on this call the Release Management
tab used to be quite light, it only had a few things on it. Well, we've made some changes,
and sorry if this looks quite small, but don't worry, if you go into Peak and click the top
righthand tab, you'll see it. The changes we made were to allow us to capture mostly
things related to BIF, Customer BIF, and PTF. So the dates of those meetings are held at
the bottom, and the discussion or the outcome of each of those sections is written in the
bigger boxes at the top. The point was to move more towards the system has all the
information in it, and to build the picture we don't have to open separate minutes to see
which ones were discussed, to see what the outcome was and what the next action was. It
should be attached to that Peak in the system. I do acknowledge that sometimes putting a
10
FUJ00243265
FUJ00243265
Filename: End-to-end peak process changes overview-20210809 - Matt Swain
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
set of minutes or at least an outcome together is helpful, but the purpose was, the system
is all seeing. We do not need to try and stitch Excel spreadsheets, Word documents,
PDFs, things on SharePoint sites, to the things that exist in the platform we use to manage
these things.
And the other thing we did is... Most of these edits, by the way, would be done by those
that chair the meetings that we're talking about. Many people would have no cause to
need to edit this section at all. This is a BIF chair, PTF chair, CBIF chair responsibility.
But the other thing is, to decide what goes to customer business impact forum tended to
be discretionary. It probably was largely consistent in the way it worked, but it was never
entirely sure why. So we have decided that a set of specific conditions, if met, will
determine whether we need to bring it to the attention of the customer. And if any of
these conditions are met and they can be ticked, the system will record it. So we will
know that it was a candidate that needed to be taken to our customer business impact
forum. Again, we can see by system query, what should have got to what forum, what
was the outcome of each one, what date did it happen? And it's all there and we can start
to query it and use it to influence how we move things along that arrow continuum and
how we actually drive things from beginning to end.
There are some new field values in Peaks. The fields aren't new, but there are some
additional choices in the dropdowns that you would use. So Call Type never used to have
“#” Defect Identified. That's the single new entry. This is for those defects that will
probably have carried that live defect tag for some time, but this is when you've decided
this is definitely something that needs to be fixed. So we are now either cloning the
Investigation Peak or changing the attributes of a Peak we raised internally. And those
are the ones that we need to manage through our process as fast as we can. So having
confirmed the fault, our goal is to fix it as quickly as process and rules and so on allow us
to. But we ought to know that it's progressing at a pace appropriate for its severity and the
constraints that we have upon us.
Collection is an existing field. There are actually three new values in there. One is this
##LiveA ffectingDefect. So the moment you think this is present on a live system, is
inconsistent with the design or service specification, and it looks like something we
would have to fix, give it that collection.
[00:35:00]
Equally, if it could affect branch operations, whether that be financially or by the
experience we create for a postmaster, then add one of the HDR collections too, because
that will drive reporting another activity. You're not alone in doing that, by the way.
There are various crosschecks happening constantly that may spot something and come
back to you as the originator and say, “Does this affect branch operations? It would
appear to, based on other criteria we're querying.” So I know it's manual, but there's
various crosschecks. These are also double-checked when it arrives at a BIF meeting. So
11
FUJ00243265
FUJ00243265
Filename: End-to-end peak process changes overview-20210809 - Matt Swain
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
that is checked, [PH 00:35:37] Mick, currently, who looks after that for us, will challenge
those people bringing a Peak to BIF and say, “Should it have these attributes on it?” And
if it doesn't, if it should, then they can be set so that we keep the system in the right state.
Same doublecheck, I think, happens at PTF2. So there's various points at which people's
best efforts are doublechecked in case they missed it, because people will, and that's not a
failure. It's just it'll take a while before it becomes habit. And sometimes you're thinking,
should I, shouldn't I? My recommendation, if in doubt, put the flag on, put the collection
on. I'd rather take it off because we decided you were being a little bit pessimistic, than
realize we missed it because you were being optimistic. Better to work the other way
around for me. So if in doubt, put it on, and otherwise leave it.
There were two values in target release, which we are quiescing, so Requested For and
Released At. And I do that with some confidence. There are only, I think, three Peaks in
the whole system with one of those values on them. So as something not used, that was
just a cleanup opportunity. So Requested In, Proposed For and Targeted At are the
predominant ones that we will police in order to see things move from start to finish.
Some fields which have been there forever are really important now because we're
running reporting. So Call Type clearly is because that's where I spot the defect
identified, the # Defect Identified setting. The Summary field, because that's the thing
that succinctly, hopefully, describes what this is about. Impact, which there’s a tab at the
top called Impact, and we're hoping eventually to do this for all, but for the minute we're
only doing it for the Horizon Defect Review Peaks. This is very, very few of the total.
We are writing content to describe the business implication, the status and the next
action. The theory is, this is a sufficiently succinct description that the person reading it
will feel informed and have an unlikely need to ask more questions.
And if I can just find the one that's the magnifying glass, and I can't remember if it's that
one, I'll zoom in just briefly here to give you an indication of the kind of things that we
will put in there. The audience you have to consider is a very senior manager or the
customer. Would it make sense to them? Does it show us in the best light? Does it clearly
articulate what we've done and what we're doing next? Does it give confidence we are in
control?
Now what happens is, if you set the HDR collection, then it will come up on a report that
we run. And having done that, then I will take a look at this text, and if it's not as good as
it could be, I'll work with the person or one of the team will work with the person and
help them write it better. So don't worry if you missed it, we'll catch you when it's
relevant, when we're going to have to use it in external reports.
Priority has always mattered because that should drive our behaviour and pace to fix and
obviously if we put a workaround in that gives permission to lower the priority.
12
FUJ00243265
FUJ00243265
Filename: End-to-end peak process changes overview-20210809 - Matt Swain
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
Assigned Team matters because I'm going to chase them if I think something's not right.
So if it's in your stack and it's not yours, hand it on, so that the person who should be
doing something has it.
And Product Group and Product are just attributes that allow us to start to see where we
have the more problematic areas in our system and therefore we can start to make some
other decisions. So those fields become important now and I'm hoping we can get them
filled in a bit more often with a bit more attention to accuracy.
This is an example of some information we now share with the customer. This is the
Horizon Defects Review report from about two weeks ago. Again, if I zoom in because it
might be slightly harder to see it, let me just go up here. So they get the Call Reference,
that's the Defect Peak reference, the Summary field, which as you can see, it's important
that it makes sense because if I read, “FAD...”, that doesn't mean a thing to me frankly.
To a specialist that's probably incredibly helpful. I would add that's probably been
derived from a Post Office created incident. We didn't choose it, they did, maybe it
makes sense to them.
[00:40:05]
But you can see sometimes how somebody reading it cold might go, "I'm really not quite
sure what that means." But we do share the workaround, where there's a workaround, and
then we share a version of the impact field that describes what's going on. I think the
previous example took the second one down on the list, but there are others. The point
being that we try and succinctly summarize what is going on. And that's what they get.
They don't get a copy of the Peak. They don't get a copy of any Knowledge Base Articles.
They don't get a proper copy of any problem records. They get the summarized
description in the Impact field plus the Summary field that describes it. They may ask
more questions, but the skill comes when they don't. That means that we've done a
sufficiently clean job of explaining what's going on. And the only thing left is, where are
we up to? So all you'll get is, I mean, these top two have got releases targeted so we're
just waiting for those. Others may need a bit of chasing. This particular one is pending a
customer decision, but it's in their camp. We can do nothing. We are waiting.
Some other fields that are important. Root Cause, that's really helpful, tells us what the
conditions are that seems to be what type of fixes do we seem to find ourselves having to
do. Been there forever, that field, not always used in the same way. So we're seeking to
make that a bit more consistent. And there are certain values for that field, which for me
denote No Fault Found. So actually when these settings are on, and I'll summarize them
on the next slide, it's really important because it gives me permission to qualify them out
from things that we need to disclose as being things that are actively being worked on.
And that's not to chicken out fixing them. That's just a fact. Sometimes you come to the
conclusion that there is nothing wrong, that it was caused by a condition that is not us or
the system, perhaps the user, perhaps a poor instruction or something of that like.
13
FUJ00243265
FUJ00243265
Filename: End-to-end peak process changes overview-20210809 - Matt Swain
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
And there are also Response categories, which they vary from open to pending to final to
closed. Open means it's just been raised. Pending, somebody's working on it. And there
are many pending states, all of which can continue to be used just as they already are.
That would put it eventually into a Ready to Release. And actually, Release Management
should be moving the status to one of the final settings, followed by the call logger then
deciding to close it. And just the same way, there are some which means, “Our
conclusion is no further action was required, and therefore we consider this to be no fault
found.” So we will take those off our tracking list. These are not new values. They've
been there all the time. I'm just picking out the ones that from the application support
strategy are denoted as No Fault Found.
There are various field values here. If you use one of those, because the Peak does not
make its way through to implementation, testing, etcetera, then we will be taking these
off the list as qualified out. So they're in there as well.
And then the final part was to make sure that when we run our meetings, our BIFs,
CBIFs, PTFs, and this Horizon Defects Review Meeting, we are driven by the system.
The data in the system determines the action. So if it's going to BIF, it'll have a BIF
action on it. If it's a Peak that's been declared as a defect, and for some reason it's not
been to the Business Impact Forum, then I find myself thinking, I realize we could still be
scoping the job. We could still be figuring out what we're dealing with, but I think we
should hurry up. So sometimes the flag will be set to force the discussion so that
something does not get stagnated at an early part of our process because somebody forgot
to set the flag. So the system may now force the flag on, which means I know BIF will
find itself having conversations sometimes with things that aren't ready. But the good
thing is it means that we don't have things stuck in a process and not moving. To give
people a nudge might be helpful.
You've seen that we've got some criteria that now determine if it goes to customer BIF.
That will be asked at BIF. You don't need to learn them. But one thing to point out is, if
you were familiar, we do no longer use the number of man days to determine whether we
should engage the customer. It doesn't matter if it's a 1-day or a 50-day job. If it needs
fixing, it needs fixing. Whether or not we fix it in which release, then the size of the job
becomes important. But the customer doesn't need to make that call. It just needs fixing.
So we don't use that as a deciding factor anymore.
The other intent is that if we bring something to the customer business forum, we will do
so with a kind of mini proposal. We have got one, which we've piloted once. We've not
had any Customer BIF nominations for the last three weeks.
[00:45:05]
14
Filename: End-to-end peak process changes overview-20210809 - Matt Swain
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
But the point here is, we wish to articulate what it is that we want the customer to read
and on which we require them to make a decision. What we can't do is try and open up a
Peak, make sense of it on the fly, which to be fair takes some skill, followed by an SME
discussing various pieces of content and supplementing the understanding. And then the
customer comes to a decision which is based on nothing recorded in our systems. So
we're going to change it and make it like a mini CWO, if you will. We'll just put it into a
structured format with a version number. The customer reads it, gives us a decision, at
least we know they read version 1.1 and they said yes or no. That would be the intention.
So it's clear what did they make the decision on. It then moves obviously onto PTF along
with anything else that came straight out of BIF that didn't need to go to the customer.
And the intention is that the dates of the meetings and re-presentation of Peaks at
meetings and the notes related to that Peak in the meeting will be in the system such that
we can go and query it and check that in the future if we ever need to. And if we have to
share anything with the customer because it's Horizon Defect Review qualifying, it will
come from the system. The flag, the collection will be set and other status information
will determine that it needs to be brought to their attention and we will take the summary
field, the impact field, and we will present that content to the customer. And they will
then be able to track what's going on and we will give them updates weekly.
But the good thing, the other side of this is we can now say to the customer, “Actually
we've given you the information why are you not using it?” or “You seem to have a
misunderstanding of status. Is that because you didn't read what we said?” And I've come
across that so often. But the confidence in our data, the confidence in the report that we
share with the customer means we can hold our head high and say, “We've told you the
state of things, please refer to it, and if that's not what you need, tell us and we will
supplement it next time.” But we can avoid this they think they know something, or
they're tracking it from a different reference number to us, or they've got an update that
wasn't in the system that they heard from whoever they spoke to last, we can break all of
that and put it into the system and drive it that way. And that's how this kind of comes
alive. That's another copy of the report.
The stage we're at right now is explaining the changes. Some of you will have heard bits
through your management team who’ve been helping with the discussions already and
some of you who've very kindly been helping put right some of the data and entries that
need to be brought to the new standards, if you could call it that, for the consistency that
we now want. There have been lots of those and I've been a proper nuisance. But
hopefully if we catch up with all of that, then there'll be far less of it because we'll fix it at
the point of logging and the point of transferring it along to the particular forums we run.
So that's a kind of one-time activity. Once we've done that, we need to embed it into the
documentation that drives the way you work or is a statement of how it should be done.
And then we need to challenge and encourage our staff to work the new ways, because if
the data is put in the system and the processes are followed, then actually we won't need
to police it too heavily. So that's where the effort really is going. And the sooner we get
to that, which I'm hoping we can get to imminently -- I think we're mostly through many
15
FUJ00243265
FUJ00243265
Filename: End-to-end peak process changes overview-20210809 - Matt Swain
Client: Morrison & Foerster (UK) LLP
Job ID: UK0155456
Date Due: August 7, 2024
Transcript by TransPerfect
of them -- but if we can get there in the next week or so, then I think we can start to rely
on some of the reporting. Wendy wants to put some in the management packs that she
has, Dan wants some in his management pack to go to Wendy, of course, so that we've
got succinct views. Not to catch anybody out, but to be honest about whether it's working
or not and find out where the process blocks are and things that need to be done. And
then we can start to be more confident and formalize some of this reporting with the
customer. Because they're not that great at this, by the way, and I think some of our
content is far more reliable and dependable and gives a much clearer picture of what's
going on. But there's the goal.
Now, what I didn't do in all of that was personalize that to your particular team area or
responsibility. And I guess I'm dependent on your management and leaders helping me
do that and the documents that get updated. But in terms of an update of what we've been
doing, that's my conclusion. And if there are any questions, please feel free to ask. Even
if you've spotted something that you think “that's just silly,” please say, because you
might be right.
MALE: Thanks, Steve, has anybody got any observations? Silence.
STEVEN BROWELL: It's normally like that. I've said a lot and I'm just going to close
this off.
MALE: I mean, the reality is once you start using it you'll probably...well, for those
who are using it you'll...
16
FUJ00243265
FUJ00243265