Project Plans

0:00Welcome to the next skill in the practical pinbox series. In this one, we're going to talk about plans, plans, and more plans. Did you know in pinbox six on page 559, there are 19 different plan names and a pile of project documents. We're not going to talk about project documents in this skill, but it's coming. Believe me, there's a lot of stuff to talk about. But here's what blows my mind . The plan tells you how to do stuff, what to do, and how to do it. So that's point number one. Well , that ain't supposed to happen. What was supposed to happen is I was supposed to check that off. The plan tells you what to do and how to do it. We know that. What I don't understand is why people don't have a plan.

0:41It's like waking up one day and you know you're going on vacation, you're going to drive from, say, Tennessee to Florida, which seems pretty easy until you remember you have to go through Atlanta. And if you've never driven through Atlanta, you absolutely want to have your GPS on when you do it. Sometimes you can go through downtown Atlanta. And other times you want to take the bypass. The point is you need your GPS to take you from point A to point B, because when things get sideways and they always get sideways when you're driving through Atlanta, you need to know how to redirect. Your project is the same way. Your plan tells you how you're going to make decisions.

1:23What tools you're going to use, the vocabulary. Everyone needs to be speaking the same language. And I'm not being literal. I think a risk means one thing. I think a plan means something else. Someone else might think it means something completely different. And that's how communication problems start right there. Not speaking the same language, not having an agreed upon language, and absolutely not having an agreed upon plan. But let me take a half step back . There are 19 different plans that are identified. And you can just make your own. There is no reason in 2025 for project managers not to have a bucket of plans. Number one, that tell them what to do and how to do it. And number two, helped them justify the leadership, what they were doing , and why they were doing it. It blows my mind. Don't be the project manager that says, well, we thought we would just wing it. Because the winging it days ended back in like 1899. So let 's dig into this.

2:23Let's keep it commonsensical. And let's have some fun.

0:00It's time to dig into these plans. So let's go. Look how magical that is. That is a stack of stuff. So let's get into it. Let's think about the triple constraints for a minute. Let me get my marker here. Let's think about the triple constraints. You got scope, you got cost, you got schedule. Here they are, right here. Got a scope plan, you got a cost plan, you got a schedule plan. They tell you how you're going to manage the cost baseline and the schedule baseline and the scope baseline.

0:35That is a terrible arrow, but you know what I was going for. So if you have these three, then you have those three, usually. But wait, there's more. If you have these three, they roll up to the performance measurement baseline. They tell you what you're measuring your execution against. So there's that. But wait, there's more more. Let's look right here at procurements. Procurements plan tells you how you're going to purchase anything. And if you purchase anything internally or externally and a dollar changes hands, that is part of your cost baseline that rolls in there.

1:14So then you need that plan right there. Well, what about risk? This guy right here. If you have any money set aside for known or unknown risk events, that also rolls into the cost baseline. So now you need this guy right there. What about resources? Well, if you have internal or external resources and you're paying for them, that's also rolling into the cost plan. And funny enough, when you're onboarding them and off boarding them, it's all part of the schedule.

1:47Wow. And I am just getting started. The communications plan here is how you plan to communicate with people, internal, external, various stakeholders, the public may be-- excuse me-- and how many different mediums are we talking? We talk an email. We talk in web pages, newsletters, LinkedIn, Facebook. I don't know. X. That's your comms plan. And it really does depend. Well, how are we going to control the versions? Version 1, 1.0, 2.0, and all that stuff.

2:18That's your configuration plan. You may not actually need that one. That one's not that big a deal. What about agile? Well, is there a development approach? Maybe. What about predictive lifecycles? You should probably have that one figured out somewhere. We're going to talk about that one. This page was left blank on purpose, so we can ignore that one. Well, what's left? The big one, change management. How you're going to keep up with all the stuff you feel like you need to change on this project.

2:50And that's a really big one. It touches the entire project. Let's clear some of this madness up and talk about some really important stuff. There are tactical plans, and there are strategic plans. And when I say strategic, I normally mean they impact the entire project. So the performance measurement baseline is one of them. The change plan, your development approach, your configuration plan, your lifecycle description, and how often you're going to have management reviews.

3:21And you might be thinking, wait a minute. That one doesn't end in the word plan. And you are right. I think I should point out that I didn't intentionally misspeak. I spoke with zeal earlier when I said, oh my gosh, there are 19 plans. Well, technically they're called components. And that's because you have things like management reviews and your development approach, and they just don't have that funny word at the end of a plan. So I'm splitting hairs here, but some people actually care about that. There are 19 components for use on your project.

3:54And I would rather you have more than less. The other issue is, why do you have them at all? If you know what you need to do and you know how to do it. Because there's this funny thing that's gonna pop up later on called the variance. The variance is the difference between what you said you were going to do and how you said you were going to do it and what you actually did. The variance is real time data. And if you don't have a plan to compare it to, you can't find the variance, also known as the difference.

4:27And if you can't find the difference, you can't figure out what to change. And if you can't change it, the variance is gonna keep happening. And sometimes you can go from bad to worse to worseer. That's the real reason you have plans. How am I gonna do it? What am I gonna do? And I'm gonna use it to find the variance. So when we come back, we're going to dig into these a little bit more.

0:00So let's talk commonality. Let's really dig into these plans and figure out what works and what's just baloney. And by baloney I mean nonsense. There are some very common items and we're going to start right here across all of these plants. For example, you can come up with a folder, either digital or real, and just start with read here first in this section. Right out of the gate you got the project name and ID. It's the same project and there's probably some sort of billable ID.

0:30Clear and unique across all of your documents. That way if it gets lost in a move or there's a merger or something happens, it's pretty easy to track down. Well, who's the PM? How do I get a hold of him or her? Someone is in charge of this circus and I want to know who it is. Even if it's just someone fulfilling a project duty, but they actually have an engineering job or another job full time. That would be more of a functional type organization. It could even be a contact this person's manager information.

1:01I don't know. But as long as someone knows who it is, you need version control folks. What's the version number? What's the date? And I'll give you a great example. I went on vacation one time when I worked for Homeland Security as a consultant. And we had great version control. And when I came back, I went to a meeting and I was sitting there looking at the update and I thought, wow, they really haven 't done anything in the two weeks I've been gone. And then when they started talking, I realized I was on the wrong version. Not only had they jumped versions, they hadn't updated anything.

1:33People go on vacation, people get sick, people get fired, people leave, people show up. Everyone needs to be on the same page. So pay attention to that. Who approved this? What's the sponsor's name? What key stakeholders or customers or vendors are involved? And who can get this information? It shouldn't be public information or public access unless that's clearly spelled out. Most of the time there's a watered down version. Just make sure you're paying attention to it because the last thing you want to do is be the project manager who put out information that wasn't supposed to be put out.

2:06But let's drive on. Other common items. What's the purpose of this plan? What's it cover? What's in what's out? And that means constraints, not constraints, exclusions. Sorry, my brain skipped to be. You should very clearly outline what's in and what's out. Because if you don't have it outlined, someone will assume, there's that word, that whatever you didn't say is out is actually in and they're going to find a way to make you pay for it. What are your objectives and goals? Whatever they are, make them short and clear. If it takes me more than 10 seconds to read your objections and goals, I 'm probably taking a nap right there on the floor. And I'm not the only one.

2:45How is it aligned to the company's organizational strategy? In a perfect world, the company's strategic vision would be here and then all the projects and programs underneath once completed support that vision. It doesn't happen that way in the real world. But if it does, and this is really an important enterprise level project, you should very clearly have this spelled out so people can stay on point and go. You know what? If we screwed this up, we're probably all updating our resume. And what did we learn from the last skill? Nothing rhymes with updating my resume. But let's move on.

3:21"Rolls and responsibilities like the organizational chart and the RACI, who's responsible, accountable, consulted and informed." This is important particularly when you have cross-functional teams, geographically dispersed teams, international teams. You may need to know who to speak authoritatively to at some point. Is that a word authoritatively or is it authoritatively? It's one of those words and you 'll know exactly what it is to someone with a word. You'll know exactly what it is to someone using either one of them towards you.

3:53We said roles and responsibilities and here's one that's important. Escalation information. At some point on your project, particularly if you're in a secure project or a secure location, someone somewhere is going to ask you , "Who are you? What are you doing here?" And if you answer those two correctly, they're going to want to know, "Well, who told you you could be here?" You need to direct them to this spot right here. Because trust me. They're going to call, they're going to want to find out, they're going to trust but verify you. So that information's pretty important. Driving on. Other fun stuff. Well, there's maintenance that happens to your plan too. What are our assumptions?

4:31Assumptions are belief you hold to be true or false in the absence of proof. A sub... I think I swallowed a bug. Assumptions can start at a very high level and become more detailed. They are also a source of risk. Because if you believe something to be true or false and it actually is the opposite, that becomes an issue real quick. A constraint is something that limits you. Like, we only have this much money. It must start no later than. It must finish no later than.

5:04What are your constraints? How are you managing change? And this is very important because if you lose control of changes, you can't figure out what happened when you need to adjust because of what happened. Take software for example. You can have bug fixes and roll out a change in some kind of a hybrid approach. And so they may say, "Alright, tonight for this change in the maintenance window, we're going to fix x, y and z." And it's very clearly documented.

5:34Well, then you go to fix x, y and z and they turn the system back on or they updated and the system doesn't act like it was supposed to act. And you're still working on it and it gets escalated. Someone somewhere is going to want to know what that change was, was it filled out properly? Who approved it? What was the expected impact? What's the fallback plan? Just to name a couple of choices. What about review and updates? When are we doing it? Quarterly, monthly, every time the wheels come off the bus? I have no idea, but you should very clearly know that.

6:06Here's another one. Who can update it? Not everyone should be able to get into your information and make changes because that's how you lose control. Other tools and references. What tools and templates are we using? If I have a configuration heavy plan, this is very important. What systems like IT systems are we using? We may have multiple testing platforms and by running the exact same kinds of tests, we get different results. Sometimes the system you are using matters.

6:41Some of them are very specific to what you are doing. What about reference documents? Well, I gave you a reference document for this training. The PIMBOC version 6. And what about the revision history log? When did we change it and why did we change it? And who changed it? I don't know, but I bet we can figure it out. As long as we have a log. And last but not least, there's some optional stuff. You need definitions and acronyms. You don't have any acronyms there are in the federal space. All of them. And there's what I think an acronym means and there's what someone else thinks it means.

7:18Acronyms and jargon kill projects slowly. You need a glossary of terms. What do they mean? Particularly if they're public facing and cross functional. Engineers can put out all kinds of words and I heard some great ones last week from someone who was teaching me autonomous neural networks. I never heard Sigm oid. I never heard Raylu. And I never heard Pi Hat. Pi Hat was not what I thought it was. In fact, it's not a hat at all. It's Python coding language. But now I know. And there was a glossary involved to spell some of that out for me. For lay people like myself who are outside the loop of awesomeness, we need to know what's what. What's the approval process?

8:01Do we have a process flow? People like visuals, a picture's worth a thousand words. Make it shiny, make it pretty, and they will come. They will pay attention. They will use it. And last but certainly not least, why are we going to do this in the first place? Why are we going to put forth the energy? Because you need structure. Every team needs a team identity. It's very important. There needs to be very clear boundaries. You're in, you're out because you can have multiple teams doing multiple things. You need traceability, accountability to go with that other word that sounds like and rhymes with and is responsibility. And last but certainly not the leastest, you need a professional looking and polished plan. Why? Because if you look shiny and you look like you know what you're doing, you probably do know what you're doing.

8:52Or at least that's what your senior stakeholders are going to think. So those are some of the common items we're going to talk about or we have talked about rather. When we come back, excuse me, I'm all excited because when we come back, we're going to talk about strategic plans. So let's get ready.

0:00Alright, after all that build up we have finally made it to the strategic plans or as one former president likes to say, "strategic replants." I think you can probably figure out which one it is. So let's see what we're going to do. We've got the performance and measurement baseline, that one's cool. Change plan, your development approach, configuration plans, management reviews, and your lifecycle descriptions. These are not check the box items, these are very important.

0:31Now, do I think you need every one of them? No, probably not, but as your project gets bigger, as the money gets larger, as the timeline expands, as the team grows, as the visibility increases, you need more plans. More plans equals more control, and trust me, you'll know when you lose control, and you can probably trace it back all the way back to some issue at planning. So let's clear the screen and let's go forward. Let's talk about the performance and measurement baseline.

1:04What is it? Well, it's a combo of your triple constraint baselines. Excuse me. So that's your scope, your schedule, and your cost baselines. And in case you forgot, you got your scope, you got your schedule, you got your cost, your classic triple constraints. You can't change one without affecting at least one other. And most of the time, you can't change one without affecting both of them. So why look at it? It's your target. It's what you're aiming at. Imagine you have an actual bullseye. That's terrible, but you got your little bow over here and your guy shooting arrows at it. Let's put some Fletches on there. He's shooting at it. The better, not want to say it that way, the more detailed your target is, the better your aiming point is going to be. If you're aiming at the side of a barn with a bow and arrow, okay, it's this huge target. Hopefully you can hit it, but you're just going to keep hitting this massive target.

2:04As you have smaller and smaller aiming points, your aim, your skill, will get better. And that's exactly what we're talking about here with your performance and measurement baseline. You have a target. It's where you're trying to go. And the more detailed it is, the more troll you're, the more troll. I feel like I'm trolling myself. The more detailed it is, the more control you are likely to exercise in trying to hit it. That's why you have a cost or correction. That's why you have a performance measurement baseline. So what's the pro tip? Outline your approach and get stakeholder buy in. What do I mean? Well, don't show up at your first management review and say, "Hey, here's the performance and measurement baseline, and this is how we did."

2:52Because if you didn't have a previous expectation set with them, they may not have any idea what you're talking about. In fact, they may look at your data and go, "I didn't ask for this. I didn't want this." If you'd previously set a clear expectation on what you were going to do and how you were going to do it, it's much better received. That's why you let them know what the target is, how you're aiming at it, and what metrics you're going to use. So let's clear the screen. Let's drive on. As soon as I figure out where my pointer is, here it is. The change plan. What is it? It's how we change. How we change stuff. Why? Why look at it? Set a proper expectation. And roles. Who's going to do what? But everyone should know. Your change plan can be as simple as I'm sitting in a room drinking a cold frosty root beer, looking at these change requests is and I'm making changes.

3:47Another one might be we have a formal change control board with all the senior leadership once or twice a month and we review each of these change requests and decide if we're going to approve or reject them. Then we're going to have to figure out how much money, how much time, and how many resources we're going to actually apply to each one of these changes. Now that's very formal. And the bigger your project is, the more control you're trying to exercise, the more formal your train change, excuse me, request should be. If it talks so fast that sometimes your words just get ahead of your lips, well sometimes it happens to me, particularly when I'm excited about something.

4:24And I'm always excited about change because it is the only constant on a project. What's the pro tip? Map the procedure. Let's call it the process. Map it out. Make sure everyone understands it. And make sure you have change under normal circumstances and change under emergency circumstances. Most of the time most of your project changes are going to be super simple and run of the norm stuff. But you may have emergency changes where we can't wait until next month when we have a formal change board. How do we change things when that happens? That'll become very important and I promise you as soon as you don't have an emergency change process, you're going to need one. Your development approach. Hmm, I wonder what this sounds like. I don't know Bob, tell us. Well your development approach is justification for project methodology. You know what I mean. So why look at it so we can decide which is best. So what are we talking about? Well there are a couple of different kinds of methodology you can use for your development approach. If you're doing software development, it's going to be some form of agile, probably scrum. But if you go all in on scrum, you're all in. You're not halfway in or you're not doing scrum. But if you have an

5:41infrastructure type project, you may be using predictive or waterfall and you probably should. But what about a hybrid approach? A combination of predictive and agile. You have to justify to your stakeholders why you're going to use whatever methodology you're going to use and get them to sign off on it because they're responsible for it. If this project fails and many of them do, someone above them is going to say, hey, how did you come to this conclusion and who signed off on it? Because now we're playing pain the finger. We're playing the finger pointing game and you don't want to be on the receiving end of that finger. You need to explain why you're doing whatever you're doing. So pro tip here is get buy in. Get them to sign off on it because if they don't, eventually someone's going to say, why did you do this? Who said you could do it and it's time to update your resume? I say that a lot, but it happens a lot more often than it should. Your configuration plan is all about version control.

6:44Why look at it? Accountability. Accountability. Trackability. I may have just made that word up, but I don't care. Trackability. Imagine a project, an infrastructure project that lasts two years. Project managers and team members come and go. There's a leadership change. Two years down the road, they open up this wonderful building and about two months later it collapses. What do you think is going to happen? Well, it's called an investigation and it rhymes with someone's in serious trouble. A forensic accountant somewhere is going to come back and start pulling these project files and they're going to say, all right, version one was this.

7:22Version 100 is this and they're going to start filling in those blanks and they're going to start figuring out who did what and when and based on what date. They will narrow it down to what happened to potentially cause this collapse. And again, I hope this never happens, but if you just look at the news, you can look at crane collapses, you can look at bridge collapses or bridge failures or dam failures and stuff like that. And the NTSB, the National Transportation Safety Board and the Occup ational Safety and Health Administration, all kinds of federal agencies get involved and they investigate these.

7:56They want to know what happened and version control matters. So here's a pro tip. Keep a running sheet version one, two, three, four, all that stuff and every time you change versions, get a signature, get a date. That way you can keep up with it. That way there's no need to go tracking stuff down in boxes and hidden warehouses someplace. You got it on a single hard copy and digital sheet in case you need it, you've got it. So let's take a break right there to contemplate and when we come back, we will wrap up these strategic plans.

0:00Welcome back from the break. I hope it was a good one. We got two more so let's dig into them. Management reviews. What are they? That's where we compare the plan against the actual. Let's just call it versus the actual. Well, what are we talking about, Bob? We're talking about did we do what we said we were going to do when we done did said we would do it? And hopefully the answer is yes. There's a little formula I like to use. It is this. Plan. The plan. Minus the actual equals the variance. The variance is not your friend unless the variance is positive. We're at a minimum neutral.

0:39And here's what I mean. There's a cost variance. The plan was to spend $500. The actual spend was $600. Some quick math. $500 minus $600 gives you a negative cost variance of $100. That's issue number one. Issue number two is why did it happen? You have to figure that out. You're going to keep doing it. Once you figure that out, you move on to solution number one. What are we going to do about it? You have to explain this to leadership.

1:10That's why we have what was it? The performance and measurement baseline earlier. We have to tell them, well, this is what we said we've been doing. And this is what we actually did. Well, now we know. So why look at it? To see progress. And, whoops, make decisions. Your project timeline is like this. You got B, you got A. You're starting right here. And as you do this, going down the road, you're going to need course corrections. And you're going to try and stay as close to the line that you said you were going to do. Now things happen.

1:45But if you start doing this right here, that's going to alarm people. You're going to need a course correction to get you back on track. Or you're going to have to figure out what you need to change. So what's the pro tip here? Tailor to your audience. And here's what I mean. Let me get rid of some of this here. Tailor to your audience. Senior leaders get summary data. Your boss gets detailed info. Senior leaders do not have enough time to listen to everything you have to say about your project. They want the high level stuff and it usually comes down to three colors. Green , yellow, red. You need to know what they are and why they are what they are.

2:21And if they're anything other than green, what you're going to do about it. If you can't answer those questions, you're going to be in that review a lot longer than you want to. And I have an easy gauge of project progress. The longer I stay in a management review, the worse my project health is. I should be in and out because if that happens, my project is fantastic. But if I'm stuck in there getting grilled like some kind of an investigation, there's a problem. And you need to fix that. So make sure you're tailoring your information to the appropriate level and ask them up front what is most important to them.

2:57And here's another pro or tip. Do not ask 10 stakeholders what information they want to see coming into this management review. Previously, you went to them and said, "Hey, I've already got a format that I 've used before and everyone agrees with it. Is this acceptable for you?" If you give them something that's already done and all they have to do is go, " Yep, I like that. That's perfect." You're good to go. You lead their thinking. This is project management. But if you go to 10 of them and say, "How about if you tell me what you want to see?"

3:27You're going to get 10 different points of view, 10 different ideas, 10 different formats, and now you're on the hook to deliver it. So don't do that. So let's clear this one and let's move on to one more. We are cooking with Greece, folks, as I like to say. Last one. What is our lifecycle description? What are our phases? What are phases or roadmap? Why look at it? So you have a clear picture and you can set phase deliverables.

4:00And here's what I'm talking about. Some projects last two, three, four years. It's bonkers and it happens. Some really big projects take a long time. Do you want to wait three or four years to look at the final deliverable before you can decide what you want to see? Well, I'm not sure if you're on the right path. If you did the right thing. Because the answer is no. Here's an easy predictive outline. Let's say we have concept, design, build, implementation, close out. That's an easy one. You need to, number one, understand what your phases are and all of your stakeholders do too.

4:30And number two, and most importantly, you need to know exactly what your phase deliverables are because that's your point to course correct this project. If you're staying on path and delivering exactly what you said you were going to deliver, you're a rock star. But if you get to that point, they're like, you know what? That is not what we wanted at all. Or this has changed and now we need to redirect. You have an opportunity to do that at the end of every phase. Or actually at any time on the project, if it's really severe. In the world of agile, scrum in particular, the longer sprint can last as a month.

5:05And at the end of the month, it is just expected. They'll have a usable increment, meaning they have some kind of small deliverable, called an increment, at the end of that phase. If they don't like it, or if it's not quite right, they immediately launch into the next sprint where they can adjust it, fix it, do something different, it doesn't matter. But stop and think about how cool that is. They deliver something every single month or multiple something's. And a sprint may only be a couple of weeks. Let's see. Deliver something every couple of weeks. Ever? Every couple of weeks to see if it's the direction I want to go in or wait a couple of years.

5:44One of them sounds a lot better to me. However, with that caveat, infrastructure projects that are heavy in documentation, heavy in oversight, infrastructure projects that last a long time are heavy in documentation and decision making. That's not how scrum works for software. So, figure out which one works best for you and have very clear deliverables at the end of each phase. Whoo! Alright, so what's my pro tip? Let's see. Have exit criteria and spell it out. That way everyone knows exactly what you're doing.

6:20Alright, my brain feels a little fried. Yours probably does too. Trying a new camera. I've had a lot of coffee and some really buzzing right now. You ever feel like you can feel the earth turn because I feel that right now? I say we go with what this guy's saying and we make me stop right now. When we come back, we'll get into the tactical plans and these are the fun ones.

0:00Excellent, we have finally made it to the tactical plan. So let's check them out. You have the scope plan and you had the requirements plan. Now notice they are tied together because the requirements plan and the scope plan are tied to the scope baseline. So we're going to have to talk about that. Then you have the cost plan and the procurement plan tied together, tied to-- excuse me-- the cost baseline. Why does it matter?

0:30Because if you get one of these plans wrong, it's going to have a cascade effect up and down through your project documentation. Well, the same thing happens with the quality plan and the process improvement plan. The same thing happens with your resources and your team plan. Now this one is a freebie. It may or may not exist in your world, but it is still relevant. And here's an easy way to change it. What if you call this the HR resource plan, your peoples? OK, Bob's on to something.

1:02Remember, this is the practical PIMBOC series. We ain't studying for the PMP no more. Well, then you have the knowledge plan tied to the data management plan because both of these are tied to info, information. Obviously, there's a schedule plan tied to the schedule baseline, then you have a risk plan tied to everything. These two should be tied together because when we went from PIMBOC 5 to PIMBOC 6, PMI took about half of communications and made stakeholder engagement.

1:35So they're tied together too. So there's a lot going on. Here we go.

0:00Are you having fun yet? I told you these would be great. I love the tactical plans because you can really get into the weeds on them. The high level strategic plans, boring, the tactical plans, that's where you make your money. So let's do this. So the scope plan, what is it? How we manage the scope? And let's go one step further, the scope baseline. Think, well the requirements plan is tied to it. Why? Because this is how we collect the needs, demands, the wants that turn into the scope baseline.

0:36These are ridiculously important. And remember, the scope baseline is three pieces. We haven't even talked about that yet. The scope statement, the WBS, and the W ubus dictionary. There's a lot going on here. What is the pro tip? Well, for starters, you need a requirements traceability matrix. This is a project document tied to the requirements plan. Basically it means if it's not in the requirements traceability matrix tied to a project objective , it should not make its way into the scope plan. Either it's rolls up into something or it rolls out. It simply does not belong. The cost plan is all about managing the cost baseline. Well, why is it tied to the procurement plan? Because procurements is all about purchasing. How we're going to do it, when we're going to do it, what currency we're going to use, who can do it, is a very important one.

1:41And when ties both of them to the schedule. Now let me give you a pro tip here. Let me go ahead and put pro tip over there. Pro tip. Let me give you another pro tip since we're talking about the requirements traceability matrix. During your project, as you deliver stuff, small deliverables, sub deliverables, work packages, if they're in the requirements traceability matrix, check them off, get them signed off on right then. Do not wait until the end of the project to get 100 things signed off on and verified that they're done. If you can do 567 here and there at the end of each phase or whenever they're delivered, do it then. That way when you get to the end, you of course correct it along the way and closure should be very easy. Ah, where was I? Oh, cost plan pro tip.

2:31Actually, this works on both. Limit the number of buyers. The more people who can purchase things, the more likely you're going to have cost overruns. Don't do that. And have limits. Limiting who can purchase and how much they can purchase is all about control. Smaller variances mean smaller corrections. Think about this for just a minute. Would you want to find out from your bank if you were say $50 overdrawn versus $500 overdrawn? Now that can happen for a number of reasons, but it happens on projects too all the time. So limit who's doing it, limit how much they can do. There should be an authority level for each one of these. So let's clear the screen and keep on going. Let's talk about the quality plan. The quality plan is all about, well, let me get the right, um, writer here is all about achieving quality. Quality is not an accident. You either aim at it and you hit it or you don't. You do not stumble your way to better quality does not happen. And the process improvement plan is tied to that because if you aren't achieving quality, it only happens for a couple of reasons. One is your,

3:49let me rephrase that. One is you missed it. Two is the process stinks. And if the process stinks, that's where the process improvement plan comes from. Now here's the pro tip for quality. Have metrics, make sure it is well defined. And I'll tell you why. I once had a customer ask me, how do you know if you've achieved quality? This is a true story. And I said, well, they're quality metrics. I need to know what those quality targets are. And they need to be measurable. I need to make sure I can measure them so I can show I achieved them. For example, if the quality metric is 100 rubber balls in a cardboard box, I can count the rubber balls. I can count the box. It's very simple. And then the customer said, well, what if we can't define what quality is? And without missing a beat, my response is and will always be if you cannot define what quality is, then I will always achieve it. And the underlying message there is simple.

4:45All I have to do is convince you that I've achieved quality, which is why well defined metrics are so important. Your process improvement plan tip, map your processes. Why? Because of the kinds of waste. Now in a whole other section of training, we're going to talk about the kinds of waste, the waste of waiting for signatures. How long have you ever waited for someone to get back to you with something signed that probably could have taken them five minutes? That impacts your schedule, that impacts your budget. What about the waste of rework? What about the waste of defects? What about the waste of movement? What about the waste of transportation? That's why your process is being mapped out or so important. Because if you have an element in your process that's not delivering value, air quotes, there's likely a kind of waste there that you can fix. We'll talk more about that in another skill. The resource plan. This is all about stuff. And your team management plan is all about people. Stuff is simple. When and what? Here's a pro tip. Use just in time. Order it only when you need it. That way you don't have to deal with storage. I misspelled

6:01people in the diva catch up. So back to just in time. Order it only when you need it. That way you're not worrying about the storage and the additional cost. Plus there's an additional cost of security as well. Now people, how we onboard them. Bring them on to the project. How we let them go. I call that off boarding pro tip. Invest in team building. The best teams that work together or should I say the teams that work best together are those teams that have rapport and especially harmonious connection with one another. They do things for one another because they want to. Not because they have to. And the way to make that happen is team building. Even if it's something simple.

6:41Go to lunches together. Why am I telling you this? Because in many companies and on many projects, this is a cost. You can, this is a cost. Excuse me. You can expense directly to and against the project. So have a plan for that. This is super important if you have brand new teams, international teams, cross functional teams. So let's stop right there. When we come back, we 're going to wrap it up.

0:00Alright, it's time to put these tactical plans to bed and turn out the lights, so let's do it. Now these two will probably surprise you a little bit, so let's start with this one. Data management is all about info, storage, what are we doing with it, and where are we doing it with it, what we're doing to it. You know what I mean, why does it matter? Because when you start storing project information, you can actually capture personal information of your employees.

0:30There may be socials, full names, birthdays, phone numbers, addresses, and stuff like that. You need to figure out what you're doing with that. So the tip here is tightly control the access, and when not needed, here's another tip. When it's not needed, destroy it. People come and go on your project and in your company all the time. Do not hold on to that information. I've seen this turn into lawsuits later on for data breaches. Don't do that. So here we're talking about info.

1:02Well, it's a kind of knowledge, but that's not the knowledge we're talking about here. We're talking about knowledge transfer. I think it's implicit or tacit knowledge. The word escapes me at the moment. Think of it this way. Let's say you have a senior engineer and a junior engineer, and this guy, this person is going to retire in a year. Well, how do you get what he knows into that person right there? That's knowledge transfer. You do not want your smartest, brightest, bestest people taking all the tips and tricks that they've learned out the door with them when they retire.

1:41So the tip here is have mentoring. A lot of companies talking about it, but they don't do it. Mentoring. Make sure you are squeezing that grape for all of the juice you can get and pouring it into that junior person because number one, you don't want that information walking out the door. And number two, you want that person who's going to stay to gather as much information as possible and build their career right there. There are a lot of things going on here, but how many times have we seen someone with 30 plus years in a company just up and say, "You know what? I'm out of here." And they give two weeks notice and there is no knowledge transfer.

2:22That's a huge problem and that's a monstrous miss. Don't do that. The schedule plan is all about, who ops, all about with only two L's, all about schedule management. It's all about managing the schedule baseline. Now here's the pro tip here for the schedule plan. Have a clear modeling techniques. Have clear model. Let me re- spell that. Have clear modeling techniques. This will help people understand how you drew the conclusions you drew on the schedule. Did you do automatic scheduling? Did you do manual scheduling? Did you use any early start and finish, late start and finish? How did you do that exactly? How did you build this schedule model? Why do you have so many...

3:12Oh, the phrase she's jumped out of my head. This is why you can't crash parach utes in your 20s, folks, because sometimes you forget things. Oh, buffers. How did you come up with these buffers? Because those buffers aren't tied to risk. If you can't explain what you're going to do, what your methodology is in the schedule plan, you're going to have problems explaining your schedule baseline later on. I promise it. So the risk plan is your risk methodology. The tips here, whoo. There are some serious documents here. You need a probability and impact matrix. You need impact definitions. You need probability definitions and you need risk statements. Risk is one of those areas where project managers just hope and pray. And I hate to say it.

3:59Prayer is not a not a risk strategy. You have mitigated void transfer, share enhanced exploit and acceptance in nowhere. Did you hear me say prayer? Now I'm down with a good prayer. It's not a strategy. And because it's not a strategy, you need very clear risk statements. And here 's two good examples. You've probably heard if this happens, then that occurs, which doesn't tell me anything. But what you probably haven't heard is something called risk meta-language. If this occurs, then that happens, resulting in this cause, risk and effect. That's called meta-language. It's a far better technique for risk. And we're going to talk more about this later on in this skill series . So let's get this done and wrap it up. Your comms plan and your stakeholder plan. This is, oh, this is our strategy for keeping stakeholders engaged. And by engaged, I mean on our side. And by on our side, I mean supportive. They are supporting our project. How do we do that? Well, one of the ways we do that is with the strategy of communications. This is the execution of info

5:16distribution. These are tied together because again, back in PIMBOC 5, PMI, Tor, Communications Management and Half, and gave half of it to stakeholder engagement. So the pro tip here is easy. Not the po tip. The pro tip is simple. Do these together because they are tied together. You cannot do one without the other because I promise you, if your stakeholders become detached from your project, there's either something political going on at their level or your project just isn't that interesting or your project just flat stinks and you're causing them nothing but headaches.

5:54The way to stay ahead of that is with the solid communications plan. Commun icate with them the way you said you would, when you said you would, and very often. There's a sweet spot between not enough and too much. You need to find it. And if you do that, you will keep your stakeholders engaged. You want supportive stakeholders, leading stakeholders, coaching stakeholders who are behind you 100%. What you don't want are negative stakeholders. People working against you and there are plenty of them. There are plenty of reasons out there for people to view your project failure as a win for them. So these two are tied together and treated that way. I think that's enough for now for this set. Let's wrap this up and see what we can do in the test your knowledge because it's It's coming real fast.