Hello, everybody, and welcome to today's webinar Applied Root Cause Analysis, using

your results to effectively manage risk. So this event is brought to you by Food Safety
magazine, and it is sponsored by Best Sanitizers, Fortress Technology Cleans,
Perfects and Safety Chain. I'm Adrian Bloom, the editorial director of Food Safety
Magazine, and I'll be your moderator for today's webinar. So thank you for joining us.

Now today's presenters with us on this webinar are Doctor Brendan Numera, the Lead
Scientist at the USD as Agricultural Research Service. We also have Deb Kane, Vice
President of Food Safety Quality, EHSS and Regulatory at J&J Snack Foods Corp. We
have Doctor John Butts, Founder and Principal at Food Safety by Design LLC. We
have Doctor Tim Jackson, Senior Science Advisor for Food Safety at the FDA Center
for Food Safety and Applied Nutrition.

And we also have Tim King, Founder and Senior Consultant at Quality Matters, LLC.

So in this 90 minute webinar, the panel will discuss the application of successful root
cause analysis and preview their planned root cause analysis session at the 2024 Food
Safety Summit. I'll rejoin the presenters at the end to help answer your questions that
come in throughout the webinar, so don't forget to submit those in the Q&A and chat
section of the webinar console anytime throughout the presentation.

Also, today's event is being recorded and will be archived on food-safety.com.

So before we turn it over to today's first presenter, Brendan, I would like to share a few
words from our sponsors with you.

Good afternoon everyone. So I'd like to begin our webinar with a quote that I think
really distills what it means to do root cause analysis, and that is that investing the time
and effort to clearly define the problem that needs to be solved is a critical step in
getting to the true root cause. The true root cause is really what makes the difference
between solving a problem and not solving a problem, right? So during the course of
the webinar, we'll be talking about some of the theoretical basis.
Behind root cause analysis.

In a larger sense, why is it important? And we'll be getting very specific in the tools that
you can use to conduct effective root cause analysis, some of the pitfalls you might see
along the way as you're trying to implement a root cause analysis program. And finally,
how do you know if you've done it right, and how do you know if you've solved that
problem? How do you validate and verify that your root cause analysis has really
identified the problem to be solved and has come up with solutions that will help you to
avoid the problems in the future?

So anytime you do any kind of a process in the real world, most of the time things work
the way they should. But we all know that they don't always work the way that they
should, right? There are always going to be problems in every kind of a workflow.
These could be contamination issues, they can be compliance failures or equipment
issues, right. And we all know that very often, sometimes you apply a quick fix, maybe
that's all you have time to do or maybe that's all you're able to do in the moment to try
to get to the end of the shift or you know, to the end of A to the end of an incidental
thing.

But that doesn't really get to the root cause of it doesn't really address the problem that
was causing what you saw. And odds are what you're gonna have is if you apply this
solution that doesn't really solve the problem, a fix that doesn't fix it, you're gonna have
a recurrence of the problem. That means that you've kinda wasted the time and effort
that you used in putting on the Band-Aid solution. You're gonna have that problem
recur with all of its associated costs and difficulties, and you can have impacts. These
are gonna be impacts on your overall productivity.

In your facility impacts on the profitability of what you're producing and impacts on
morale of the workforce, right. If they're continually dealing with the same thing, this
certainly has a long term impact on how you conduct your business. So at the 2023
Food Safety Summit, we had a workshop on root cause analysis and very well received
and it really gave a lot of hands on experience and impractical tools for people to use to
identify what are the problems that are causing the symptoms that we see. And we had
people work through some exercises to put these things into practice.
And there's a lot of value that was in that in the 2024 Food Safety Summit in May.
We're going to be expanding on that, digging a little deeper in some of these root cause
analysis tools you can use to address problems that come up in the workforce. So now
what I'll do is I'll hand this webinar off to Devkane, who will take us forward and talk
about some of the theoretical basis about root cause analysis and its importance. Deb.

Thanks, Brandon.

So why is RCA important?

So can you relate to recurring problems? Right? Have you ever worked on a problem,
determine what you deem to be an acceptable solution, and then have the problem
reoccur?

Right. And you have to ask yourself, was there bias in the problem solving?

Teams often approach a problem with a bias for what is believed to be the best
solution, and this is typically based on them reacting to the most visible symptoms.

Visible issues, which are likely only the symptoms of a deeper issue.

Right. So when a non conformance is reported.

When it Excuse me, sometimes the implemented solution can provide a temporary fix,
especially if targeted toward the symptoms of a nonconformity. This would mislead the
team about the true efficacy of the bandage they've just applied. And if the team
addresses only the immediate visible issues, the symptoms, they're not getting to the
root cause or the core of the problem, and the symptoms will likely recur and that that's
when you'll see that cycle right where you have a problem, a solution, and a repeat.

So it's the fix it doesn't fix. As Brendan said, root cause is the core of the issue or the
underlying cause for the problem, the ultimate reason behind the symptoms. Ineffective
solutions could happen when the problem statement statement doesn't accurately
define what needs to be solved. Or to be comprehensive, sometimes the problem
statement sometimes circumvent the RCA process, and these types of problem
statements might be targeted at fixing the symptoms and not the true root cause of the
Y.

So when the nonconformance is reported but the true root cause is not identified, the
ongoing impact is seen, as Brendan mentioned, implant process and people
efficiencies. For example, if you think you've gotten to the root cause and you
implement A corrective action which might be a process change, then you train
everybody to the process change, then figure out you didn't get to the root cause and
now you have a different process.

Change. Well, now you're training on training, retraining.

And this will cost valuable time and resources and likely chaos and confusion. And For
these reasons, it's important to invest the time and effort to clearly define the problem
that needs to be solved as a critical step in getting to that true root cause.

Brands will likely be impacted if the true 'cause is not identified. True root cause. If you
do not get to the true root cause of the issues you may experience, product recalls,
withdrawals. You will likely lose your consumer or customer trust in you and your
company. This will likely in fact impact your sales and profitability.

You will experience negative press, right? Recalls, withdrawals or these days, it's so
easy for a consumer to post on social media.

And you may also lose your future opportunity. So again, really, really important to get
to the true root cause. And at this point, I'm going to hand it over to Tim Jackson, who's
going to talk about the FDA expectations for the industry.

Good afternoon.
FDA certainly has an interest in industry conducting root cause analysis for a number of
reasons.

We don't specifically require what we call a root cause analysis, but certainly it is
understood in regulation and also in food safety practice that an evaluation is done
when incidents happen. So specific to the Food Safety Modernization Act and see if our
part 117.150, it does say that corrective actions need to be taken to identify and correct
a problem that's occurred.

With implementation of a preventive control that appropriate actions taken when

necessary to reduce the likelihood that a problem will occur, and that all affected food is
evaluated for safety and prevented from entering commerce. It'd be really hard to do
this if we didn't understand actually what happened, to be able to take the appropriate
corrective actions or preventive actions, and also to identify the affected food.

But in practice, as Deb mentioned, root cause analysis could really help in a variety of
areas. So for industry, it could help identify the root causes of problems. It could
determine the help to determine the origin of the and scope of a problem. It can help to
determine whether or not we have the right corrective actions to prevent recurrence.
We're not just putting duct tape if there's a systemic failure or if there's a deeper issue
that we need to address and the methodology could be useful for.

Not just for outbreaks, but also recurrent issues or near misses. So we think of things
on the regulatory side in terms of the signals we see, which are outbreaks. Now
outbreaks to me are a bomb. This is a bomb going off, but there could be a lot of
signals that a food processor or grower or manufacturer have.

That indicate whether or not a system is in or outside of control and where a verification
methodology indicates.

That something has gone off track or is not in control, or where other information,
maybe from customers or other sources for what they find, indicate there's an issue.
RCA is a good way to get to the bottom of what happened to prevent recurrence that
could become an outbreak or could become a more serious issue.

FDA is going to is going to be looking at root cause analysis where we don't have
confidence that a manufacturer or food operator or grower have done their job in really
understanding what was the root issue in an outbreak. So where we have those
relationships, those conversations, if a food food producer or grower has done a good
job really digging into what happened, we don't have a need to repeat that. We don't
make food at the agency. It's really the operator that makes food and has available the
resources to records and personnel and others.

Other expertise that can help to identify what happened, but we'll also use it for
recurring outbreaks. So if we see repeat issues in a particular commodity, we'll take
that information and try to tie together root cause information or what the potential
causal factors are to see if there's an issue that might be common across an industry
segment and if there's some things that should be done across a category in order to
prevent risk. And that would lead to maybe a prevention strategy.

Or other activity that we would undertake along with industry and others.

We'll also use this to evaluate other adverse events such as recalls. We have other
testing that we do from surveillance or import testing. We have firm inspections if we
see repeat issues for a category there. And then there's maybe new or emerging issues
that come up from a foreign entity, maybe an outbreak that happens overseas or some
heads up that comes from European Food Safety Authority for example, or the Chinese
Food Safety Authority letting us know of a new problem.

And.

Some of those activities could spur doing a more a deeper dive or root cause analysis
to try to understand if there's common issues that need to be addressed. The outcome
could inform follow-up actions for us such as compliance actions related to a firm or
category, maybe stakeholder communications or prevention activities such as guidance
development or some research that we would do collaboratively with our partners.
In other segments of industry or academia. With that, I'm going to hand it over to Tim
King, who's going to get into some of the some of the useful tools on RCA.

OK. Thank you, Tim.

And yeah, we're going to kind of take a look now at the methods and the tools that we
generally will see being used in industry to perform root cause analysis. So far, you've
heard a lot about getting through symptoms. You've heard a lot about finding the true
root cause. So I'd like to embellish that a little bit in this session and talk about both the
approach to root cause analysis.

As well as some of the tools that can be helpful and maybe some tips on them. Now,
some of these tools, some of you have probably seen or heard and perhaps some are
just absolutely new to you. So let's get into that now.

Now the first thing I'd like to say first and foremost, when we talk about roof cause
analysis, we're really talking about only one part of an overall process of solving.

And preventing recurrence and it's in the green box that you see here. We'll explore
that a little bit further.

But however, and I like to think of it as the gateway, the gateway to success here is
really finding the right root cause or causes or contributing factors that need to be
remedied.

With process changes in controls so that you can truly trust that you will prevent the
recurrence of the problem, nothing's perfect. Sometimes we miss something and root
cause analysis in this whole process is your second chance to get it right and keep it
right.

So in this slide you see that before you get to root cause analysis, there's a few things
that need to be done.

Obviously you have to have good monitoring and detection out there because that's
what's going to tell you have a problem. Hopefully you find it and not someone else.
And then you need to describe the issue. That quote that Brendan had up right in the
beginning was about defining the problem properly. You know, what is it? What exactly
are we trying to prevent? What happened and how do we define it?

And then you're also going to put some interim actions in place. We tend to call those
containment actions corrections to put a safety net in place so that you can go do root
cause analysis and contain that area from anything happening or getting away from
you until you can make permanent improvements and change.

Once the root cause which comes out of the root cause analysis, you're going to
implement improved process parameters and controls. And then you have to verify and
validate because maybe you missed something. And when you go through verification
and validation that John will be talking about, you'll find that there's still something
going on here that you need to get under control. So root cause analysis fits into a
larger process with some things to do before you get to root cause analysis and some
things you gotta do after root cause analysis.

And you'll be hearing more about that as we proceed.

All right. The next important principle that we have to talk about when we do problem
solving is that we take a process approach to it, OK? You'll hear people say focus on
the process, not on people.

Doctor Deming, one of the big TQM gurus, put it as problems occur because of an
inadequate process management, not inadequate people.

And so when we take a process approach, it means we have to look at six factors that
make up good process management and that's what we're looking at here on the
screen, OK. So when we do root cause analysis somewheres in these six areas, the
root cause will be harboring and you got to get in there and you got to find it and tools
help you do that, OK. For example, manpower, OK, our employee confident, do they
have the knowledge and skills to perform their work independently.

OK, do they have the aptitude to do it consistently? Have they done it enough? If not,
then they should be shadowed or monitored and not releasing their own work
machines. Sometimes machines are in ill repair or they're just not adequate for the job
being done.

And environment. There's a lot in the environment that can affect.

Human performance and have problems occur. You see a few here. Ergonomics,
distractions, a culture of complacency, complacency, creeping in, temperature,
humidity, lighting.

So when we do root cause analysis and we do apply tools to it, we want to make sure
that we're checking in all of these six areas for the possible root cause to a particular
problem that we're investigating.

And you can see none of these really focus on the person. Manpower should be
focusing on competency and their ability to do consistent work, to do, to apply the skill,
and to apply the knowledge in a consistent manner. If they're having difficulty doing
that, it could be something else in the other five areas that are that is causing it that to
be hard to do.

OK, now one more thing I want to kind of put in place here is that when we do root
cause analysis.

We do need to ask answer the question, why did the process create this issue? How
did this come out of the process? OK, that's that has to be figured out. But most of the
time when you get into some of these corrective actions, it also got through detection. It
also passed through QC inspection.
It got away from you. It was put out in commerce as Tim Jackson was talking about, so
that also has to be investigated. Why did it miss it? Why did it escape?

And then the third piece that we always want to look at is what's wrong with our system,
our GMP, our ISO 9001, whatever quality management system that you use or your
food safety program. Are we really doing our program, our system, well enough where
it prevents and keeps these conditions from getting into our operation? Because if that
is weaker, that's inadequate. You're going to keep having these conditions in your
organization.

That you end up having to fix with corrective action. So I think of it as a three legged
stool that if we're going to prevent the recurrence of a problem, we're definitely got to
find out why the process created it, what's got to be shored up in there And we look at
those six process elements, we also got to find out what happened to our controls or
things we used to detect and stop things in their track before they get away from us.
And then the third thing is.

Are we not doing our system adequately enough?

Are we not doing our program well enough? Robustly enough?

Such that these conditions are occurring out in the operation.

So don't think that it's just about the process when you think when you do root cause
analysis, those other two areas need to be looked at as well.

All right, trending now. And probably very important in this whole thing is that we start
to understand human error, OK? How many times do we hear people use human error
as a root cause? You know, you see it. Person made a mistake, The person forgot, OK?

That's not fixable, right? We have to ask why is that happening and when you ask why
is that happening?

And get behind and underneath what we classify as a human error, we start to
investigate what we call human factors. This list that you see on the screen are
categories of human factors that can contribute to human performance, The
consistency of human performance being below par.

Now, bear in mind that people are not automated pieces of equipment. We're not
perfect and we do have a variable nature to us, OK? However, we don't need to create
processes that make that human variability worse.

And factors of the process that make it worse or increase the likelihood that someone
may do X when you wanted them to do Y.

Only goes up if these human factors are in the process, and in a way that they're
excessively causing this deviation in human performance from what you hoped you'd
see as opposed to what actually happened.

A few examples on here Skill aptitude. I mentioned that under competency.

Making sure that people can apply the skill that they have to do in a consistent and
repeatable manner.

In that they don't feel like they have to take shortcuts because the way they're having to
do it is difficult and hard people will take. People want want things to be easy, and if we
make that easy, if we make the right thing easy to do and the wrong thing hard to do.

Then they're going to do the right thing. OK, you have to look at that type of thing. Tools
and equipment. Often times the tools and equipment are inadequate or not available, or
someone couldn't find it, so they use something else.
And as a result of using something else they may not be familiar with, they misused it.
That's an example and just kind of think about factors in the environment or things like.

Dyslexia.

Setting things up where it works well if you're right-handed, but it's hard to do if you're
left-handed. Or people aging or having sensory deprivation in some way. Color
blindness a little bit. Vision's gone a little bit. Hearings going a little bit, or even
language barriers. When you come to communicating and explaining things to people,
you have to realize that all of these things compromise a body of knowledge that we're
calling human factors and we're trying to manage those better.

We talked a lot about this in the workshop of last year that we did and we're going to
continue to talk about it in this upcoming workshop because.

Really the last people are involved in everything we do, and if we can give them an
environment that maximizes their performance, then we're doing the best we can. We'll
have to rely on some detection and controls to make sure something doesn't get away
from us, and we don't have that issue of getting out into the commerce.

So what we'd like to do is just talk about some of the tools. There are three tools that
you see here on the screen that we're going to go into a little bit.

Two of them, those start, there are tools that are very common. You see them across
the industry. You see them used globally. You go to any conference or see any
presentation on root cause analysis and their app to come up. And then we're going to
talk to you about a tool most likely you haven't seen. It's a hybrid of the two called the
cause effect matrix.

So for each one, I'll introduce it a little bit, talk about how it works, show you an
example. OK, we obviously can't get this isn't about in depth training on these tools, but
it's making you realize that these tools can be your friend. You cannot do root cause
analysis by sitting around the table and talking about it.
You have to use a tool because the tool will remove the bias that Deb was talking
about. It'll it'll have you look at things more thoroughly.

And it would. And they're designed to help you get under the symptoms and get down
to root causes in those six M areas that we mentioned before. All right. So let's take a
look at that first one, which is the five Y.

Now I can tell you this is one of my favorite tools. I love the five. Why it's named that
way because you ask why five times and kind of dig down.

And that little blue line is sort of like, imagine you can see things above water. Things
are obvious. Oh, it happened because of that. What happened because of that? But
why did that happen? Well, that's a good question. And so as you get into the lower
wise, it starts to go in and look at things that aren't so obvious.

And oftentimes, that's where the good stuff is. It's in. It's what's not obvious to you.

And it's what's not obvious that might be causing what's obvious to you. So if you just
go fix what's obvious, you may not be getting at that underlying root cause that's only
going to come in, you know, breed another issue later on. All right, root cause analysis.
You know, one of the best analogies is, you know some people don't like weeds on
their lawn, right?

And so you can keep mowing them, you can keep cutting them, but until you get down
and get that taproot out of there, it's just going to keep coming back. That's not an
obvious thing, OK? What's above ground that we can see? And if we just keep *******
at that, there's something underneath there that's going to keep popping things up.

So this process was came out of Toyota. It was a discipline of keep asking why,
starting with the problem statement. To put your define your problem and put that at the
top. Ask why did that happen. Find something that was immediately in the time aspect
or process aspect that made that happen and then and verify that truly did happen and
then investigate why did that? Why did that happen?

Down enough times until you feel like you get at something in those six M areas that
you feel like if we fix that everything above, because it's kind of a chain reaction, the
last Y becomes your root cause. And if you fix that, then the one above, it's not going to
happen. And if that doesn't happen, the one above that's not going to happen all the
way up to the problem's not going to happen.

The reason I like this tool is because it is pure investigation. Sometime I talk,
sometimes I talk about it as crime scene investigation.

Know it's like it's just I love investigating and following the trail of activities until you find
that root cause. What it tends to have you do as you ask each why is go upstream from
where the problem occurred and go back in time from when the problem occurred till
you reach a point up there and back there where you say, aha look what's going on
here. Look what happened here and that led to this these series of events that caused
our problem.

Now a little bit of training helps. Theory these things are easier. They look easier than
they are.

And some people do them really well and some people struggle with them, but a very
good tool. So let's take a look at the example.

OK so here we have a problem. This is.

A healthcare example that in a certain room on a certain night a patient fell out of bed
while sleeping and.

That's the problem, right? And so the team asked why did that happen? OK, why did
the patient? This is how you tend to do it. You asked why did the patient fall out of bed?
And then you start with because the right side bed restraints opened up during the
night. Well, how did we know that? How did we verify that? We looked at the left side,
they were, they were closed. The right side was open. OK, well, why was most likely
they were all set.

Why did that happen?

OK, well, you look well. The other side restraints are not close correctly. So if that's how
this side was closed, the patient can open them up by bumping up against them. OK,
so why was why did that happen? Why were they not closed correctly? While the
technique used by the floor nurse was incorrect for that type of fastener talking, you got
to talk to, the, see what happened, have them walk you through what they did. Not
blaming anybody, just trying to find out what happened.

And then you continue on and maybe come to the fact that the knowledge and skill of
this particular nurse on the floor that night was not adequate to do this work
independently.

In terms of using these restraints.

That person was not familiar with that restraint. So we have something about managing
competency on the floor, especially with travelling nurses coming in. Now that's the
process issue.

It's also possible that an evening someone came around and did their rounds to make
sure all the rooms were set right and ready for the night and they missed that. Going
into that room, they didn't notice that the restraints were not right.

So there's a control mechanism that failed, right? How come they didn't see that? Well,
we have to explore that as well.

So 5 wise, while they look simple, are a little tricky and really require actual
investigation one way at a time.
Verifying something that did happen and making sure it couldn't have been something
else before you move on down to the next wife, but a very powerful tool to use.

Now let me take you to the next example, which is the famous and oftentimes used
cause effect diagram AKA the fishbone. All right, the fishbone diagram is named. It's
nicknamed because of its shape. Looks a little bit like a filleted fish. This tool was
created.

To make sure that when teams investigate a problem or think about what could be
contributing to the problem, which you see in the box to the right, you put your problem
in there that you would explore under all of those six categories, all of those process
elements. Okay. So you see that you have a choice in the cause boxes, which are the
Gray boxes of putting in those process elements.

Someone thought in this one we could add policies.

We have procedures, which is methods, we have people, which is manpower. We

could have also put in machinery and material.

Or environment. But the idea of it is put those process areas on and then go and
investigate and fill in why. How could one of these areas have contributed to the
problem? Get the right people in the room and brainstorm. So this is a brainstorming
tool. It's not a you must do investigation after you use this tool. It's not it's not an
investigating tool, it's a brainstorm to set up the investigation.

Also notice in the bottom there the root cause. A possible should say really potential
root cause 'cause you gotta go verify it, but it can use this little bit of this five Y
technique or YY technique on the fishbone and let me show you an example that will
actually draw that out a little bit more here. So here we're looking at an example of
using the cause effect diagram to try to understand why invoices are coming in without
proper.
PO numbers and PO information on them.

OK. So that's in the effect box. They decide to look at materials, people, manpower,
environment and procedures.

The two categories not on this one as you see in the box above that measurement and
equipment and tools is it being put on and then have the right people in the room have
a cause effect facilitator take one of those areas at a time take materials and determine
is there any way materials could be causing this problem. And whatever people say
you put it up there and notice where it says new employees and audits.

Someone's getting some detail on it. So someone said, what about people? Yeah, well,
new employees. OK, we'll put it up. Why new employees? Because they lack the
training arrow, comes off a bit. So using the YY technique on the fishbone is very
important, otherwise the initial.

Additions like forms and training.

They're too broad and they're too vague. What about the forms?

Flush it out and put arrows off of it. What about the trading, what about the suppliers?
So it's very important to do this branching that we call it on the fishbone to make it
effective.

Now.

There's that branching I was talking about.

Now.
I had an experience with a client.

He.

I like the five. Why? He said. But I'm afraid it'll miss something. It'll go down, you know,
a narrow path.

The fishbone feels a little messy to me. You got something in between? And so he and
I came up with this tool called the Cause Effect Matrix. And this is a tool we used in the
2023 workshop when we gave him a case study. And they did use this tool to come up
with their hypothesis for where the root cause could be.

So it has shape simplicity because it's more linear in shape. You'll see it coming out. It
does cover the same process elements as the fishbone. It allows for some YY analysis,
and at the end it has a way of converging what goes on to this into the most important
areas that the team thinks they should go out and study.

So I'm going to pop up an example now. It's a little bit. It's going to feel a little bit, man. I
guess it's not too hard to read, but this is a filled in matrix, all right. If you draw your
attention to the column to the left, it says seven key process areas. And the 7th one I
haven't mentioned yet, but I will put in design. If like you're in a packed food packaging
business and you design the packaging, OK, well, it could be. The packaging design is
very difficult for manufacturing.

To make it or assemble it or whatever, or put food into it. So sometimes design is

causing problems, so it's the 7th above the 6th. But notice the other six are there with a
little definition of what they are.

Now when you use this tool, you just take one of one of them at a time and fill in the
row going left to right the first column which is a you see a. How could What could be
causing that to happen? So you put your thoughts there.
You go over to the next row which is B, and you say. What could be causing that to
happen?

And then you could go over one more row to see and say what could be causing that to
happen. So it has a little bit of why drill down built into it for each row. Sometimes you
find things in a row, sometimes you don't. And then the yellow column that's to the right
is where I have the team look at everything we said in that row and what should we go
investigate.

A tool coupled in with the right people in the room with experience and knowledge of
their processes.

Kind of knows where to go. The tool just helps them frame it up, document it, go do it,
and then when the report is done, have something tangible to show how you did it. So I
will tend to go to this tool over the fishbone. OK, so this 15Y and one other tool we're
not showing today tend to be my go to tools for root cause analysis. So this is called A
cause effect matrix.

So in summarizing.

I wanted to emphasize that.

You need a tool.

You must understand the tools and gain skill in using it effectively.

You want to be trained on them. You want to get some feedback from somebody who
knows how to use them properly. Because true of any tool, I can give it to somebody
and they can try to use it. They don't use it properly and as a result problems occur,
right?
Having more than one tool can promote more robust root cause analysis. All right, not
everything is a 5Y5Y is nice when there is a smoking gun out there.

And you just need to follow the scent until you find it. But if you go out there and go
boy, there could be a lot of things going on here, root cause and some contributing
factors.

You need to jump on a tool that does a little more broad brush at 1st and then
squeezes down to what's essential. The Fishbone does that nicely. The Cause Effect
Matrix does that nicely. OK, there are other tools out there.

There's 'cause logic mapping is another one of my favorite tool. And of course anyone
who's trained in theories like Lean and Six Sigma, bringing a whole other set of tools
that can help in root cause analysis if those folks are on the team.

So most tool boxes, some get used more than others.

And the two top go to tend to be that five Y and the fish bone. So if you can join us on
May 8th, we'll get into some of these more in detail and give you a little more in depth
experience with them. So I'm going to turn it over to Deb now and she'll take us on from
here.

Great. Thanks, Tim. So I'm going to move us into considerations for success.

First of all, this need you need to be really strong going through this process. The root
cause If done properly root cause exercise will likely get very uncomfortable. So you
must be strong. But the exercise isn't a finger pointing exercise or a blame game.
Remember Tim King had shared with us that very often it's a process gap right and it's
the team approach to figure out the core reason for the issue and.

So it's not a blame game or a finger printing pointing exercise.

Common pitfalls and considerations for excess. So one question facing the food safety
professionals is how can they ensure that the root cause exercise they facilitate will be
effective? And there's several considerations for success to keep in mind when
implementing this process within an organization.

Just like food safety culture, it's tone at the top, right? You need that management
commitment.

The importance in organization places on a project or a process starts with that support
and commitment from leader senior leadership.

They don't necessarily need to be involved in the process itself, but the quality and
outcome is significantly impacted from having that. Senior management and their
awareness and endorsement of the activities will ultimately Dr. the success. And then
when it comes down to implementing the preventive actions or the preventive controls,
right, there's that financial endorsement that comes into play. So what's important to
the leaders of the organization or the boss will import will be important to everyone.

And once the senior leadership supports the efforts of the root cause analysis, it's
important to ensure that you have all inputs considered right. It's a team activity. And I
remember at the 2023 Food Safety Summit, we had tables of 10 and it was a fun
interactive exercise and we were able to walk around the room and look at the different.
We gave them a scenario and we had the folks figure out what the root cause for the.

Failure was.

And the different experiences that they all brought to the problem was really cool to
watch. So it's a team activity and all inputs need to be considered because everybody
views a problem differently. So if you have an operational issue and you have food
safety folks trying to figure it out, you're going to miss those little operational nuances
that the operational folks understand.
Consider the old adage, right? If the only tool you have is a hammer, then every
problem looks like a nail.

So those operational folks are going to add in their perspective of what happened and
you may involve maintenance, sanitation depending on the issue.

Everybody's going to have that significant input when looking at that same operational
failure. Those perspectives are important and that you have to consider those different
factors.

Another consideration for implementing a successful RCA program is to.

Make sure you have the right time allotted, right. Not Tim, I believe was talking about
the complexity of the problem and which tool you use. Sometimes a simple 5 Y will
work. Sometimes you need to get and look at all the contributing factors and there
you're more like the fish fish bone or that cause effects matrix that Tim showed us. And
that's really a great tool by the way. I do like that tool.

Another consideration for implementing the successful RCA program is leverage

existing processes. So if you have your employee health and safety and they have near
miss event.

If you're always going into the same exercises, and you're training your entire
organization to these same tools, and you're all approaching it the same way, you're
going to be more successful. And the more often you do these exercises, the better
you'll get as a team. You have to watch the biases, right? We talked about the biases.

But.

Sometimes there's tools that the drag which tool to use, but again, let the complexity of
the problem drive the decision on which tool to use.
So even if you do have your management commitment, the right tool, you've allotted
some time, sometimes there's still common pitfalls that derail that RCA process. Like
Tim said, that five Y process looks very easy, but sometimes you can get hung up. And
sometimes one of the most common mistakes with the root cause analysis is the
problem statement.

Maybe the problem statement is too vague, or maybe we're defining the problem
solution at as the excuse me, defining the problem as the solution.

A lot of times, again, if the problem is not clearly defined from the beginning regardless
of the tool selected, the RCA team may go down the wrong path and miss the root
cause altogether.

Once the RCA team is assembled, make time. Make sure they have allotted time to
collectively discuss in the line on the description of the problem.

That needs to be resolved.

This will help ensure that they're focusing the correct problem and not just the
symptoms. Remember we talked about if you're fixing the symptoms, the you're not
getting to the true root cause of the core of the problem and the problem will likely
reoccur.

And then again, you'll be wasting valuable time and resources because you'll be
repeating the exercise.

Unfortunately, despite the support of senior leadership and a strong team working on a
well defined.

Problem. Then the RCA exercise can go sideways if you allow biases, opinions, turf
issues, the blame game We talked about that preconceived notions.
Sometimes folks may come in and think that they've worked there a number of years.
They know exactly what happened.

But it's critical to acknowledge these biases. Set them aside, and the best RCA teams
do not let the opinions guide act as red herrings and they and go after the symptom,
covering up the real issue. So it's essential to rely on the process and follow the
evidence to come up with a theory, not coming up with the theory and trying to make
the evidence fit that scenario.

Other common watch outs that could cause issues focusing on containment is factors
for symptoms that bandage we talked about.

Tim was talking about equipment maybe not being set up for success, so not
considering organizational system deficiencies, equipment.

Line equipment not designed for success. Perhaps the training program is insufficient,
and a big one that leads to non conformance is his failure to follow up on audit
deviations. So.

All of these are common watch outs and I'm going to turn it over to Brendan who's
going to take you through additional common watch outs and controls.

All right. Thanks so much, Deb. So just to reiterate, when you're looking at the data for
where do problems come from and how do problems come to the fore, what you find is
that probably 80% roughly of critical events are due to human performance. And this is
maybe not that surprising because people are at the center of everything that you do in
a process, right? But when you drill down into that data, you find that only about 30% of
those failures are due to individual competency gaps.

Of people actually not having the skills and abilities, not knowing what to do or how to
do it. The rest are due to organizational deficiencies. People have been trained on the
system the way that they were supposed to be trained. They're operating the machine
according to the SOP. They are carrying out the instructions, carrying out the duties as
they're supposed to. But the problem is still occurring. And so you then you have to dig
into this and say, well, why? If the people are doing what they're supposed to be doing
and we're still having problems, why is that?

What's the issue and why are we still having to deal with this? Hierarchy of controls is
probably familiar to a lot of people, and if you start at the bottom with PPE, this is in a
case where.

Your problems and the issues that you're dealing with can't be removed. The hazards
that you're trying to control are, for whatever reason, they are systemic because of the
nature of the work, of the nature of the environment. You can't remove those hazards,
so you just have to protect your workers from them, right? The hazards are present,
you're not able to remove them, and you're just trying to, you know, perfect the people.
Above that then is where you start to try to dig into this and say, well, can we remove
some of these hazards? Can we remove some of these things? Do we change the way
that people work?

To reduce their exposure or to try to mitigate this. Again, if you're trying to control the
hazard, to control the failures or the times you're going out of spec, or you have some
other kinds of problems, those are still there. You're just trying to control them. You
haven't really eliminated it. You have to keep going farther back into redesigning the
equipment, getting into engineering controls, or changing the way that you do the
business entirely. And you do these functions, getting into substitution before you can
even start to look at elimination. Real elimination of hazards, and real elimination of
these things.

That's where the root cause is, right? So ultimately.

In order to get at all of these, kind of the deep dive to say, well, what is the problem and
how can we eliminate this? If you've eliminated the hazard, eliminated the failure, or
eliminated the outer spec circumstances, then a lot of the other things down the line
can be mitigated or can be reduced or can be set aside. You don't need necessarily so
much PPE if the hazard has been removed. That saves you money and protects your
workers and you get all kinds of benefits.
From doing that, right. So the time and effort that it takes to invest in a proper root
cause analysis really can pay dividends. Now there are a couple of common watch
outs, I mean aside now if you look at the cartoon you see that the, you know modern
update of language going from it's not my department to that's beyond the scope of my
role. That was in 22, 000 and six. I imagine here 2024 we could update that language
even more and I'll leave that as an exercise for the audience to come up with you know
a better way to phrase that or a more modern way.

But one of the big problems you have is that you implement a correction and then say,
great, we have implemented this correction, therefore we have implemented A
preventative control. Not true. I'll give you an example for what that you know what the
difference is there if you're driving down the highway and your car is consistently pulling
to the right.

Your preventative control, Your correction is, well, you just yank the steering wheel to
the left and that keeps you going straight. Is that a preventative control? No, because
the car still wants to pull to the right. You still have something that is causing it to go to
the right. It might be a tire that's low, it might be a flat tire that might be some other kind
of a thing or some other kind of issue you're not even aware of. This correction that you
put in is keeping you on the straight and narrow for a while, but that thing that is that is
out of spec is still there, and it can cause you real problems.

Much bigger problems, perhaps further down the roll down the road. So another thing,
these problems that if you only focus on administrative controls to try to contain or to
quantify or to channelize the problems or the issues or the situations where the things
aren't doing what they're supposed to do and you say right, well, having done this, now
we have contained the problem, but it's still there and it's still waiting to break out of
those administrative controls. Very often you can have implementation of some short
term and unsustainable fixes.

And that's, it's not necessarily a problem if you understand that that's what you're
doing. If you only have time and say you're in the middle of a shift or something, you
say, well, we have to put in something that we know is not a proper fix, but we need to
do this in order to get to the next six hours. Well, that's okay as long as you make a
commitment at the plant level and at the, you know, administrative office level to come
back and, you know, do this And that leads into the next key point which is lack of
ownership.

And if it's not my problem, then it's nobody's problem, nobody's going to fix it. The
people that are in charge of this, people that are on the line, are expected to have
these things operate the way that they're supposed to and get a certain outcome. And
when they don't, then you not only have the risk of lost profitability and damaged
reputation, you also have the problem or run the risk of worker safety. And that's a
that's a real issue in the plan functionality for the workers and for the company as a
whole.

Right. So it does nobody any good to ignore the problem or to pass the buck or to say,
well we'll fix that next quarter when maybe profits are better. This really needs to be
addressed now you really need to take the time and effort to do it.

So one of the things that you need to do also is to after you've implemented a solution,
after you think you've understand the problem, you put in some kind of a preventative
control that you think is going to address the issue and really get you to a place where
you can rely on the process and do what it's supposed to do.

You have to check it, you have to validate, and you have to make sure that what you've
done is doing what you think it's doing and is actually solving the problem that you
have. And to talk about that level of validation, I can hand the webinar off to John Butts.

Thank you very much, Brandon.

I really appreciate the opportunity to discuss the validation system.

The validation process.

Consist.
Testing to validate the root cause.

Preventive controls to manage validate the effectiveness of the preventive controls, and
in verification monitoring to hold the gains in the long run. In the food industry, we have
CCPs, which control hazards and preventive controls that manage food safety hazards.
This process identifies how new preventive controls are established along with how
they're validated for future production.

I really like the table that is presented here to enable you to document this and
document the validation process so it can be used to train future.

Process users.

So the root cause validation testing may include identifying causative Organism and its
source testing may define a faulty piece of equipment validation testing and must be
focused on why the failure occurred in addition to what failed. So we have to be data-
driven and we have to design tests that will prove failure of uncontrolled variation.

Leading to the root cause and hopefully the hopefully the preventive controls that we
implement.

Will be able to fix that. As we see on the right here, we may partially eliminate that
problem.

We often have multiple factors or multiple root causes in a system and we may not get
to the exact one. So we have to change the process and maybe include the control that
we've implemented, but then continue researching until we get to the get to the real
root cause.

So preventive controls to manage, we know the root cause must be either eliminated or
managed.
An example is removing a machine from the process.

If it can be eliminated then we have to re qualify the process.

If it cannot be eliminated, then it must be managed. In either case, the process must be
changed and employee training does not constitute a process change.

So key here is requiring a process change.

Interacting factors may be present that cause failure. Tests then need to be. Tests
need to determine if there are more than one root cause in the process. So again, be
cautious and aware of quick fixes that we've covered in the other in the other
presenters, so test must be designed to challenge the system.

So the validation process.

Or examples or failure effects to measure controls, challenged seek and destroy

investigation, which includes complete disassembly of equipment and with the root
cause being managed.

Entryway Hurdle Challenged with Dirty Footwear.

Greasy contaminated tool cleaned and then pasteurized in the COP tank. Or dye test
or swabathon on a corrected CIP system.

So we examined the integrity of the process of shedding foreign material after running
drier with inexpensive or pseudo product. There are many ways that we can evaluate a
process to make sure that we've effectively determined the root cause.
So verification monitoring to hold gains long term.

In process assessment, testing must assure preventive controls are effectively applied.
So this is what we do over time. So it's a verification test that we define during the
process that fixes or prevents the root cause from occurring. These tests are
monitoring go on forever with the process.

So validation of the root cause provides data to train future operators, maintenance
process managers in general. Simply put, why is answered.

So I'd like to turn it over back to Brandon now you're on stage.

Thanks, John.

So just to wrap things up, the lessons learned and the big takeaways from the
information that we presented and from all of the discussion that we've had about root
cause analysis. The goal of root cause analysis is not so that you never have problems,
but it's so that when you implement solutions, you can fix it so that it stays fixed. OK. As
Tim King said, the RCA process can't be ad hoc. You can't just throw this together. You
know some folks that are on the table on a short term thing without a plan and without
any structure to the discussion.

And expect that to be fully successful. You might come up with ideas or strategies or
solutions, but they're not necessarily going to be getting at that root cause. And you're
going to be right back to where you were before implementing solutions that don't really
stick and that you're going to be you're having those problems again. So you need to
begin with the right team, you have the right tools and have the right focus on
addressing the issues that you're that you're trying to really, you know, get that laser
beam focus on to solve your problems and you have to think critically.

And you have to ask those important questions. And even as you're doing the analysis,
you have to take a step back and ask those questions about it, say, and look at what
you're doing. Look at how you're using the tool and say, is this tool working for us? Is it
helping us to get to the root process? Are we using this tool properly? And could a
different tool help our investigation? And these are the areas where it is really helpful to
have somebody who is trained in root cause analysis to be part of the team or to come
in and do a train.

A training seminar for people that are involved in your facility and in your operation, so
that you have some awareness of what the possible tools are. Because if you don't
know what the different tools are, you're not aware of how to use root cause analysis.

You may not even realize that you're not doing it right and you may not realize that
you're sending us send yourself down a path that's going to lead to more problems in
the future, right? When you have the right people around the table, you have people
that are trained in this, that have some of these experience, they can help you ask
these questions to say, well, look, are you missing some aspect of the problem that
could help shed the light on what the root cause is? Ultimately, then you have to take
this back to management, back to the FDA or other regulators that operate in your
space, into auditors, to your customers, to everybody that's in your whole business
that's listed in your business plan.

And say, look, we had this problem, this is what we're gonna do to fix it. And This is
why we do not expect to have this problem again in the future. Those effective and
efficient solutions are gonna prevent those problems from recurring.

The recrawlers analysis helps to break that cycle, right? You don't wanna be in this
Groundhog Day thing where it just keeps happening again and again and again. We
always have this failure. You know it happens every Friday or it happens once 1/4 It
just keeps going and going and going. When will it stop? How can we address this if
you apply root cause analysis the way that it's meant to be applied and you do it in a
thoughtful, efficient way.

You will be successful in finding out what is actually causing your problem and fixing it
so that it stays fixed. OK, and so with that, I will turn the slide deck back over to Adrian
Bloom for some final thoughts.
Great. Well, thank you everybody for that great discussion. And before we jump into the
Q&A here and have our presenters address some of your questions, I'd like to remind
you that we love your feedback. So please take a few moments to complete our
webinar survey, which you'll see on the screen now or you'll also be redirected to it at
the end of the program, so you can also complete it at that time as well.

So we have a good amount of time for Q&A today, which is great. And we've already
got some great questions coming in from you all.

Please feel free to continue to submit your questions using that QA box or the chat box,
and we'll try to get to some, if not all, of the questions here, All right, So what I'm gonna
do is I'm gonna read the questions out loud and our presenters are gonna address
them.

There's a question that I think is really interesting that I'd like to throw out first that I
think is going to generate some discussion among our presenters. And I'm gonna throw
it out and let you guys pick to see who wants to jump in and speak to this first. But I
have a feeling there's gonna be more than one person who wants to speak to this.

All right, so the question are there any occasions where the root cause has been
identified but it cannot be eliminated because it could potentially cause other problems?

It's a tough one there.

So anybody who wants to tackle that, please feel free to jump in.

Can I, am I off mute? Nope. Yep. We can hear you. Yeah. OK. Well, I'd say.

First off, anytime you solve a problem and remove a root cause, you have to look for
unintended consequences and problems.
I mean, it's a little tough without a specific example. Most of the time I hear people say
we could eliminate the root cause, but it's but it's economically.

Not feasible.

So I don't know. I think that there's always a way. I just believe where there's a will,
there's a way. Sometimes you have to think outside of the box. Is this the only way we
could do it?

Because if you can't eliminate it, you're going to have to really control it and find it and
detect it quick and take the loss that comes from it. But there's always risks in that
because things aren't always found and they escape, and that's when you get in
trouble, so.

I guess my answer to that is.

Believe there might be a way and see what you find out. I just like to say that I think
that if you've done a root cause analysis and you have identified a root cause which is
the root cause of several problems, then I it sort of feels like there's a business
opportunity there, right? There's an opportunity to kill several birds with one stone. Now
maybe that's, you know, a larger.

Change or something that you're ready to do in one moment, but that might be
something to develop as a strategic plan for going forward in the coming year or in the
coming couple of years to say, look, if we fix this, then we solve lots of problems for
ourselves. And so the ultimate value of the whole process that you went into is still
there because now at least know what's going on, whereas before you were kind of
flying blind.

From my perspective, I think we have to look at what the effect is. If we're dealing with
the food safety hazard, that's different from a root cause of an economic issue. So if
we're dealing with the food safety hazard and we cannot come to a solution that
enables us to produce seafood and we have a very simple decision to make, we
cannot, we cannot really produce that. So there's a lot of.

Of factors that go into.

This defining the solution and research a lot of times is required to do that. Sometimes
it's not simple research, but these are chronic problems that have to be addressed.

Great. Thank you, Deb, Tim Jackson, either of you have anything you want to add to
that?

OK. So Tim Brennan, John, thanks so much for your. Oh, Deb, did you want to say
something?

Sometimes, often we don't find a smoking gun.

And there's a lot of reasons for that, because everything we do.

We're reacting to something retrospectively. So if it's an outbreak, there might be a lot

of time because there's the time it takes to for people to get sick, and then there's the
time it takes to tie together the illnesses and there's the time it takes to do the trace
back and the investigation.

And also in a firm there all of the indicators that most of the indicators we're looking at
are lagging indicators of some kind of processor program. So things are retrospective.
And because of that and also the complexity of how all of the controls that often need
to work together for food safety. It could be GMPS baseline, GM, PS Plus preventive
controls. It could be if you're a grower, it could be all of those variables that in your
growing operation that need to be controlled.

That you may not find exactly 1 failure. Maybe it was multiple failures that lined up. The
reason I say that is that just because we can't find.
A smoking gun in many cases doesn't mean that we can't identify those programs that
should have managed the risk. So if we go through that evaluation, we could see that
maybe we didn't have a program to manage a particular risk that we saw in our
evaluation or maybe we do have programs and there the question would be how do
we?

Make sure we reinforce those programs or we verify those programs in such a way that
we don't have a failure that could lead to the same issue even in the absence of
knowing exactly what happened.

And I would add to that, right, sometimes you don't find the exact root cause, but in that
root cause exercise you uncover other program gaps, so you end up fixing those along
the way. So it's hard to figure out without a specific example how you would create a
new problem. But I will add, we often uncover other gaps and it gives us an opportunity
to fix those gaps even if you don't get to that smoking gun or true root cause.

Great. Thanks everybody for your comments to that question. All right, we'll move on to
another question and I'll throw this one out for the group as well. So what do you
recommend in terms of root cause when you're dealing with a very low probability event
that occurs over an extended period of time and is only detected by people getting ill,
So, for example, Listeria monocytogenes or Salmonella foodborne illness outbreak?

I see that Doctor Buchanan posed that question. Thank you for being on board. We
appreciate.

What we've done for environmental pathogens, Salmonella Listeria is the second
destroy process that was developed in the early 90s, which consisted of taking things
apart and sampling and it required complete disassembly. So the first pillar in
environmental pathogen control.

Is to eliminate the residents in the area of where we have exposed food products. So
seek and destroy is one way of eliminating that in equipment.
The next pillar of control is to control movement.

Once we've eliminated it from the equipment, we now have movement coming from
Zone 4 into the RTE area or coming out of the facility. This is where we have to set up
sampling and process controls to create barriers to entry. We have to create tortuous
pathways.

Once we've established the ability to control movement, then we use predictive
indicators.

To tell us when to apply interventions, we've been cooking equipment now for almost
25 years. Cooking equipment is like we cook a meat slicer to make sure that we've
applied an intervention, so in the process of establishing.

Or eliminating the Organism in the RTE area we apply it have to apply an intervention
to each piece of equipment.

And sometimes it's very difficult and hard, but it's when you have that intervention,
enables you to have control and then we use indicators to tell us when to apply that
intervention.

Great. Thank you, John. Anybody else want to add anything to that? Well, I would add
right, the root cause analysis exercise starts when there is a failure, right?
Unfortunately that is someone getting sick or food becoming contaminated with the El
Mono that goes back to the controls, right, to make sure that doesn't escape, right. So
that monitoring activity really goes back to monitoring in those programs tab in place to
ensure you don't have the failure.

Up front.

Great. Thank you, Deb. All right, anything from anybody else on this one I think we've.
Got that? Pretty well answered. OK, I'm gonna move on to another question and
actually there's a couple questions on a similar topic. So I'm gonna combine them and
I'm gonna throw this out first for Tim King to answer and then of course, if anybody else
would like to comment, please go ahead. So the question here is about applying. How
do you, how do you apply root cause analysis in very small food industries, especially
companies that may not have any training or formal education on root cause analysis?

And then could you also explain a little bit about if root cause analysis looks different at
all between large companies versus small companies?

OK.

The first question, I think there's always a way to get some training on this, even for
small companies.

Perhaps locally?

I'm very much affiliated with the American Society for Quality, and ASQ has sections in
every state, and sometimes there's folks there who can come in and do something very
affordably.

And understand that as a small company you don't need a big solution, but I think you
got to learn how to use these tools and not just the tools, but fit inside a certain overall
process. So that leads up to RCA and then.

Make sure at the end you have that verification and validation. It's not I'm a is at ASQ
we do this in a one day class. It's not a big training, but I do think you need to have the
training and maybe there's a way to get some help or economic help with training.

But I would say find some form of training for it on that other say that other question
again.
So the other question was, does root cause analysis look different between?

Large companies versus small companies.

Does it really look differently? I don't think the tools and methods look different, but you
may have more complexity going on.

Larger companies could have more automation going on. Smaller companies got a lot
more manual activity going on.

There may be a difference in labor pool one can get at versus the other and then
obviously there's going to be a difference between larger companies will have people
dedicated to this.

And in smaller companies, it's like, OK, I got my job and then I got to get this done too.
And I do see that in smaller companies, they have a hard time getting the time aside
because they're wearing many hats and they got a lot going on.

But it is an opportunity to buy yourself a little free time in the future if you don't have
these problems keep recurring on you. So I think those might be some factors of big
versus small.

Although I find small small organizations tap more into.

Their core people better and they're people who are really close to the problem, and I
think I see them come up with some pretty darn good solutions because they're
creative and innovative and not restrained by some bureaucracy.

This is Tim just to add to Tim's comments. Agree.

The tools in RCA, the tools we presented may be seen complex, but the sole purpose
is to help sort information.

And try to drive down to what happened. So the key is to keep it as simple as possible,
and there are there are courses.

Where the tools are, people can become familiar with the tools, hiring consultant to
maybe help to walk through the tools and help to facilitate that. But even in a small
group, if you have the right people in the room, as Tim saying, then you should be able
to get through that brainstorming of what could have happened.

And then start to narrow it down and identify the root cause. And as long as you have
the people that understand the process as it should be and maybe as it really is, which
is maybe more critical as it really is an application. And you have those people that
know what happens from day-to-day in that conversation. And then you allow a really
open kind of brainstorming of ideas about where the failure could have occurred.

And keep it open to where everyone is encouraged to participate. I think a small firm
should be able to do it as well as a big firm. Certainly you might. If you need to do other
data collection or testing or other external analysis, then bringing others in would help.
But as Tim was saying, smaller organization might be easier because people are used
to working together and being being really open. And you might not have people just
defer if you've got 50 people in a room or 15 people.

Just defer to somebody that talks a lot. You really want to get the folks that understand
the process to feel free to contribute because their ideas might be the right one,
especially the people that work with the process very closely.

And I would add to I've seen very successful root cause analysis with small teams. It's
about having the right people in the room, right the people that understand the process
and can really contribute.
Great. Thank you guys for those comments. And actually, there's a great question that
kind of jumps off of some of the things that you were just saying in response to that
question. And I'd like to pose this question next so.

Is it good to assign a root cause analysis exercise always to a group or could it ever be
assigned to one person to complete that? And then also, how should we determine the
deadline to finish a root cause analysis?

I'll jump in on that one.

When we teach corrective action, we always teach A-Team approach.

There's a popular method out there called 8D. The 8D method and the first D stands for
disciplines, A disciplines to do a root cause analysis. The first discipline is give it to a
team. I don't think one person can do it all. They don't, you know, they don't know
everything. They don't see anything. Could they facilitate and bring other people in? But
I and we don't suggest big teams, two to four people.

That go through the whole process together, bringing in other people. Like Deb said,
when we do fish bone, we got to get the right people in the room. It doesn't mean the
team has to conclude all of those people. When they do that, they can invite other
people, but to a team of two is fine, but a team of one I don't think is a good idea.

What was the second question? I see no forget the second question, second part of the
question.

No worries. So the second part of the question is what would be, how do you know
what the deadline should be for finishing a root cause analysis? Yeah, how do you
determine that? Yeah, deadlines.

First off, let's take it in stages. You should get your containment in place within 48
hours. You put that safety net over.
The next 30 days, maybe longer, maybe sooner, get your Rook, determine root cause
analysis and have it verified. If FDA isn't, you know, someone looking at it. So a
common number used out there is 48 hours for your intermediate interim actions and
then 3030 days to get to root cause analysis because your interim action should be
holding the Fort and give it buying you a little bit of time if it's really urgent and it's big
deal, you know, maybe it's got to be a week, but you don't want it going on more than
30 days 'cause it you start to get.

Drag on completion and the other thing that can happen is once people do put interim
and containment actions in the pressures off and they delay getting to the root cause
analysis. So you got to keep it going. My answer is 30 days.

Plus or minus?

OK, great. Thank you for that perspective. Anybody else want to add anything else to
that? I would just say that highlights the value in doing exercises and dry runs and
tests, do, do training exercises so that you're familiar with the process, so that you don't
spend the first period of time in a root cause analysis. Trying to remind yourself of, well,
what are we doing and how are we doing this and how does this all work? If you are
familiar with it or if you've got a facilitator that's trained in it, you can get up and running
pretty quickly in your root cause analysis.

And that's why running these, it's sort of like doing a fire drill. You don't want to be
looking for the fire extinguisher and wondering where it is. When there's a fire, you want
to know where all that stuff is. This is why this is valuable to do ahead of time.

And I would say too, the time depends on the complexity of the problem, right? Your
complex problems are going to take much longer to solve, especially if you have a lot of
contributing factors that you're looking at. Maybe those simple 5 why's could be done
again.

Much more quickly than that 30 day and that's why Tim said there was a range. I think
you said there was a range straight to him range of time, but 30 days would kind of be
that Max.

Yeah, the five Y can really be fast, but it's looking for a smoking gun, more complex
ones to depth point. You do that, you brainstorm on that fishbone diagram. Then you
got to go out and check out all of those things and when you got time and it can take a
while and sometimes there's subtle stuff that takes a while to figure out, so.

Yep, I agree.

OK, great. Thank you for those guidelines and good pointers for the attendees and the
great answers to a great question. We've had a lot of great questions during this Q&A
and this was a great discussion from you all, but unfortunately that's all the time we
have for the Q&A today. But please join me in once again thanking Brendan, Deb,
John, Tim Jackson and Tim King for their presentation as well as today's sponsors best
Sanitizers Fortress Technology.

Cleans, Perfects and Safety Chain. Now, if you have any additional questions or
comments, please don't hesitate to click that e-mail Us button on the console and we'll
share them with our presenters so that they can respond directly to you. And if you
didn't have a chance to fill it out earlier, you'll be redirected shortly to the Post Event
Survey. We always look forward to hearing how to make our programs work better for
you, so please take a few moments to fill that out. Also, please make sure to visit food-
safety.com.

Slash webinars.

For the archive of this presentation, which you can share with your colleagues as well
as information about our other upcoming events. Also, please save the date for our
annual Food Safety Summit taking place from May 6th through the 9th, 2024 in
Rosemont, IL. This will give you the opportunity to connect with peers, learn from a
network from leading subject matter experts and so much more. And you'll also get a
chance to meet today's panelists as they dive deeper into their session root cause
analysis.