Hi, guys. Welcome to improve phase developing effective pilots. I'm Catherine MacGyver, and today you'll be able to understand the considerations for effective pilot design.
So first things first. What is a pilot? This is going to be a small scale implementation of your identified solutions. So remember, throughout your improved things and certainly up to this point, your whole focus has been taking what you learned in your analyzed phase and developing proposed solutions.
So you have your future state process map where you've eliminated
you're non value, add in your waist. You're goingto have some ideas about visual management to make the process more intuitive to manage. And you will have done some mistake proving because you know I love mistake proofing and get some ideas on how it is that you think that you can move change or independent variables to get to the outcomes
that were stated in your objective statement in your charter.
the pilot is used to test those solutions before doing full implementation, and it can't be used to test multiple solutions. So it's a smaller investment than having the whole company go bananas on your solution. If maybe you're not 100% certain
how effective it's going to be or if you wanna learn what is a good way of doing an implementation.
So I strongly recommend pilots
so much so that I actually have this whole slide dedicated to it so
pilots aren't required.
That being said, I strongly, strongly strongly recommend that if you were in a place where you can do one, you do it. So the first reason that you want to perform a pilot is you want to roll lower the risk of project failure, having worked on a couple of projects
that have been classified as
failures because we didn't even get close to our objective statement and in fact, one of them that we didn't pilot on, um, note we actually got worse than where our baseline was. So we actually made the process more complicated and even lower performance
Then we had when we actually started from so that specific project,
we went back Thio, the original current state, and you want to talk about an uncomfortable conversation with a sponsor.
So the next reason that you wanna you want to do a pilot is to assess the effectiveness of your proposed solutions. So just because you know that this is going to be a great solution doesn't mean you know how much it's going to move the needle. So this gives you an idea of how close
to the objective statement does the solution get you? And if it doesn't get you close enough, this is a great time
to look back at your solutions. Go back to the drawing board and see if you can come up with something that does get you closer to where you want to be. You can also identify additional improvement opportunities in a project. So
one of the things that's great is is in your mind. We have this idea of how our future state is gonna work. But once we actually get out there and we're doing it with a real process, we might learn something about something that we either missed in her process mapping or a different way that something could be done
to be even more effective. So that organizational learning in that feedback loop from our pilots is very hopeful. The next reason is dry run implementation, cultural change and changing processes is very difficult,
so if you do it on a small skill. You can kind of get an idea of the things that you're gonna want to look for when you do it on a big scale. So, for example,
if you're having a hard time training, say five people to do the new process, imagine how difficult it's going to be to train 500 if you don't tweak that training to be more well received,
the last aspect of why you want to do a pilot it so you can manage organizational expectations. If your objective statement says you're going to decrease cycle time by 20% and the best you can do when you're piloting your solutions is 12% now is the
time to start having those conversations. You need to tell your sponsors in your champions and your stakeholders.
Look, this is the work that we did to this point, and regardless of what we thought we did, our define and we put our finger in the wind, and when we did our measure and we tweaked it a little bit more, this is as good as we're gonna get today. So start having those conversations up front,
so when you actually get to developing your pilot. You're gonna want Want to run this like a mini project? So if you remember, at the very beginning, we planned our purpose and our goals.
So we're gonna want to define what needs to be piloted. What solutions are we working on? And let's make sure that the solutions that we're working on in the way that we're constructing our pilot,
we'll actually get to our project objectives. So if you remember, for the time bound, if our problems statement is time bound, our objective *** is time bound. We want our measure plan to be time bound. When we get to piloting, we want a pilot, something that's time bound. This is a recurring theme.
So let's make sure that our pilot
demonstrates our project objectives. Well, we want to be able to show this is how we're going to fix it on a large scale.
The next thing that you want to do is define your scope. So how are you going to make this as realistic as possible? So there are a couple of ways that you can do pilots. You want to make sure that you are collecting enough data points. So when you say make this is realistic as possible, you can either do it with the master process
set. So, like Monday, Tuesday, Wednesday, we're going to do it the original way. Thursday, Friday, Saturday. We're going to do with our new way and then go back. Or you can buy for Kate your process. Five. We're going to do this way. Five. We're going to do the new way and test Arnel and our alternative hypotheses or our solutions that way.
But you want to know when you're defining your scope, make sure you identify your data requirements.
So if you're working with continuous data, you wanna have atleast 20 data points so you can be able to measure effectively whether or not there is a practical or a statistical, significant, practical or statistically significant result in your pilot compared to your baseline.
And you also want to identify your limitations, what are the things that make this pilot different
than a full scale implementation? So if we were to say, do our Monday, Tuesday, Wednesday with our baseline and Thursday Friday Saturday with our improved we need to say we're missing Monday Tuesday Wednesday data. So there's a possibility that we're going to see inaccurate results.
The next thing that you want to decide is your timeline. How long does your pilot need to run to collect the results that you're looking for? So it goes back to your scope as faras what your data requirements are that will be a factor in your timeline, and sometimes it limited, and sometimes they're not.
Generally, I worked on projects that we we have to get some results fast, fast, fast.
So we're gonna have a crunch time line. So we need to be creative in how we're going to make this pilot as realistic as possible. The last thing that you want to do in your developing a pilot is developing activities list. So who's going to do the training? Who's gonna do the oversight? Who's gonna make sure that the people doing the process are following
the future state process and the solutions as we designed them? And if they aren't, why aren't they? And what can we learn from that? So
those air the steps to develop an effective pilot? Ah, couple of really quick tips that I've learned is having your project team observed the pilot. So this gives you more insight to remember back to her current state. We did a lot of observations. Are gimbal walk? We're still observing.
Have your team observed the pilot as much as possible.
Communicate, communicate, communicate. You need to tell your stakeholders the team's your project team The groups of people that are gonna be performing your pilots over communicate in this specific setting, be adaptable in your pilot planning. Try to be as creative as possible when you're looking at how to make it realistic so that
you're able to be resilient and maybe account for some of those scenarios that you didn't account for in your future state process mapping. And then the last thing is is remember that a pilot isn't a done deal. So you're doing this isn't a full implementation.
This is a test run. You're doing this to learn as much as you can. What works, what doesn't work? Does this get to the objectives that we need to? What do we need to know when we go in for our full implementation?
So when you want to do when you're looking at doing a pilot you don't have to, but you should. Um And then you want to run your pilot like, ah, many projects. So you want to make sure you understand your outcomes in your scope? You want to know who's gonna do what and by win,
so that when you come up and you wrap this all together, you're able to go to your tollgate, review with your sponsor and say, these are This is the way that we got to the solutions that we did. And this is how we know the solution's going to work
which leads us into our next module are improved. Phase tollgate review. I'll see you guys there.