7.4 Project Charter

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 3 minutes
Video Transcription
Hi, guys. Welcome to define phase Project Charter. I'm Catherine Nick Iver, and today we're gonna understand the purpose of a project charter and identify the major components in a project charter.
So this is the first tool that we have used that is exclusive for the domestic model. Um, so if you remember, quick hits don't necessarily need a charter. They do need documentation of the PDC a cycle, but you don't have to have a charter.
Um, and then, as far as other tools go, you remember we have gone over the side pocket tool. That can be an input into our charter,
but it is not a requirement. So why don't we do a project charter? This is a
A project charter codifies your lean six Sigma projects. So we've talked quite a bit about having a problem statement and a business case in an objective statement and being chartered
air quotes
by a sponsor. A project charter is what the sponsor agrees to. So it's gonna pull all of these disparate components together a CZ far as one of the things that you need to get a project started, it is going to create a baseline expectation
that can be referenced and reviewed by your entire organization. It is a living document, so
I I always hesitate to use the phrase codify and living document and the same description. But it really is the best way eso it codifies in it create pulls together the justification and substantiate its the need
and the forethought in doing a lean six Sigma project. Because you do want to be thoughtful. If you think about team member selection,
a charter will pull all of that together to show that you have really
taken your time. When you are asking to invest in organization in a lean six Sigma project,
bask in an organization to invest.
But at the same time we talked about living documents. We talk about problems, demons, and we don't know what the actual defect rate is when we talk about, um,
objective statements and we don't know what is realistic. I mean, we want to push ourselves and challenge ourselves. But are we asking for the impossible? Are we asking for that stretch goal? So we do sometimes need to modify an update it, but these are things that are not to be taken lightly.
All right. So when we talk about a project charter, there is an example in here in the cyber re course documents for you, for two references. You develop your own charter. But each of the project charters are going to need tohave these major things.
You need a project name if you remember back to the prioritization matrix. And I said you should name it something that you can remember what it means.
Um, you're gonna want a project name, and that way you know which project it is. I generally always code mind with the project number and given a name. And that's just for money on organizations. So we start thinking about sequential like this was Project one in year 2019 versus Project Five.
you need your problem statement. So you're who, what, when, Where and why
you're going to need your business case. So
this is going to be that state of the department address to say, Why does it matter that we invest all of our time in this project, you're going to need your objectives statement.
So when we talk about objective statement, we know that this is what our goal is we're going to reduce our cycle time by 10% which therefore decreases our customer complaints by 25%.
We talk about delivery, Bols, when we talk about deliver Bols, we're not talking about project outcomes. We're not going to deliver a new E r P system. What? We're gonna talk about our tools. So we're going to deliver a root cause analysis. We're going to deliver a sigh park. We're going to deliver
a pilot and the results of those pilots. But we're not going to say we're going to implement X new process. And this is going to be the outcome of the project so
different than project management and be super mindful of that. When you start committing to deliver Bols, you want them to be
tools. We're going to do a root cause analysis. We're going to do a current state process map. We're going to do a future state process map.
We're gonna do multi voting on our solutions. Whatever it is that you're going to do those air, What you want to keep and keep in mind is a practitioner. You may not know what tools you're gonna D'oh. I mean, there's some that are always you're always going to go to and we'll go through those here in the yellow Belt, and there are some that you're gonna use less and be very specific about using.
Um, you'll learn about those in green and black. Vote.
All right, The next part of our project charter is our scope statement. This is going to be two parts, so the first part is what you can and can't do. So what is in scope in what is on a scope? You cannot hire 15 new people to do this to person process.
Not gonna happen. You cannot invest in a new computer system. You cannot buy a new machine. These are all fairly straightforward scope things. You cannot physically rearrange your floor plan. Okay, that's actually one that may pop up that you want to be is explicit as possible. The other part of this is
when does your process stop? And where does your process or excuse me? When is your passes start? And where did you process stop
at? So when we talk about this, like when we talked about our cash register,
we've not talked about cash register get when we get to talking about our caste register example we're going to talk about. It starts when the customer walks up to the cash register, and it ends when the order is given to the kitchen.
When we talk about this, it could start when the customer opens the door to the restaurant, and it could end when the customer receives their order. So you want to be very specific at the start and stop points. It's very important we start talking about process mapping. It's very important when we want to make sure that we don't want to have scope creep,
which is when we started doing more than we committed to you.
Your charter is also going to need your team members. So if you remember back to those six rolls that team members play on our lean Six Sigma project teams, you're gonna want who your team member is and what their role is. So if I have Bob as my subject matter expert, I want a document.
Bob is my subject matter expert, as compared to Jon, who is my stakeholder.
I want to make sure that I know that John is my stakeholder, representing wherever John works. Um,
but you want to be very explicit. And remember, we've talked about setting the ground rules and making sure that we show that were thoughtful. Knowing what that team member is and why they're there is very important to committing towards moving forward with your project
phase completion time frame. So we talked quite a bit about lean. The demonic projects are G n really 3 to 6 month long projects. We know that they're gonna be greater than a month, because if they could be done less than a month, they're probably going to be a quick hit. But there's a lot of subjectivity in
how long the phases are going to be done.
And the more you do projects, the more sophisticated you'll get with a sense of it. Like when you start looking at your metrics, you're like, OK, this one's pretty straightforward. We know how to develop metrics plan. We can probably do this in three weeks. Okay, well, this one's not a straightforward. We probably need six weeks. So you're gonna want to throw some very high level
timeframes. And that's just a
you your project team. Your sponsors know what the expectations are for when you're going to be done with the project. You don't want zombie projects that just going and going and going. You wanna have a line in the sand somewhere,
so test your knowledge. True or false, A project charter cannot be changed once it's approved by a sponsor.
This is false, but we have talked about quite a bit that this is a living document and you need to collaborate with your sponsor. Sponsors can re approve or revise. You do want to keep the revision history so we all know what we changed and why. But it can be revisited
even after it's been approved. The initially in our tool hate review.
So Project Charter establishes the expectations and scope for the project. We know our problems stand that we know our business case. We know our objectives, who our team members are, what we can and can't do, and when we think we're going to get it close to done by, it provides a common point of reference. So for both the team members
and your sponsor, these air all lumped together
and the rest of the organization so you can start talking about what it is you're doing and why? And then it consolidates information for your sponsor to approve. So this is where I can hand you one document and say, this is our proposal for a lean six Sigma project. Review it and then get a hopefully a quicker answer.
All right, guys, that was Project Charter. Our next module is defying the toll gates, and then we're getting ready to move into measure. Thank you, guys.
Up Next