9 hours 53 minutes
Hi, guys. I'm Katherine MacGyver, and today we're going to go over Project charters. Just is a really quick refresher. So pulling together all the concepts we've been talking about in the last couple of modules so literally today, wrapping it all up, put it in a nice, neat package for us. This is going to set the foundation.
Four are lean six Sigma Project
We did go over this in yellow belt. So if there's anything that you want additional information on, don't hesitate to reference back to the project Charter modules as well. So when we talk about what is a project charter and why do we care about a project charter? Really? What we're talking about is expectation management.
in, aside from the fact that it documents and codifies our project, really, it tells us What are we going to work on? What are what we have available to apply towards that? What are our objectives like, what do we think we're going to get done from this project, and why does it matter?
So we're gonna have these key elements to our project,
and we want to make sure that they're set and stone
understanding that the charter can expand as we go through it because that keeps us focused. So when we are three months from now, being like God, what did we do? Hear the project charter is going to be a reference point
for not only you as a project team where you're trying to figure out, Do we go ahead and look at this since we opened the hood or don't wait, but also for the organization.
So at any point in time, somebody can ask, What exactly are you guys doing with your two hours every week in the conference room? This these air, the objectives that we're working towards Here's the problem we're trying to solve.
So with that, it's important to keep in mind that your project charter is more than that document. I mean, the document is certainly important because it creates records. It gives you the reference point, like your encyclopedia. But it really is more the embodiment of the purpose of the project. So again,
when you guys start getting off track,
it gives you focus. It can function for motive, motivating or justifying your team activities. So when you start having conflicting and conflicting priorities with employees where you have so many different projects, you can go back to your charter and say this was important because of these reasons which helps keep people on track.
at any point in time, my recommendation would be to you guys. If you ever feel like your project team is getting a little scattered, go back to your charter and to give you an example of what this looks like, Um,
my project teams my big dome AIC projects usually have at least one full team meeting a week. I like to do it where we keep you in the forefront of people's minds because you lose momentum if you don't have projects all of the time. I mean, the first thing that we do in our project meeting is we look at our problems statement,
so that kind of orient everybody in that meeting. Teoh.
These are the things that were going toe work on today. It helps keep the sidebar conversations to a minimum and helps keep the project moving forward. So progressing towards those delivery bols and ultimately, solutions. So that's what it looks like from an actual tactical perspective of course. The other thing that I use it for
is when we finish our project charter and we plug in those last fields where we say, Hey, we did it
Using this is leverage and a conversation point with other executives moving forward like you want to get on board with it because look at this exciting team and all of the fun work that they did. So project charters very helpful across the organization. Important because they codify and they really service kind of your document air your
your Constitution of the project.
With that, there are seven elements that need to be on your project charter. It doesn't matter what format you use. I've seen them done in word or word processing. I've seen them done in excel or spreadsheets. I've even put a couple on Power Point because that's what worked for the organization. So how you document
is less important
the making sure that you have these seven things in this order. So the first thing is the project name, and you want to be really explicit on this. You don't want to be like code black because your project in name is what people are going to recognize this for so we could talk about the
induction process Redesign, You're gonna know up front. Okay, We're looking at the induction process. We're doing some read redesigning of it or, you know, induction process starting at, um, specifications received. But as much fun as the
kind of code names are,
you want to keep them clear, Especially when you start thinking about doing organizational wide. Lean six sigma off. So values dream. So you're going tohave the Cy Pox and next to each other. Remember, back from our side Poch discussion,
you're gonna want to chunk each one of those as its own project. Arguably. So you want to know where it fits in the value stream, so be explicit. The next thing that you want is business case. So even though you write your problem statement first you want to lead with your business case because your business cases, why does this matter?
And if you don't think if you don't understand why it matters, you're going to disengage from the rest of the charter, then you want to do your problem. Statement. This is what we need to fix Number four, your goals and objectives. You're going to want to write this in what your objectives for the project are.
You can have X as a placeholder while you come up with something realistic. But this tells us what we're going to improve
if we agree to do this project. What are we working towards in this project? So decreasing cycle time. Increasing throughput, decreasing defects, thes are all things that would be completely fair as a goal or objective when I talked about your charter being set in stone. But revise Herbal. This is one of those things
your goal is set in stone.
Your actual metric or your magnitude is revise herbal based off of your measure and analyze face more your measure phase where you understand your baseline.
The next thing is your scope. Remember, you want discreet statements, it starts here. It ends here. We can do this. We can't do this. You're gonna want to capture your team. Members also, um, pro tip here. Document what role or why those members are on the team. So if you have somebody who's a stakeholder
as compared to somebody who's a process owner, it changes there.
Position within the team a little bit, of course, understanding one person, one vote. But if you're the one who is ultimately going to be accountable for the process when it's done, you're going to view it a little bit differently than hey, I'm just invited because I know a lot about it. So keep that in mind, and then the last one is your time frame.
And remember I had talked about. You don't necessarily want to measure this in the form of your phases, like I'm gonna spend four weeks and define and six weeks a measure. Rather, use this in the form of your milestones.
So those toll gates to advance forward so I can expect a charter by X date. It becomes more tangible for your sponsors as you are having those ongoing conversations with them. It also gives your team a really easy way to get a sense of accomplishment and how much further they have to look forward to.
So with that,
that's a really, really brief conversation about our project charter refresher. If you have questions about those details, we talked a little bit about some of those in Greenville and a little bit more and yellow Belt eso. I am looking forward to see you in our next module, which is when we're going to start talking about sponsored by in.
So we're gonna talk about the questions and the pushback that you might get as you're trying to get your projects up and going, so I will see you guys there.