Project Plans

0:00Welcome to the next skill in the practical pinbox series.

0:03In this one, we're going to talk about plans, plans, and more plans.

0:07Did you know in pinbox six on page 559, there are 19 different plan names and a

0:16pile of project

0:17documents. We're not going to talk about project documents in this skill, but

0:21it's coming.

0:21Believe me, there's a lot of stuff to talk about. But here's what blows my mind

0:25. The plan tells you

0:26how to do stuff, what to do, and how to do it. So that's point number one. Well

0:31, that ain't supposed

0:31to happen. What was supposed to happen is I was supposed to check that off. The

0:35plan tells you

0:36what to do and how to do it. We know that. What I don't understand is why

0:40people don't have a plan.

0:41It's like waking up one day and you know you're going on vacation, you're going

0:46to drive from, say,

0:48Tennessee to Florida, which seems pretty easy until you remember you have to go

0:53through Atlanta.

0:54And if you've never driven through Atlanta, you absolutely want to have your

0:58GPS on when you do it.

0:59Sometimes you can go through downtown Atlanta. And other times you want to take

1:03the bypass.

1:04The point is you need your GPS to take you from point A to point B, because

1:10when things get

1:10sideways and they always get sideways when you're driving through Atlanta, you

1:15need to know how to

1:17redirect. Your project is the same way. Your plan tells you how you're going to

1:22make decisions.

1:23What tools you're going to use, the vocabulary. Everyone needs to be speaking

1:28the same language.

1:29And I'm not being literal. I think a risk means one thing. I think a plan means

1:34something else.

1:36Someone else might think it means something completely different. And that's

1:39how communication

1:40problems start right there. Not speaking the same language, not having an

1:44agreed upon language,

1:45and absolutely not having an agreed upon plan. But let me take a half step back

1:50. There are 19

1:52different plans that are identified. And you can just make your own. There is

1:56no reason in 2025

1:58for project managers not to have a bucket of plans. Number one, that tell them

2:04what to do and how to

2:05do it. And number two, helped them justify the leadership, what they were doing

2:09, and why they

2:10were doing it. It blows my mind. Don't be the project manager that says, well,

2:15we thought we

2:16would just wing it. Because the winging it days ended back in like 1899. So let

2:22'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.

0:02So let's go.

0:03Look how magical that is.

0:06That is a stack of stuff.

0:09So let's get into it.

0:11Let's think about the triple constraints for a minute.

0:13Let me get my marker here.

0:15Let's think about the triple constraints.

0:17You got scope, you got cost, you got schedule.

0:20Here they are, right here.

0:21Got a scope plan, you got a cost plan,

0:23you got a schedule plan.

0:25They tell you how you're going to manage the cost

0:29baseline and the schedule baseline and the scope baseline.

0:35That is a terrible arrow, but you know what I was going for.

0:38So if you have these three, then you have those three,

0:43usually.

0:44But wait, there's more.

0:46If you have these three, they roll up

0:49to the performance measurement baseline.

0:51They tell you what you're measuring your execution against.

0:56So there's that.

0:57But wait, there's more more.

1:00Let's look right here at procurements.

1:01Procurements plan tells you how you're

1:03going to purchase anything.

1:05And if you purchase anything internally or externally

1:08and a dollar changes hands, that is part of your cost

1:12baseline that rolls in there.

1:14So then you need that plan right there.

1:17Well, what about risk?

1:18This guy right here.

1:20If you have any money set aside for known or unknown risk

1:24events, that also rolls into the cost baseline.

1:28So now you need this guy right there.

1:30What about resources?

1:32Well, if you have internal or external resources

1:35and you're paying for them, that's also

1:37rolling into the cost plan.

1:40And funny enough, when you're onboarding them and off

1:44boarding them, it's all part of the schedule.

1:47Wow.

1:48And I am just getting started.

1:51The communications plan here is how

1:53you plan to communicate with people, internal, external,

1:57various stakeholders, the public may be-- excuse me--

2:00and how many different mediums are we talking?

2:02We talk an email.

2:03We talk in web pages, newsletters, LinkedIn, Facebook.

2:07I don't know.

2:08X. That's your comms plan.

2:10And it really does depend.

2:11Well, how are we going to control the versions?

2:14Version 1, 1.0, 2.0, and all that stuff.

2:18That's your configuration plan.

2:20You may not actually need that one.

2:23That one's not that big a deal.

2:24What about agile?

2:26Well, is there a development approach?

2:29Maybe.

2:30What about predictive lifecycles?

2:32You should probably have that one figured out somewhere.

2:34We're going to talk about that one.

2:36This page was left blank on purpose,

2:39so we can ignore that one.

2:41Well, what's left?

2:42The big one, change management.

2:44How you're going to keep up with all the stuff you feel

2:47like you need to change on this project.

2:50And that's a really big one.

2:51It touches the entire project.

2:54Let's clear some of this madness up

2:56and talk about some really important stuff.

2:58There are tactical plans, and there are strategic plans.

3:03And when I say strategic, I normally

3:06mean they impact the entire project.

3:09So the performance measurement baseline is one of them.

3:12The change plan, your development approach,

3:14your configuration plan, your lifecycle description,

3:18and how often you're going to have management reviews.

3:21And you might be thinking, wait a minute.

3:23That one doesn't end in the word plan.

3:26And you are right.

3:27I think I should point out that I didn't intentionally misspeak.

3:31I spoke with zeal earlier when I said,

3:34oh my gosh, there are 19 plans.

3:36Well, technically they're called components.

3:39And that's because you have things like management reviews

3:42and your development approach,

3:43and they just don't have that funny word

3:45at the end of a plan.

3:46So I'm splitting hairs here,

3:48but some people actually care about that.

3:50There are 19 components for use on your project.

3:54And I would rather you have more than less.

3:58The other issue is, why do you have them at all?

4:01If you know what you need to do and you know how to do it.

4:04Because there's this funny thing

4:06that's gonna pop up later on called the variance.

4:10The variance is the difference between

4:12what you said you were going to do

4:13and how you said you were going to do it

4:15and what you actually did.

4:17The variance is real time data.

4:19And if you don't have a plan to compare it to,

4:22you can't find the variance, also known as the difference.

4:27And if you can't find the difference,

4:29you can't figure out what to change.

4:31And if you can't change it,

4:33the variance is gonna keep happening.

4:34And sometimes you can go from bad to worse to worseer.

4:37That's the real reason you have plans.

4:40How am I gonna do it?

4:41What am I gonna do?

4:43And I'm gonna use it to find the variance.

4:45So 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

0:05what works and what's just baloney.

0:07And by baloney I mean nonsense. There are some very common items and we're

0:11going to start right here across all of these plants.

0:14For example, you can come up with a folder, either digital or real, and just

0:20start with read here first in this section.

0:24Right out of the gate you got the project name and ID. It's the same project

0:28and 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

0:35move or there's a merger or something happens, it's pretty easy to track down.

0:39Well, who's the PM? How do I get a hold of him or her? Someone is in charge of

0:44this circus and I want to know who it is.

0:46Even if it's just someone fulfilling a project duty, but they actually have an

0:52engineering job or another job full time.

0:55That would be more of a functional type organization. It could even be a

0:58contact this person's manager information.

1:01I don't know. But as long as someone knows who it is, you need version control

1:05folks. What's the version number? What's the date?

1:08And I'll give you a great example. I went on vacation one time when I worked

1:12for Homeland Security as a consultant.

1:14And we had great version control. And when I came back, I went to a meeting and

1:19I was sitting there looking at the update and I thought, wow, they really haven

1:22't done anything in the two weeks I've been gone.

1:25And then when they started talking, I realized I was on the wrong version. Not

1:29only had they jumped versions, they hadn't updated anything.

1:33People go on vacation, people get sick, people get fired, people leave, people

1:38show up. Everyone needs to be on the same page.

1:40So pay attention to that. Who approved this? What's the sponsor's name? What

1:45key stakeholders or customers or vendors are involved?

1:48And who can get this information? It shouldn't be public information or public

1:53access unless that's clearly spelled out.

1:55Most of the time there's a watered down version. Just make sure you're paying

1:59attention to it because the last thing you want to do is be the project manager

2:03who 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

2:11it cover? What's in what's out? And that means constraints, not constraints,

2:17exclusions. Sorry, my brain skipped to be.

2:20You should very clearly outline what's in and what's out. Because if you don't

2:24have it outlined, someone will assume, there's that word, that whatever you

2:29didn't say is out is actually in and they're going to find a way to make you

2:33pay for it.

2:34What are your objectives and goals? Whatever they are, make them short and

2:38clear. If it takes me more than 10 seconds to read your objections and goals, I

2:42'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,

2:51the company's strategic vision would be here and then all the projects and

2:56programs underneath once completed support that vision.

3:00It doesn't happen that way in the real world. But if it does, and this is

3:04really an important enterprise level project, you should very clearly have this

3:08spelled out so people can stay on point and go. You know what? If we screwed

3:12this up, we're probably all updating our resume.

3:15And what did we learn from the last skill? Nothing rhymes with updating my

3:19resume. But let's move on.

3:21"Rolls and responsibilities like the organizational chart and the RACI, who's

3:26responsible, accountable, consulted and informed." This is important

3:31particularly when you have cross-functional teams, geographically dispersed

3:35teams, international teams.

3:38You may need to know who to speak authoritatively to at some point. Is that a

3:44word authoritatively or is it authoritatively? It's one of those words and you

3:49'll know exactly what it is to someone with a word.

3:49You'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.

3:56Escalation information. At some point on your project, particularly if you're

4:01in a secure project or a secure location, someone somewhere is going to ask you

4:05, "Who are you? What are you doing here?"

4:07And if you answer those two correctly, they're going to want to know, "Well,

4:10who told you you could be here?" You need to direct them to this spot right

4:14here. Because trust me.

4:15They're going to call, they're going to want to find out, they're going to

4:19trust but verify you. So that information's pretty important.

4:22Driving on. Other fun stuff. Well, there's maintenance that happens to your

4:27plan too. What are our assumptions?

4:31Assumptions are belief you hold to be true or false in the absence of proof. A

4:36sub...

4:37I think I swallowed a bug. Assumptions can start at a very high level and

4:43become more detailed. They are also a source of risk.

4:49Because if you believe something to be true or false and it actually is the

4:52opposite, that becomes an issue real quick.

4:55A constraint is something that limits you. Like, we only have this much money.

5:01It 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

5:09important because if you lose control of changes, you can't figure out what

5:15happened when you need to adjust because of what happened.

5:19Take software for example. You can have bug fixes and roll out a change in some

5:25kind of a hybrid approach. And so they may say, "Alright, tonight for this

5:29change in the maintenance window, we're going to fix x, y and z." And it's very

5:33clearly documented.

5:34Well, then you go to fix x, y and z and they turn the system back on or they

5:38updated and the system doesn't act like it was supposed to act.

5:42And you're still working on it and it gets escalated. Someone somewhere is

5:46going to want to know what that change was, was it filled out properly? Who

5:51approved it? What was the expected impact? What's the fallback plan? Just to

5:55name a couple of choices.

5:56What about review and updates? When are we doing it? Quarterly, monthly, every

6:01time the wheels come off the bus? I have no idea, but you should very clearly

6:05know that.

6:06Here's another one. Who can update it? Not everyone should be able to get into

6:10your information and make changes because that's how you lose control.

6:15Other tools and references. What tools and templates are we using? If I have a

6:21configuration heavy plan, this is very important. What systems like IT systems

6:27are we using?

6:28We may have multiple testing platforms and by running the exact same kinds of

6:34tests, 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

6:45documents? Well, I gave you a reference document for this training. The PIMBOC

6:50version 6. And what about the revision history log? When did we change it and

6:55why did we change it?

6:56And who changed it? I don't know, but I bet we can figure it out. As long as we

7:01have a log. And last but not least, there's some optional stuff. You need

7:06definitions and acronyms. You don't have any acronyms there are in the federal

7:11space. All of them. And there's what I think an acronym means and there's what

7:16someone else thinks it means.

7:18Acronyms and jargon kill projects slowly. You need a glossary of terms. What do

7:24they mean? Particularly if they're public facing and cross functional.

7:30Engineers can put out all kinds of words and I heard some great ones last week

7:33from someone who was teaching me autonomous neural networks. I never heard Sigm

7:37oid. I never heard Raylu. And I never heard Pi Hat.

7:41Pi Hat was not what I thought it was. In fact, it's not a hat at all. It's

7:46Python coding language. But now I know. And there was a glossary involved to

7:50spell some of that out for me. For lay people like myself who are outside the

7:56loop 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

8:07words. Make it shiny, make it pretty, and they will come.

8:10They will pay attention. They will use it. And last but certainly not least,

8:14why are we going to do this in the first place? Why are we going to put forth

8:18the energy? Because you need structure.

8:20Every team needs a team identity. It's very important. There needs to be very

8:25clear boundaries. You're in, you're out because you can have multiple teams

8:28doing multiple things.

8:30You need traceability, accountability to go with that other word that sounds

8:35like and rhymes with and is responsibility. And last but certainly not the

8:40leastest, you need a professional looking and polished plan. Why? Because if

8:46you look shiny and you look like you know what you're doing, you probably do

8:51know what you're doing.

8:52Or at least that's what your senior stakeholders are going to think. So those

8:55are some of the common items we're going to talk about or we have talked about

8:58rather.

8:59When we come back, excuse me, I'm all excited because when we come back, we're

9:04going 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

0:06or as one former

0:08president likes to say, "strategic replants." I think you can probably figure

0:13out which one it is.

0:14So let's see what we're going to do. We've got the performance and measurement

0:17baseline,

0:17that one's cool. Change plan, your development approach, configuration plans,

0:23management reviews,

0:24and your lifecycle descriptions. These are not check the box items, these are

0:30very important.

0:31Now, do I think you need every one of them? No, probably not, but as your

0:35project gets bigger,

0:37as the money gets larger, as the timeline expands, as the team grows, as the

0:43visibility increases,

0:45you need more plans. More plans equals more control, and trust me, you'll know

0:51when you lose control,

0:52and you can probably trace it back all the way back to some issue at planning.

0:58So let's clear

0:58the screen and let's go forward. Let's talk about the performance and

1:02measurement baseline.

1:04What is it? Well, it's a combo of your triple constraint baselines. Excuse me.

1:11So that's your scope,

1:12your schedule, and your cost baselines. And in case you forgot, you got your

1:18scope,

1:19you got your schedule, you got your cost, your classic triple constraints. You

1:23can't change

1:24one without affecting at least one other. And most of the time, you can't

1:29change one without

1:30affecting both of them. So why look at it? It's your target. It's what you're

1:34aiming at. Imagine

1:36you have an actual bullseye. That's terrible, but you got your little bow over

1:41here and your

1:42guy shooting arrows at it. Let's put some Fletches on there. He's shooting at

1:46it. The better,

1:47not want to say it that way, the more detailed your target is, the better your

1:52aiming point

1:53is going to be. If you're aiming at the side of a barn with a bow and arrow,

1:58okay, it's this huge

1:59target. Hopefully you can hit it, but you're just going to keep hitting this

2:03massive target.

2:04As you have smaller and smaller aiming points, your aim, your skill, will get

2:11better. And that's

2:12exactly what we're talking about here with your performance and measurement

2:15baseline. You have a

2:17target. It's where you're trying to go. And the more detailed it is, the more

2:21troll you're,

2:22the more troll. I feel like I'm trolling myself. The more detailed it is, the

2:27more control you are

2:28likely to exercise in trying to hit it. That's why you have a cost or

2:34correction. That's why you

2:35have a performance measurement baseline. So what's the pro tip? Outline your

2:40approach

2:41and get stakeholder buy in. What do I mean? Well, don't show up at your first

2:46management review and say, "Hey, here's the performance and measurement

2:50baseline, and this is how we did."

2:52Because if you didn't have a previous expectation set with them, they may not

2:55have any idea what

2:56you're talking about. In fact, they may look at your data and go, "I didn't ask

3:00for this. I didn't

3:01want this." If you'd previously set a clear expectation on what you were going

3:05to do and how you were

3:06going to do it, it's much better received. That's why you let them know what

3:10the target is, how you're

3:11aiming at it, and what metrics you're going to use. So let's clear the screen.

3:16Let's drive on.

3:17As soon as I figure out where my pointer is, here it is. The change plan. What

3:23is it? It's how we

3:24change. How we change stuff. Why? Why look at it? Set a proper expectation. And

3:33roles. Who's going

3:34to do what? But everyone should know. Your change plan can be as simple as I'm

3:40sitting in a room

3:41drinking a cold frosty root beer, looking at these change requests is and I'm

3:46making changes.

3:47Another one might be we have a formal change control board with all the senior

3:51leadership

3:52once or twice a month and we review each of these change requests and decide if

3:56we're going to

3:57approve or reject them. Then we're going to have to figure out how much money,

4:01how much time, and

4:02how many resources we're going to actually apply to each one of these changes.

4:05Now that's very formal.

4:06And the bigger your project is, the more control you're trying to exercise, the

4:11more formal your

4:12train change, excuse me, request should be. If it talks so fast that sometimes

4:17your words just get

4:19ahead of your lips, well sometimes it happens to me, particularly when I'm

4:22excited about something.

4:24And I'm always excited about change because it is the only constant on a

4:29project. What's the pro

4:31tip? Map the procedure. Let's call it the process. Map it out. Make sure

4:37everyone understands it.

4:39And make sure you have change under normal circumstances and change under

4:44emergency circumstances.

4:46Most of the time most of your project changes are going to be super simple and

4:50run of the norm

4:51stuff. But you may have emergency changes where we can't wait until next month

4:55when we have a formal

4:56change board. How do we change things when that happens? That'll become very

4:59important and I promise

5:01you as soon as you don't have an emergency change process, you're going to need

5:06one. Your development

5:08approach. Hmm, I wonder what this sounds like. I don't know Bob, tell us. Well

5:13your development

5:14approach is justification for project methodology. You know what I mean. So why

5:21look at it so we

5:22can decide which is best. So what are we talking about? Well there are a couple

5:27of different kinds

5:27of methodology you can use for your development approach. If you're doing

5:31software development,

5:32it's going to be some form of agile, probably scrum. But if you go all in on

5:36scrum, you're all

5:38in. You're not halfway in or you're not doing scrum. But if you have an

5:41infrastructure type project,

5:43you may be using predictive or waterfall and you probably should. But what

5:47about a hybrid approach?

5:49A combination of predictive and agile. You have to justify to your stakeholders

5:55why you're going

5:56to use whatever methodology you're going to use and get them to sign off on it

6:00because they're

6:00responsible for it. If this project fails and many of them do, someone above

6:05them is going to say,

6:07hey, how did you come to this conclusion and who signed off on it? Because now

6:11we're playing

6:12pain the finger. We're playing the finger pointing game and you don't want to

6:17be on the receiving end

6:18of that finger. You need to explain why you're doing whatever you're doing. So

6:22pro tip here is

6:24get buy in. Get them to sign off on it because if they don't, eventually

6:30someone's going to say,

6:31why did you do this? Who said you could do it and it's time to update your

6:36resume? I say that a lot,

6:38but it happens a lot more often than it should. Your configuration plan is all

6:42about version control.

6:44Why look at it? Accountability. Accountability. Trackability. I may have just

6:50made that word up,

6:51but I don't care. Trackability. Imagine a project, an infrastructure project

6:56that lasts two years.

6:57Project managers and team members come and go. There's a leadership change. Two

7:02years down the

7:02road, they open up this wonderful building and about two months later it

7:06collapses. What do you

7:08think is going to happen? Well, it's called an investigation and it rhymes with

7:12someone's in

7:13serious trouble. A forensic accountant somewhere is going to come back and

7:17start pulling these

7:18project files and they're going to say, all right, version one was this.

7:22Version 100 is this and

7:24they're going to start filling in those blanks and they're going to start

7:27figuring out who did what

7:29and when and based on what date. They will narrow it down to what happened to

7:34potentially cause this

7:35collapse. And again, I hope this never happens, but if you just look at the

7:39news, you can look at

7:40crane collapses, you can look at bridge collapses or bridge failures or dam

7:44failures and stuff like

7:45that. And the NTSB, the National Transportation Safety Board and the Occup

7:50ational Safety and

7:51Health Administration, all kinds of federal agencies get involved and they

7:55investigate these.

7:56They want to know what happened and version control matters. So here's a pro

8:01tip. Keep a running

8:03sheet version one, two, three, four, all that stuff and every time you change

8:08versions,

8:09get a signature, get a date. That way you can keep up with it. That way there's

8:14no need to go

8:15tracking stuff down in boxes and hidden warehouses someplace. You got it on a

8:20single hard copy and

8:22digital sheet in case you need it, you've got it. So let's take a break right

8:27there to contemplate

8:29and 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

0:04dig into them. Management reviews.

0:07What are they? That's where we compare the plan against the actual. Let's just

0:12call it versus the actual.

0:14Well, what are we talking about, Bob? We're talking about did we do what we

0:18said we were going to do when we done did said we would do it?

0:21And hopefully the answer is yes. There's a little formula I like to use. It is

0:26this. Plan. The plan.

0:28Minus the actual equals the variance. The variance is not your friend unless

0:35the 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.

0:44The actual spend was $600.

0:48Some quick math. $500 minus $600 gives you a negative cost variance of $100.

0:56That's issue number one. Issue number two is why did it happen? You have to

1:01figure that out. You're going to keep doing it.

1:03Once you figure that out, you move on to solution number one. What are we going

1:07to do about it? You have to explain this to leadership.

1:10That's why we have what was it? The performance and measurement baseline

1:15earlier. We have to tell them, well, this is what we said we've been doing.

1:19And this is what we actually did. Well, now we know. So why look at it? To see

1:24progress. And, whoops, make decisions.

1:28Your project timeline is like this. You got B, you got A. You're starting right

1:34here. And as you do this, going down the road, you're going to need course

1:38corrections.

1:39And you're going to try and stay as close to the line that you said you were

1:43going to do. Now things happen.

1:45But if you start doing this right here, that's going to alarm people. You're

1:49going to need a course correction to get you back on track.

1:52Or you're going to have to figure out what you need to change. So what's the

1:55pro tip here? Tailor to your audience.

1:59And here's what I mean. Let me get rid of some of this here. Tailor to your

2:02audience. Senior leaders get summary data.

2:06Your boss gets detailed info. Senior leaders do not have enough time to listen

2:10to everything you have to say about your project.

2:14They want the high level stuff and it usually comes down to three colors. Green

2:17, 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

2:24you can't answer those questions, you're going to be in that review a lot

2:27longer than you want to.

2:28And I have an easy gauge of project progress. The longer I stay in a management

2:33review, the worse my project health is.

2:36I should be in and out because if that happens, my project is fantastic. But if

2:41I'm stuck in there getting grilled like some kind of an investigation, there's

2:46a problem.

2:47And you need to fix that. So make sure you're tailoring your information to the

2:50appropriate 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

3:02want to see coming into this management review.

3:05Previously, you went to them and said, "Hey, I've already got a format that I

3:08've used before and everyone agrees with it. Is this acceptable for you?"

3:12If you give them something that's already done and all they have to do is go, "

3:15Yep, I like that. That's perfect."

3:18You're good to go. You lead their thinking. This is project management.

3:23But if you go to 10 of them and say, "How about if you tell me what you want to

3:26see?"

3:27You're going to get 10 different points of view, 10 different ideas, 10

3:31different formats, and now you're on the hook to deliver it. So don't do that.

3:35So let's clear this one and let's move on to one more. We are cooking with

3:40Greece, folks, as I like to say.

3:42Last one. What is our lifecycle description? What are our phases? What are

3:50phases or roadmap?

3:53Why 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.

4:04It's bonkers and it happens.

4:05Some really big projects take a long time. Do you want to wait three or four

4:08years to look at the final deliverable before you can decide what you want to

4:11see?

4:11Well, I'm not sure if you're on the right path. If you did the right thing.

4:15Because the answer is no.

4:16Here's an easy predictive outline. Let's say we have concept, design, build,

4:21implementation, close out. That's an easy one.

4:25You need to, number one, understand what your phases are and all of your

4:28stakeholders do too.

4:30And number two, and most importantly, you need to know exactly what your phase

4:34deliverables are because that's your point to course correct this project.

4:39If you're staying on path and delivering exactly what you said you were going

4:43to deliver, you're a rock star.

4:45But if you get to that point, they're like, you know what? That is not what we

4:48wanted at all.

4:49Or this has changed and now we need to redirect. You have an opportunity to do

4:53that at the end of every phase.

4:56Or actually at any time on the project, if it's really severe. In the world of

5:00agile, 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

5:08increment, meaning they have some kind of small deliverable, called an

5:13increment, at the end of that phase.

5:16If they don't like it, or if it's not quite right, they immediately launch into

5:20the next sprint where they can adjust it, fix it, do something different, it

5:23doesn't matter.

5:25But stop and think about how cool that is. They deliver something every single

5:30month or multiple something's.

5:32And a sprint may only be a couple of weeks. Let's see. Deliver something every

5:37couple of weeks. Ever? Every couple of weeks to see if it's the direction I

5:42want to go in or wait a couple of years.

5:44One of them sounds a lot better to me. However, with that caveat,

5:48infrastructure projects that are heavy in documentation, heavy in oversight,

5:54infrastructure projects that last a long time are heavy in documentation and

5:59decision making.

6:00That's not how scrum works for software. So, figure out which one works best

6:05for you and have very clear deliverables at the end of each phase.

6:09Whoo! Alright, so what's my pro tip? Let's see. Have exit criteria and spell it

6:15out. That way everyone knows exactly what you're doing.

6:20Alright, my brain feels a little fried. Yours probably does too. Trying a new

6:24camera. I've had a lot of coffee and some really buzzing right now. You ever

6:29feel like you can feel the earth turn because I feel that right now?

6:32I say we go with what this guy's saying and we make me stop right now. When we

6:36come 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.

0:04So let's check them out.

0:06You have the scope plan and you had the requirements plan.

0:09Now notice they are tied together because the requirements

0:13plan and the scope plan are tied to the scope baseline.

0:19So we're going to have to talk about that.

0:21Then you have the cost plan and the procurement plan

0:24tied together, tied to-- excuse me--

0:27the cost baseline.

0:29Why does it matter?

0:30Because if you get one of these plans wrong,

0:32it's going to have a cascade effect up and down

0:35through your project documentation.

0:37Well, the same thing happens with the quality plan

0:40and the process improvement plan.

0:42The same thing happens with your resources and your team plan.

0:47Now this one is a freebie.

0:49It may or may not exist in your world,

0:51but it is still relevant.

0:53And here's an easy way to change it.

0:55What if you call this the HR resource plan, your peoples?

1:00OK, Bob's on to something.

1:02Remember, this is the practical PIMBOC series.

1:04We ain't studying for the PMP no more.

1:07Well, then you have the knowledge plan

1:09tied to the data management plan because both of these

1:13are tied to info, information.

1:17Obviously, there's a schedule plan tied to the schedule

1:21baseline, then you have a risk plan tied to everything.

1:25These two should be tied together

1:27because when we went from PIMBOC 5 to PIMBOC 6,

1:31PMI took about half of communications

1:33and made stakeholder engagement.

1:35So they're tied together too.

1:38So there's a lot going on.

1:39Here we go.

0:00Are you having fun yet? I told you these would be great.

0:03I love the tactical plans because you can really get into the weeds on them.

0:07The high level strategic plans, boring, the tactical plans, that's where you

0:13make your money.

0:13So let's do this. So the scope plan, what is it? How we manage the scope?

0:19And let's go one step further, the scope baseline. Think, well the requirements

0:24plan is tied to it.

0:26Why? Because this is how we collect the needs, demands, the wants that turn

0:33into the scope baseline.

0:36These are ridiculously important. And remember, the scope baseline is three

0:41pieces.

0:42We haven't even talked about that yet. The scope statement, the WBS, and the W

0:48ubus dictionary.

0:50There's a lot going on here. What is the pro tip? Well, for starters, you need

0:56a requirements

0:58traceability matrix. This is a project document tied to the requirements plan.

1:05Basically it means

1:06if it's not in the requirements traceability matrix tied to a project objective

1:13, it should not make

1:14its way into the scope plan. Either it's rolls up into something or it rolls

1:21out. It simply does not

1:23belong. The cost plan is all about managing the cost baseline. Well, why is it

1:28tied to the procurement

1:29plan? Because procurements is all about purchasing. How we're going to do it,

1:35when we're going to do

1:37it, what currency we're going to use, who can do it, is a very important one.

1:41And when ties both

1:43of them to the schedule. Now let me give you a pro tip here. Let me go ahead

1:49and put pro tip over

1:50there. Pro tip. Let me give you another pro tip since we're talking about the

1:54requirements traceability

1:56matrix. During your project, as you deliver stuff, small deliverables, sub

2:01deliverables,

2:02work packages, if they're in the requirements traceability matrix, check them

2:06off, get them signed off

2:08on right then. Do not wait until the end of the project to get 100 things

2:13signed off on and verified

2:14that they're done. If you can do 567 here and there at the end of each phase or

2:18whenever they're

2:19delivered, do it then. That way when you get to the end, you of course correct

2:23it along the way

2:25and closure should be very easy. Ah, where was I? Oh, cost plan pro tip.

2:31Actually, this works on both.

2:34Limit the number of buyers. The more people who can purchase things, the more

2:39likely you're going

2:40to have cost overruns. Don't do that. And have limits. Limiting who can

2:46purchase and how much they

2:48can purchase is all about control. Smaller variances mean smaller corrections.

2:54Think about this for

2:55just a minute. Would you want to find out from your bank if you were say $50

3:00overdrawn versus $500

3:03overdrawn? Now that can happen for a number of reasons, but it happens on

3:07projects too all the

3:08time. So limit who's doing it, limit how much they can do. There should be an

3:13authority level

3:14for each one of these. So let's clear the screen and keep on going. Let's talk

3:19about the quality

3:20plan. The quality plan is all about, well, let me get the right, um, writer

3:25here is all about achieving

3:28quality. Quality is not an accident. You either aim at it and you hit it or you

3:33don't. You do not

3:35stumble your way to better quality does not happen. And the process improvement

3:40plan is tied to that

3:41because if you aren't achieving quality, it only happens for a couple of

3:45reasons. One is your,

3:49let me rephrase that. One is you missed it. Two is the process stinks. And if

3:56the process stinks,

3:57that's where the process improvement plan comes from. Now here's the pro tip

4:01for quality. Have

4:02metrics, make sure it is well defined. And I'll tell you why. I once had a

4:07customer ask me,

4:09how do you know if you've achieved quality? This is a true story. And I said,

4:13well,

4:13they're quality metrics. I need to know what those quality targets are. And

4:16they need to be

4:17measurable. I need to make sure I can measure them so I can show I achieved

4:21them. For example,

4:22if the quality metric is 100 rubber balls in a cardboard box, I can count the

4:26rubber balls. I

4:27can count the box. It's very simple. And then the customer said, well, what if

4:31we can't define

4:32what quality is? And without missing a beat, my response is and will always be

4:37if you cannot

4:38define what quality is, then I will always achieve it. And the underlying

4:43message there is simple.

4:45All I have to do is convince you that I've achieved quality, which is why well

4:50defined metrics are

4:52so important. Your process improvement plan tip, map your processes. Why?

4:58Because of the kinds of

5:00waste. Now in a whole other section of training, we're going to talk about the

5:03kinds of waste,

5:04the waste of waiting for signatures. How long have you ever waited for someone

5:09to get back to you

5:10with something signed that probably could have taken them five minutes? That

5:13impacts your schedule,

5:15that impacts your budget. What about the waste of rework? What about the waste

5:19of defects? What

5:20about the waste of movement? What about the waste of transportation? That's why

5:25your process is

5:26being mapped out or so important. Because if you have an element in your

5:30process that's not delivering

5:32value, air quotes, there's likely a kind of waste there that you can fix. We'll

5:38talk more about that

5:39in another skill. The resource plan. This is all about stuff. And your team

5:45management plan is all

5:47about people. Stuff is simple. When and what? Here's a pro tip. Use just in

5:55time. Order it only

5:57when you need it. That way you don't have to deal with storage. I misspelled

6:01people in the

6:02diva catch up. So back to just in time. Order it only when you need it. That

6:07way you're not worrying

6:08about the storage and the additional cost. Plus there's an additional cost of

6:12security as well.

6:13Now people, how we onboard them. Bring them on to the project. How we let them

6:19go. I call that

6:20off boarding pro tip. Invest in team building. The best teams that work

6:25together or should I say

6:27the teams that work best together are those teams that have rapport and

6:31especially harmonious

6:32connection with one another. They do things for one another because they want

6:36to. Not because they

6:37have to. And the way to make that happen is team building. Even if it's

6:40something simple.

6:41Go to lunches together. Why am I telling you this? Because in many companies

6:46and on many projects,

6:47this is a cost. You can, this is a cost. Excuse me. You can expense directly to

6:54and against the

6:56project. So have a plan for that. This is super important if you have brand new

7:01teams, international

7:02teams, cross functional teams. So let's stop right there. When we come back, we

7:06're going to wrap it up.

0:00Alright, it's time to put these tactical plans to bed and turn out the lights,

0:04so let's do it.

0:06Now these two will probably surprise you a little bit, so let's start with this

0:11one.

0:11Data management is all about info, storage, what are we doing with it, and

0:18where are we doing it

0:19with it, what we're doing to it. You know what I mean, why does it matter?

0:23Because when you start

0:24storing project information, you can actually capture personal information of

0:28your employees.

0:30There may be socials, full names, birthdays, phone numbers, addresses, and

0:34stuff like that.

0:35You need to figure out what you're doing with that. So the tip here is tightly

0:41control the access,

0:43and when not needed, here's another tip. When it's not needed, destroy it.

0:48People come and go on

0:49your project and in your company all the time. Do not hold on to that

0:53information. I've seen this

0:55turn into lawsuits later on for data breaches. Don't do that. So here we're

1:00talking about info.

1:02Well, it's a kind of knowledge, but that's not the knowledge we're talking

1:06about here. We're talking

1:07about knowledge transfer. I think it's implicit or tacit knowledge. The word

1:13escapes me at the moment.

1:15Think of it this way. Let's say you have a senior engineer and a junior

1:21engineer, and this guy,

1:23this person is going to retire in a year. Well, how do you get what he knows

1:29into that person

1:30right there? That's knowledge transfer. You do not want your smartest,

1:35brightest, bestest people

1:36taking all the tips and tricks that they've learned out the door with them when

1:41they retire.

1:41So the tip here is have mentoring. A lot of companies talking about it, but

1:48they don't do it.

1:49Mentoring. Make sure you are squeezing that grape for all of the juice you can

1:55get and pouring it

1:56into that junior person because number one, you don't want that information

2:00walking out the door.

2:01And number two, you want that person who's going to stay to gather as much

2:05information as possible

2:07and build their career right there. There are a lot of things going on here,

2:12but how many times

2:13have we seen someone with 30 plus years in a company just up and say, "You know

2:16what? I'm out

2:17of here." And they give two weeks notice and there is no knowledge transfer.

2:22That's a huge problem

2:23and that's a monstrous miss. Don't do that. The schedule plan is all about, who

2:28ops, all about

2:30with only two L's, all about schedule management. It's all about managing the

2:36schedule baseline.

2:37Now here's the pro tip here for the schedule plan. Have a clear modeling

2:42techniques. Have clear

2:44model. Let me re- spell that. Have clear modeling techniques. This will help

2:50people understand how

2:51you drew the conclusions you drew on the schedule. Did you do automatic

2:55scheduling? Did you do manual

2:58scheduling? Did you use any early start and finish, late start and finish? How

3:03did you do that

3:04exactly? 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

3:16utes in your 20s,

3:16folks, because sometimes you forget things. Oh, buffers. How did you come up

3:21with these buffers?

3:22Because those buffers aren't tied to risk. If you can't explain what you're

3:26going to do,

3:27what your methodology is in the schedule plan, you're going to have problems

3:31explaining your

3:32schedule baseline later on. I promise it. So the risk plan is your risk

3:37methodology. The tips here,

3:39whoo. There are some serious documents here. You need a probability and impact

3:45matrix. You need

3:47impact definitions. You need probability definitions and you need risk

3:53statements. Risk is one of

3:55those areas where project managers just hope and pray. And I hate to say it.

3:59Prayer is not a

4:01not a risk strategy. You have mitigated void transfer, share enhanced exploit

4:07and acceptance

4:07in nowhere. Did you hear me say prayer? Now I'm down with a good prayer. It's

4:13not a strategy.

4:14And because it's not a strategy, you need very clear risk statements. And here

4:17's two good examples.

4:19You've probably heard if this happens, then that occurs, which doesn't tell me

4:24anything. But what

4:24you probably haven't heard is something called risk meta-language. If this

4:29occurs, then that happens,

4:31resulting in this cause, risk and effect. That's called meta-language. It's a

4:39far better technique

4:41for risk. And we're going to talk more about this later on in this skill series

4:44. So let's get this

4:46done and wrap it up. Your comms plan and your stakeholder plan. This is, oh,

4:52this is our strategy

4:55for keeping stakeholders engaged. And by engaged, I mean on our side. And by on

5:02our side, I mean

5:04supportive. They are supporting our project. How do we do that? Well, one of

5:09the ways we do that

5:10is with the strategy of communications. This is the execution of info

5:16distribution. These are

5:19tied together because again, back in PIMBOC 5, PMI, Tor, Communications

5:24Management and Half,

5:25and gave half of it to stakeholder engagement. So the pro tip here is easy. Not

5:30the po tip.

5:31The pro tip is simple. Do these together because they are tied together. You

5:39cannot do one without

5:40the other because I promise you, if your stakeholders become detached from your

5:45project,

5:46there's either something political going on at their level or your project just

5:50isn't that

5:50interesting or your project just flat stinks and you're causing them nothing

5:53but headaches.

5:54The way to stay ahead of that is with the solid communications plan. Commun

5:58icate with them the way

5:59you said you would, when you said you would, and very often. There's a sweet

6:04spot between not enough

6:05and too much. You need to find it. And if you do that, you will keep your

6:10stakeholders engaged.

6:12You want supportive stakeholders, leading stakeholders, coaching stakeholders

6:17who are behind you 100%.

6:19What you don't want are negative stakeholders. People working against you and

6:23there are plenty

6:24of them. There are plenty of reasons out there for people to view your project

6:30failure as a win

6:30for them. So these two are tied together and treated that way. I think that's

6:34enough for now

6:35for this set. Let's wrap this up and see what we can do in the test your

6:40knowledge because it's

6:41It's coming real fast.