9 hours 53 minutes
Hi, guys. Welcome back. I'm Katherine MC Iver, and this is your lean six Sigma green belt.
So today we're going to go over pilots on DTA. Get to this point. We have done a bunch of root cause analysis. We have developed some hypotheses. We've collected some data and we've said yes, there is a relationship between our hypotheses and the outcomes that we're looking for. And at this point, we should have developed some solutions
to change those relationships. So how are we going to impact our process
to meet the project objectives in the charter? And with that, we're going to come forward to today's lecture where we're gonna go over. Pilots were gonna understand why we perform pilots on. We're going to understand how we can tell if our pilot is effective.
So before we get started, this is one of my favorite lean quotes, and it really gets to the frustration that sometimes you're developing solutions that you really have no idea what's gonna happen. So the quote is lean isn't a stab in the dark. It's a stab in the dark
and then listening carefully for screaming. I'm and I love that because really what our pilots are
is listening for the screaming. So we're going to say, kill its try this solution and see what happens.
So the actual definition of a pilot, if you want to sound really spiffy when you're talking to your boss, is it is a preliminary investigation intended to collect data.
So what that tells us is is we're doing this before we're doing our whole implementation and we're gonna be measuring along the way to see whether or not this is in fact, what we wanted to dio. They're generally small and size, scope, duration, or budget
or and budget. And what that means is that we're not going to go all in on this. We want to test a teeny tiny thing. It's like spot checking with your laundry. Let's see if this change is the one thing before we commit to the entire red T shirt in the load. But all of that is really great and you know, fine and dandy.
But really, at the end of the day, what you want from your pilot is you want to show you what will go wrong and your full implementation.
So you two fold you want to see? Yep. Is the solution gonna work and then you want to see Whoa. These are all of the things that we have to fix before we get there.
So from that good pilots their small scale. So you want to talk about things that can easily be done if you're doing a true kaizen project? I'm kind of a lean blitz.
They have to be able to be done within one day. Generally, I recommend that they can be done within a week
That is dependent on the number of data points that you can get. So once we get into statistical process control, we'll talk a little bit about data patterns. But really, you want to make sure that you get at least those 20 to 25 data points to get a sense of how is that pilot really evolving?
You're gonna want to do your hypothesis test on this to determine whether or not you are seeing changes. Um, between your current state and your piloted state,
eso what you're going to be looking for. There is either statistically or operationally significant changes. Usually I look at our averages on as faras how we can determine that you are going to test your future state process.
So if you devised this wonderful, brilliant future state process that's going to fix all of the problems,
there should be no problems testing it. So either you can do this where you do, um, a set time. So your control group is your baseline data from your measure phase, and we're going to do the new process for a week. Or if you're working on a larger process, you could buy for Kate it
some are going to be in the control process, and some are gonna be in the new process. So current state and future state
and really, what you're looking for is whether or not you're changes in fact, affected the outcomes Look, well, you're looking for in your project. So your project objectives you're gonna be testing individual solutions so often times as you go through these, you come up with lots and lots of different solutions were going to be testing those to see if they work.
So maybe you don't have a future state process maps specifically,
but rather you have a couple of solutions. We want to make sure it's in fact, impactful if you think back Teoh are yellow Belt. When I was talking about the reasons that we do lean six Sigma is because we sometimes see where we come up with these brilliant solutions, and then we have to find a problem to substantiate it.
We want to make sure that we're not just putting solutions and and they don't impact our project objectives.
You will want two sets of data so baseline and pilot before and after, or control and future state and we say future state because it's really control and independent variables. But we should be testing our future state process.
So you will be looking at What is your descriptive statistics for your before
or your baseline? And what is it through your pilot data and then you're gonna compare from there. So a couple of things that you'll look for in those descriptive statistics, your average is because, remember, most add, it performs around your average, and then you're going to be looking for your standard deviation specifically, which is a measure of variants,
and we'll talk about that a little bit more
in statistical process control.
So when you are developing your pilots with your project teams. I want you to challenge your project team and really push on them so much like our fmi a where we were talking About what? What will go wrong? Because of Murphy's law. I want you to ask your team.
Can this process be studied the way it was designed?
So what that means is is, can we do what we actually said we're going to do? Or do we need to alter it? Like do we need to make a couple of tweaks? So, for example, if you're doing a control group and your pilot group, you have to buy for Kate. So how do you decide? Is the pilot going to be
everything that comes in from this source? Is the pilot gonna be randomly selected? It goes back to your sampling group if you're doing some random selections there. But do you need to change it? And this is really important if you have to change it for some reason,
because you want to document what was altered and why you will want to ultimately develop hypotheses for the impact of those alterations. So, for example, one of the processes that I worked on for a hospital. We were looking at surgical suites in the ower.
So in order for us to pilot our process, we had to omit anything that had to do with patient contact
until we were absolutely certain this is what we wanted to do. So we had to create some scenarios. So we were basically testing about 70% of the future state process and not the full 100%. Then when we got to doing it, we actually did a second phase pilot where we integrated the actual patient experience.
But we only did certain surgical types. We only did outpatient day surgery
as we piloted that because of the nature that we were working with a surgical office, we wanted to be very or a surgical practice. We wanted to be very, very, very careful as we're changing our processes because we know the current state works whether or not it works to the level we want. It works. So you want to be really mindful about how do you need to tailor it to study it?
Because ultimately, in the long run, you're not gonna want to keep those alterations in.
So when you know that you've done a good job with your pilot when your pilot is effective, it's because you have measured the process exactly the same way as you did in your data collection plan. So if you remember when we were talking in our measure phase and we said, Develop your data collection plan but be really, really thoughtful because it's not gonna change.
This is where it doesn't change. So now we're going to say we did this for our apple. We're going to do this for our apple,
and then you're going to compare the results of your baseline. So what you captured in your measure phase to your pilot results to your project objectives in your charter. So let's say that you're looking at cycle time, and while the thing it was the same amount of time to get through the process,
you were able to get, you know, 10 more widgets through
in that keys. You did have an effective pilot, but it didn't change the project objectives, and that's a good point to have a conversation with your sponsor and say, Is this good, or do we need to really go back and look at our original project objective. That does set you up for scope creep, which we don't like.
So today we win over what makes a good pilot. You know that you wanted to be small. You want it to be as close to the future state process as possible. You want to be able to collected data on it If you can't collect data, there is no point in doing the pilot. And you know that when you're designing your effective pilots, you're going to be following those processes
and those measurements exactly the way that you're proposing doing it for your full scale future state.
So with that, our next module, we're actually going to start talking about statistical process control, so I will see you guys there.