Scope, Resources, Objectives and Deliverables

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

9 hours 53 minutes
Video Transcription
Welcome back, guys. I'm Katherine MacGyver, and today we're going to discuss scope. Resource is objectives and deliver, Bols. So on our last module, we talked about our business case and our problems statements and this one we're gonna be talking about scope, resource is and deliver, Bols.
So this should all be knitting together for you. The idea of our project charter, which is the foundational document
throughout your lean six Sigma, projects you to make projects, speaks specifically that given idea of what you're going to do and what you're allowed to do.
So when we're talking about scope, I think that we don't necessarily talk about this enough. And the easy answer for it is it's when your process starts and stops. So, for example, my scope, um would be I
No, for example, in a cheeseburgers, right, your scope starts when you receive your order, and when you deliver, your order is when ends. So all steps within those within those book end brackets are on the table for my improvement project.
It's important to be very, very explicit about our scope
because it is that second leading cause of project failure. 1st 1 being team dynamics. 2nd 1 being scope creep. Well, since we're here, we might as well talk about it more. So you want to make sure they're your scope is looked at in two different ways. One is
breath or your brackets where you start and where you end within your process
for this project and the next pieces depth, what are the things you are and aren't allowed to do? So? One of the things that I always talk about when I'm doing my my scoping conversations is Are we allowed to do system changes like, Can we buy new software? Can we reconfigure the software that we have that
as an example on, Do some organizations you can in some organisations you can't, but you want to go ahead and clear, clarify that
another thing that I try and call out in my scope statements is whether or not we can do FTE changes. So full time equivalent or full time employees can we add them if we discover that we need more. That's a little counterintuitive to doing to the lean Six Sigma you know, better, faster, cheaper.
But let's say for some reason we revamp everything.
Can we Adam, can we decrease them? I would argue against decreasing them. We would rather reinvest that capacity somewhere else in the organization. But it's an important conversation to have. What are we allowed to do? So you want to document this as discrete statement?
This scope begins at and ends at what you can do what you can't do. We're not going to do system changes we are going to do for plan. Change it or we are available to do floor plan changes. You want to be a straightforward as possible because much like your problem statement,
your scope statements will help you keep your project on track. When you have somebody who's like, Well, I mean,
really, we should talk about what we should be talking about the parking lot. When we're talking about our cheeseburgers, you could go back and say, Nope. We start when the order is received and we end when we deliver the order.
So the next part of this is when your scope, which gives you the size of the project so your problem statement gives you a sense of magnitude
or your objectives. Your scope gives you the size of the project, Are you revamping the entire HR system? Or are you looking at three steps within interim employees into the H arias?
So scope leads into resource is and this is what all do we need to do to get this done? How many employees do we need? This is going to be our project team. How much time from those employees are we going to take?
Is this going to be two hours in meeting in two hours and homework? Is this going to be four hours and meeting and 16 hours in homework?
You wanna have a sense of this as a facilitator and then money you If you think that there's going to be any investment from a financial standpoint, you need to call that out at the beginning when you're looking at chartering because you don't want to have your project go off track because you've got here
and then you have all these great solutions and you're like up no money for them.
Remember that one of the 14 rules from Toyota, the 14 Rules of kaizen from TPS, is creativity before capital to try and keep that in mind that you want to come up with solutions that Mrs that don't necessarily require huge investment.
But the last thing that you want to do when you're starting to document your resource is is anything that you want, where you think you may need to use. You want a list on the project charter.
So I'm going to need to use the computer lab. We want a document that so we have very clear expectations at the beginning. And if for some reason, if we don't get those things,
then we know where we can attribute our project going off track. So being as explicit as possible, of course, understanding that you don't know what the solutions are gonna look like till you get there. But try to keep in mind what solutions could look like and it never hurts toe over, ask an under spend.
So with that, the next piece. So we've got our scope, which is how big of a project we're going to be. We have our resource is how are we going to get things done? The last aspect that we're going to talk about in this one is our delivery bols, which is how do we know we're getting things done
so if you remember back to yellow. But we talked about every single phase in domestic has a toll gate where we have to provide something to our sponsor and are champions
showing that we have in fact got stuff done. We are using the tools were doing the analysis we're testing and piloting these air How we know we're doing stuff. They're important that were very good about documenting them because we want the historical, the historical record of the project.
We want to know what did we dio and how did we make the decisions that we did
based off of what we learned from those delivery Bols?
So my recommendations to you are use your delivery bols as your milestones. We talked quite a bit in yellow belt about. These are the things you have to do before you could move to the next phase of the project. I would use those as clear delineations in your project timeline
because when you say something like, I'm gonna be in the defined phase for four weeks,
you don't really know when you finished it. As compared to saying we're going to have our project charter done by X Day. That is a very clear line in the sand. You, Comptel are we're awfully on track. Are we? Are
are we are off on track, even a, um from a project timeline perspective, it gives you something tangible. I would also recommend you review these with your champion before you give them to your sponsor. So remember your champions, somebody that's gonna be excited about your project, that we want to help you overcome barriers.
Your champion will also give you insight from an outside set of eyes.
So if you were to say bring to me a project charter, I would give you some feedback. Say, you know, maybe your business case could be a little bit clear. And then you can go to your sponsor. Which sponsor approval is what advances your project time forward or your phases in your d make project forward.
So with that today, we talked about how important it is to understand and document our scope, how important it is to be very discreet and explicit. And what resource is we think we're going to need and that we want to have set delivery Bols
that the sponsor and champion can expect to see. This is how they're going to know
that our project is moving forward
in our next video. We're gonna pull it all together and do a really quick project Charter refresher. So I will see you guys there.
Up Next