The People, Process, & Progress Podcast - Listen to Learn the Foundations of Waterfall Project Management | PPP #106

Episode Date: March 14, 2022

We go chasing waterfalls in this one…Project Management Waterfall, that is! Join me on this audio tour of Waterfall Project Management.Key Focus Areas:Project IntakeProject PhasesInitiationPlanningExecutionMonitoringClosing

Hey everybody, Kevin Pinnell, host of the People Process Progress Podcast. Thanks so much for coming back to this episode 106, Project Management Principles and Practical Application. This is actually audio from a slide presentation slash video, I guess, that I'm putting up on YouTube. So there's some references to what we see on screen, but not a lot. But head on over to the People Process Progress Podcast YouTube channel, if you will, subscribe so you can get the latest in videos that I'll be putting up there and see the visuals that go along

with this episode. Thanks so much for also subscribing, sharing, leaving a review on the People Process Progress Podcast on whatever platform you're on. Particularly Apple Podcasts helps get this seen a little bit more, get the message about program project management, some all-hazard incident management out there. Thanks so much for your time.

Here we go. It's time to lace up, chalk up, get logged in, and get locked on as we put people first, share our processes, and help each other make progress on the People, Process, Progress podcast with Kevin Pinnell. To project management principles and practical application, I am your host for this show, Kevin Pinnell. I'm the creator and host of the People Process Progress podcast, also available wherever podcasts are played. I'm a senior project manager in the healthcare space with a background in the US military, the Navy in particular, public safety and incident management.

But today we're going to talk about what I've shared a few times on Reddit and LinkedIn and just in conversations with folks that are new getting into project management or discussions on how we can all make project management better and just go through some of the concepts using the waterfall methodology from the project management body of knowledge. And so let's get into this. So starting off, what is a project? How do you define a project? How does your organization define a project, right?

And these are important questions to ask if you're the, let's say, director of a project management office or trying to get into project management, because it's probably a question maybe on an interview you might get. If you're that PMO director or someone else standing up more project management or refining it or updating those processes, you need to think about how does your organization define a project? Is it hours? Is it costs? Is it a combination of those, which usually it is? And that varies, right? So my organization has certain standards that make things a project and others don't. But let's go with kind of an industry worldwide standard. And that's, as I mentioned, the Project Management Institute, which is the body that those of us

that have that project management professional or PMP credential are governed by, so to speak, or they set the standard. And so for that definition, it's a temporary endeavor undertaken to create a unique product, service, or result. So the keys there are those bold areas, right? It's temporary and it's unique. And so projects shouldn't last forever. It should be to, like it says there, a unique need. And it says, again, product, service, or results. So it can be a thing we're putting out there, it can be services we provide, or that we want to improve our process or something like that. And we'll get more examples of this as we go on to the next thing.

The other thing we can talk about is on episode 54, I just talked about what makes a project a project, do we need to sometimes stretch that out or cut it off. And so check out Foundations Friday, episode 54, wherever podcasts are sold or go to peopleprocessprogress.com. And all the episodes typically are posted there as a blog post. So let's get into the first phase. It all starts with intake, right? So not a project phase, but first we have to have an intake process, or we should. We should be filtering all the requests, all the wants and the needs, all the whatever you want to call it, that folks in our organizations have maybe even folks outside and our organizations

are trying to sell us. And it starts with defining that need, right? Why do we need to have a project? Is it a new something? Is it improving the process of something? Is it replacing an existing something? Or did we discover a need for this based on maybe increased trouble tickets, or somebody happened to look, you know, and see this old piece of equipment that we forgot about? And that happens in the world and we just discovered it. Or we found an inefficiency in a process or something like that. The next what we need to do is get a request in there. And we need to have someone that owns that request.

We need to have what is needed on that request. And these could be how you build out your request form. It could be pretty simple. There's so many great tools to do online forms, but someone needs to own it, right? Typically a high-level person, a sponsor, like we'll talk about, or I've talked about in other episodes of the People Process Progress podcast, or if you're a project manager, you're familiar with that. And then again, what is needed, right?

Brief, it doesn't have to be super long because we're going to include other information like this estimated cost, right? We have done some research, hopefully, if we're going to ask for a project, we've said, you know what, the vendor says this, and then we think there'll be maintenance for that. And there's a lot of other stuff in there. But it's good to at least know it'll be about this much. Who is paying? So where's where's the the line of the cost code or whose business is going to pay for this? What line of business is going to pay for that? Basically, where's the money coming from? Like it says, what's the outcome we want to achieve?

So when we look at those needs we defined, is it that we have put a new something in place that is going to cost less maintenance down the road, that we improve the process, that's going to increase efficiencies? Do we replace an existing thing, which again is going to be less costly because we don't have to fix it as much? Do we discover a need? And so now we're going to fill the gap that exists by not having whatever it is there. What is the priority? How often or how soon do we need this? Is it a safety thing? Is it a regulatory thing? Is it a we can't keep doing business until we fix this one thing? Or is it a nice to have? And there's stuff that ranges in between there, but that's something we need to think about,

particularly if you're in charge of a process, an intake process like this. And what's the level of effort? It's good to have an estimate on, it's going to take this many hours for, you know, this many people and roughly this long to take it, you know, to complete this project, this temporary unique endeavor. How are we going to improve it, you know, to complete this project, this temporary unique endeavor. How are we going to improve it, right? This should be a group of folks multidisciplinary, I think that should help improve this. Is the request complete? I think this is critical. If you get incomplete requests, and you're part of the group that's in charge of, you know,

reviewing project requests, and then putting them out there, then, you know, send it back to the person nicely, hey, we noticed these areas, can you please fill these these, you know, the rest of this information out helps us make a better educated guess, it'll help us staff and resource and, you know, complete this project better once we get going. But we got to have as much information as we can up front, just even out of the gate to even approve it. Who can approve it. So we know we have an owner of the request just to even get a project. But who can approve this, who is on the board and the group, the committee, the council, whatever, you know, verbiage you want to use for that group of people, but who you've got to define that. And you've got to decide, um, you know, is there also, you know, kind of an ultimate vote,

so to speak a tiebreaker and how you work with that kind of stuff. Um, or do you have an objective scoring system? And so, you know, that group that's going to approve these, the intake group or whatever you want to call it, can also look at scores, you know, number affected, safety risk, those kinds of things. How often is it reviewed? Do you review new projects weekly, monthly, quarterly? You know, by the time you review things,

you're probably already working on a bunch of other things. So that's probably a tough kind of balance to think about is how often you review them, but but good to consider. How are your project managers assigned? So are they early in the initiation or you know, with the requests? Or do we say, okay, these are the approved projects. And these are the folks that we're going to assign to them based on their experience, or, you know, it's an opportunity, maybe for someone less experienced, or it's a project where we need someone with more experience to get in there and get a handle on on, you know, a really big project that's almost a program itself. Want to hear more about the intake process like that snazzy animation there.

So I talked about intake in particular, and how important it is in episode 93 of the people process progress podcast. So I'll dive deeper into what I just touched on on the slide in there. Navigating the waterfall. So I mentioned waterfall, which is, you know, the traditional method methodology that talks about initiating planning, executing monitoring, controlling closing projects. So I'm going to touch on each of those. Again, this is a primer. If you are an experienced project manager, I'd love to hear your feedback. Hit me up at people process progress at gmail.com or stop by the people process progress.com website and contact me there. But I'm just

going to touch on these to give folks an idea of how you could set up your own program, you know, your own project management office and just really get into this. So let's let's get into this waterfall. Getting started, right, let's charter this thing. Charters are very important. It's a very quick summary. We'll talk about what we think we're going to do because this is early, right? We're initiating. We think this is what we're going to need. We're pretty sure it's going to do this and we're going to do that, right? What's the business need? We should know that from our good intake process. What resources do we think we know where we need? We should have an idea based on the problem we're solving or the unique product we're providing, or, you know, process we're improving, whatever it is,

we can think, hmm, who in my organization from what teams, what groups, how can we put them together, just to even have an early idea? What organization do we think will work best? Meaning, the organizational structure, right? The boxes and lines that will draw an org chart, is it going to be a functional one based on like a technology group and a legal group and, you know, other things with the sponsor and the business owners and the PM, you know, coordinating all those folks? Is it a geographical kind of thing? If you're a global company, right? Is it going to be the North American group, the European group, the Asian group, it's so many different ways to chalk that up. And then within those, you could have functional things. So just like the incident command system that I came from

project management, you can set up an org chart to work. And that's the key is to set the org chart up to however it works for your organization. And for this project, in particular, how long will it take, right on the charter, we can guesstimate and I'm going to show you an example here in a second, roughly how long we'll get into the specific tasks and days and all those things in the next phase. But now we just want to have an idea so we can tell the resource managers how long we would like their folks to work with us on this project. How much money were we approved and our intake? We should know that by the time it's approved. We should know, okay, here's your total budget, and we'll touch on a super basic kind of breakdown of budget here

in a little bit. What's in scope, what's out. So what should we focus our time and energy on? What shouldn't we focus our time and energy and money on right out of scope, whether it's physical locations, or, you know, sometimes we get going on a project and a new functionality pops up, let's say with software, and there's opportunity to add that. Well, that adds more work. And again, we need to define maybe current software or this version is in scope, this stuff is not in scope, because we don't need all these new functions. And there's a lot of details in there you can work out in your organization. But basically, folks need to know what should I work on and what shouldn't I work

on? What are your key performance indicators? So those KPIs, how are we going to measure this? So how are we going to measure that efficiency, that process we're trying to improve? Are we going to reduce sick time because we have better shifts that help people not get burnt out so much? Are we going to spend less because of this new product we put out there that doesn't break as much. So think about numbers, tangible numbers, and how often you're going to measure those. And we can capture those pretty well up front. And we'll talk about that here in a second. Set the operational meeting tempo.

I like to do this really early. So how often are we going to have full team meetings? Are you going to meet with your counterpart if you have another project manager that you work with from a vendor or somewhere else? And just up front let folks know, hey, we're going to meet weekly, right? Whatever day of the week works the best for the majority of people. Because as we know, you can't, you know, this day and age with all these web meetings, super hard to coordinate everybody, you know, 100% of the time all the time. So go with 8020 if you can get 80% of the folks to meet, and then catch up with other folks offline. Because again, your regular weekly meetings, there should be work in between those meetings. And you can have some kind of offshoots

or use those as work sessions. But that's not really time for folks to, you know, once a week, catch up with each other and talk about the work they need to do. So super basic sample charter element here. It's an extension ladder, I had to talk with the fire department about some project management stuff. And this isn't specific things, Smith is a pretty generic name. So Chief Smith is our sponsor, right? He's an executive level person. So they can sign off, escalate, tell us yes or no. Business cases, we need to replace some ladders, right? They require replacement, they're breaking down their end of life. We need resources from finance, logistics and operations. So we need money, we need stuff from logistics, right? And we need operations

folks as boots on the ground. We need a high level schedule. So like I mentioned, at this point, it's super early, we're just saying, man, the next, you know, January and February, we're going to be starting this thing between March and May, we'll get into the really deep planning, we'll do the work between May and July. And then we'll try and close it out after we've gone live and the new ladders are out July to August. And you'll notice monitoring, controlling, really, is it on there as its own phase? It kind of happens throughout a lot of planning and executing, especially when you start looking at how is this kind of working and even into closing. So while, yes, it's built out as its own phase, it's hard to kind of plan for we're going to monitor and

control during this time because you're always really doing that. We have just a simple budget million bucks, what's in scope, these kind of ladders, what's out of scope, those kind of ladders that you see there on the screen. What are our KPIs, we're trying to reduce ladder failure, right? So maybe we've gotten some reports where ladders are breaking down folks are have gotten injured, because you know, ladder failure, and we don't want that to happen anyway. And we're going to decrease maintenance costs, because we keep having to fix these things because they're end of life and they're old. So that's a very basic but good way to start a charter. So everybody knows who is leading this if we have to escalate things. Why are we doing it?

What resources do we think we need? What's the rough timeline? How much money do we have? What are we focusing on? What are we not? And then how are we going to measure our success? More on initiating, episode 31. Check it out. Focus on the details. So this is where we get into the details of the stuff we just talked about in initiating. So now we are going to break down more. What's the common operating picture for all of us here?

What's the meeting tempo like we talked about? How many work sessions do we need to get some work done? Who's doing what specifically? So who's going to set up, let's use the ladders, I guess, who's going to set up the meetings with the vendors? Who's going to be a subject matter expert internally that can talk about ladders? Who's going to help go spec those out? How often do we want to do that? How many vendors do we want to meet with? And project managers will help coordinate that. Let's say we're doing software. Who is going to do the build and the test? And we're going to get into all those details, task by task, and really line out from that

first month we said we were going to start. And then weekly, however often, however many days it's going to take to do all those tasks and assign them to people that we've asked for from our resource managers. Status reporting. So we got a report, right? We've been given a million bucks. We need to tell the folks that approved the million bucks for us to use and spend how we're doing. Are we ahead? Are we behind? Do we meet with folks? Do we find what we need? Did we think, do we need their help? Because we're not getting responses, but in the, you know, the gist of it is how are we reporting on some of those things in the charter or our objectives that we're going to measure ourselves toward on? Are we going to do that weekly? So, Hey, we're going to send a weekly

status report. We're going to bring it up in the, in the weekly calls. And there's so many systems that we can use. You could kind of put an extra work and take, you know, use PowerPoint slides, which we're all a fan of. I mean, we're on one right now. Or you could use whatever project management system, whether it's an Excel spreadsheet, project online, Microsoft project, there's a there's a whole bunch of other really good project management tools that have reporting in them. And you could pull it up on the screen, talk through it, and then see where, you know, people need help. But visual, I really like so the Gantt chart, which we'll look at, which is the lines that kind of correlate with a schedule and show folks, here's where we are.

Here's, you know, are we on track? Is it, are we kind of in the red? Cause we're having a huge stoppage from supply, which we've all seen this year and late last year. But it's, it's at any rate, your organization probably has a standard. If you have an established project management office, if you don't, Google it, there's so many different project status reporting protocols out there or again, reach out to me go to people process progress.com. My contact stuff's there. Happy to share some ideas. Diving into the details, right? This is where

we're going to really get into it. What are the specific requirements to get the right ladders that we need for this replacement to build a specific software that's going to help us improve the process or make people safer? And I mean, with the vendor looking at schematics, like we really get into it here. What will you do? What won't you do that scope? So we'll really define a little bit more what's in scope, because maybe what we thought was out of scope, it should be in scope.

But it's, you know, something bundled within this other software we looked at. So again, we're just really getting in the nitty gritty of what we're going to ask our folks to and spend their time on, and then build out the team. So I'll go to that in a second. So we're going to build the org chart this time, not just with, we think we need people from these areas, but their names, what they're focused on, and, you know, what their skill set is a very, very simple way to do that. So very standard functional group, project organization. So a sponsor at the top there, that's an executive level person typically, or whomever, right doesn't always have to be, but it usually is. And so the sponsor's in charge of the whole project, right? The project manager is the one, you know, that's going to help keep them informed, not surprise them, get approvals

from them. Business owner is someone that partners with us as well, but is really close to the area that you're improving the process in or putting the product out or that it's coming from. That steering committee up there on the top right, you know, that's a group of other leadership folks or invested folks, they're going to help us make decisions. But let's talk about to the incident commander, that equivalent of the incident command system, if you're from public safety, is what the sponsor is, it's an executive, like I talked about that approves or approves major changes, and that you go to to get sign off or that comes to you and says hey wait a minute what's going on with here i'm hearing some rumblings and shouldn't be as a

project manager nervous about working with or talking to your sponsor because typically the vice presidents or higher c-suite even that's that's part of the business of being a project manager is getting comfortable with talking to people from all levels that high level advisory group we talked about the steering committee. Again, they in conjunction with the sponsor and the sponsors typically a part of the steering committee. And often I've seen also the project manager and the business owner. But they are, you know, let's say you need $25,000 more dollars and whatever threshold you all talked about, you have to go to the sponsor and then the committee for those kind of things. So typically that that meeting tempo,

you might meet weekly with the business owner and the team, maybe the sponsor there, or the sponsor there, and then monthly with the steering committee. It's kind of a good tempo to look at. Again, there's so many different ways because there's so many different organizations. That's just one that I've used and seen a lot. Who asked for the project? Who will own it? Another thing in the IT space in particular is instead of business owner, there could be application owner. So let's say you're doing software instead of a business process owner that you're going to do if you're putting new application or new software out there. They're going to own it after it goes live and the project's over.

Project manager, that's us. We're facilitating a process. We're monitoring and reporting on the progress. We're keeping the team together, right? This is where there's soft skills of project management really come together in that third bullet of keeping the team together. It's not that difficult to set up a task and project or whatever system you're using. It's not that hard to set up reports. The challenge in project management is people, right? It's also the opportunity, building relationships, and keeping folks together, asking them how their day was, you know, generally caring about it. But that third bullet, I think for project managers,

if they were numbered, I would make number one, it's keeping the team together and moving forward. The bottom box is the functional groups is the folks that are getting it done, right? Our subject matter experts that I and you as project managers, program managers should be defaulting to, right? You tell me how we need to build this, how we need to get this done, and I'll help build kind of the structure around it is really what I like to think. And so grouping together, I really like grouping things by functional specialties. Again, if you have functional specialties, and you have geographic layout, then you can combine those. These are our boots on the ground, right? They're the ones getting it done. The ones that we owe the thanks to, they're going to put in the hard work, get it done, and then we get to report on it and make sure that it's

happening. That's the kind of frank how project managers work with teams is that functional group folks, they get it done. So we owe them our time and our effort and our appreciation. So let's keep focusing on those details building out the schedule i'm going to show a very easy basic example of a schedule but this is where we're going to really get in the task the subtask really detail um and it's you know like we talked about from our earlier effort we think it's going to be these couple months and then these months well that we're going to know by the week by the days really really get into the nitty-gritty of that schedule That's what should be happening in this planning phase.

And like I say, it should, should start once you get that charter going and go, okay, let's really build out that schedule and go all the way through closing, right? Through go live through, okay, we're going to close this thing out on this day or this week. Um, we're going to track that budget, right? That's a big deal. We got a lot of money in this example I used earlier. We got a million bucks. Capital, right? Physical goods and services, operating, installation, consulting fees, salaries, taxes. And I'll show you a very, very basic example of a budget here in a second. But that's typically two big or the two big groups of budget areas. So if you haven't heard those before, look up more about capital operating costs or CapEx and OpEx is what you'll hear in the project management or business world or a lot

of other areas is another way to say those. And ongoing support. That's one thing not to forget, right? So we may buy a bunch of stuff initially, let's say we're going to do a computer upgrade, we're going to buy a bunch of those computers, we're gonna use capital, we're going to pay our people and operating to keep those things up to date. That's our labor costs. But there's also probably ongoing maintenance and support. Maybe there's quarterly or annual updates that cost money. And that needs to be factored into your budget as well. A super basic example here of the schedule. This is actually an old Excel schedule thing that I used to use before I got into Microsoft Project and some other good online project management tools.

As you can see on the right, it's from 2017, but it works, right? So if you don't have anything and you're setting up a project management office for your organization, you don't have all these other tools, Google, Microsoft Excel, Gantt chart, and template like project management template, and you'll find something like this. I'm happy to share this too. It's generic, you can see looking on the top, you know, you have your project name, project leads, team members, a little nuance with this one, changing the dates and things that have to do with how the cells below are formatted. So you can see that when you find examples of this, and I found this one online, and then I changed it. But really the gist of it, what are the tasks?

What are the subtasks related to this task? Who owns it? When do you, when do we think we're going to start it? When does it do the types? You could, you could kind of make this a customized at what phase are these in, right? So we can even track, are we still in planning? We're reviewing it, we're approving it. And then the status, we didn't start it.

It's on hold. We're in progress. And again, you can, it's Excel. So you can format all this jazz however you want. But the cool example I want to show here, and again, when I talked about the status, meaning you could pull this up and say, okay, everyone, here's where we are today, are we on track? Oh, we're not started, what's going on? And just use this to talk through things. And you can see you can have concurrent, you know, big areas, project areas going at the same time, you don't have to do this, then this, then this and this, like the purest waterfall,

so to speak, schedules, you know, are going to be what schedules need to be to get the project done. So that's just a really quick example of what one can look like if you've never seen one. Oracle, you know, I don't know all the magic behind this. I'm pretty good with formulas, but pretty cool to see that Gantt chart. But Gantt charts are a standard. So if you're gonna get into project management, be familiar with reading, setting up, looking at Gantt charts.

And the budget, super basic, right? So I use that million bucks we talked about earlier. Total budget's a million, CapEx or capital costs. It's 300,000, 100 of that is for hardware, 200 is for facilities, right? Those are things up front we're going to get value from in the future. Then operating expenses, personnel, right? We've got to keep paying our people. And you can have that in CapEx as well.

I just kind of broke it out because it's an ongoing cost now to help, you know, take care of all the stuff that I mentioned up there, the hardware and facilities and maintenance, right? So that key point that I mentioned about you have to remember to plan for ongoing maintenance, or you're going to run into needing to spend money that you didn't budget for. So that's a quick schedule and budget examples for this planning phase. If you want to hear more, check out episode 32, where I go into the planning phase. I did a run of going through each of these in more depth on the People Process Progress podcast. So check out episode 32, where I go into the planning phase, I did a run of going through each of these

in more depth on the people process progress podcast. So check out episode 32. Putting in the work. Now we're gonna get done we're executing, right? So we need to provide trainings that is huge, right? I think making training on a new system, a new process, a new product, whatever the unique thing that's temporary, right as a project that you're going to do, people need to get trained on it, because it's going to change their workflow, it's going to slow it down for a little bit till they adjust, or it's going to make people safer, it's you know, whatever it's whatever problem we're solving with this project, consider making a requirement, it's not always that way. But it's, it's a good thing. And then we know, okay, this percent of people were trained. So that could be one of your KPIs, right?

We are going to have 100% people trained, which is really hard to do before go live, or we need to have at least 80% or whatever your organization is comfortable with. This, again, when we talk project management, that's tied to but not the same as change management, if we haven't trained folks and giving them the knowledge, right, from EdCar, it can it can negatively affect adoption. So if they say, well, no one ever trained me, or they didn't actually get trained, then they're not going to use the new process, they're not going to use the new widget that you gave them. Or if you gave really good training, folks could use the new devices you put out there or be really good at the new process, because you really trained them up well. Pre-install testing, 100%, we should test anything before we put it out into the world.

The difference would be, and again, this is a must, we're not going to find everything. So if I test five things and I'm going to put 500 things in the world, there's some stuff that's just going to happen when I put that many more than the test number. So you want to have a good test cohort. And let's say we're doing a process, 30 is a good number that I've used or been, you know, guided to use in the past, as far as we're looking at like a process, let's say we're trying to improve the amount of time it takes someone to do a task, let's time and, you know, look at 30 people to do it. And we can put that into our

testing. And then afterwards, you know, we can can see how that compares but we need to in our test environment particularly for software and hardware processes we could have people come into a room and do the new process and say how did that work and then tweak it so many different ways to do that but training and testing are huge before we go live meaning we put in the the product or the process or whatever out into the world. Go, no go.

So it's good as a project or program or portfolio manager, whatever level you're doing, but let's say for project manager to set up with the sponsor and the steering committee, a current state of, as of this date, we are here, we are good to go, we are at risk, we are critical, whatever it is, a week, two weeks before go live, before you're going all out into the environment. And then, you know, if it's a go, cool, we're good. We plan for go live. We've trained folks.

We tested folks. If it's no go, why? Maybe all the equipment you plan to be there that you're going to have to install the day before didn't show up. All this stuff happens, right? And that's a no go and it changes things. And then you go live. So you need to have people ready, get your service desk ready, get your folks in the field ready, your subject matter experts ready that people can ask questions to. This is the big show. This is when we're putting the new process in place, the new product, whatever it is, this is where we've

done all that extensive planning, we have budgeted, we've spent money, we've gone back and forth, we've gone through the emotional roller coaster of what projects can be. And now we're saying here, team members, here users, here's the new thing that's going to make your process more efficient, safer, it's not going to break as much. So we need to have people on standby to help folks have our service desk or support structure, whatever that looks like, whatever field you're in, ready to go well ahead of time. And then also be thinking about how we're then going to hand this off when we get into closing, which we'll talk about now. And as you guessed, I went into a little more detail about executing on episode 33 of the People Process Priority Podcast. So check it out monitoring controlling i mentioned this is like you know we're doing this throughout um so yes it's one of the you

know the areas that's covered by the project management body of knowledge but it's ongoing right it's not a do this then this then that status reporting that we talked about earlier that's part of this monitoring controlling so let's say we're reporting a status or monitoring and we see something's off we work work with the team. We see, is there a roadblock? Is it supply? Is it this person? Is it me? And we're going to take ownership. How can I help them as project managers and help them do better or help this roadblock and getting equipment, get it out of the way? Whatever it is, we can use that status reporting and monitoring and controlling to get roadblocks out

of the way weekly checkpoints i talked about monthly steering updates ad hoc work sessions right sometimes we just need to put extra work in we need to work technical stuff right get their subject matter experts talking their talk whatever field that's in and set those up as a standard escalation is not a four-letter word right and and so i say that because some folks are as i mentioned earlier nervous about reaching out to the sponsor or vice president or, you know, their boss or whoever it is. If you need help, if you're having stuff at home, or there's other folks on the team or whatever it is, we're adults, right? We objectively can talk to each other. We have those relationships we've built throughout the project. If we need to escalate, we do. It's not tattletale and it's

helping us all be successful for the project. Ask for help early,ate, we do. It's not tattletaling. It's helping us all be successful for the project. Ask for help early, not when you're in the red and you're about to have project failure. But when you first think, oh no, this is pretty impactful, it's better to do that earlier rather than later. Yep, you guys talked about monitoring episode 34. Check it out. Closing, demobilization. This is when we are shutting things down, we're getting ready to hand them off operationally. So we need to make sure that the project piece is pretty defined. And we've said and once we're done, which is this date or week or day, now you're going to call this number for help. And this is the person that

you're going to escalate to not me. And you know know, one of the challenges, and I guess if you do a good job, you're still called upon for projects that you worked on years ago, because someone new knows that you worked on it. But you want to always have a good handoff on, I'm not going to be here anymore. Essentially, here's the support structure that we use that's now going to take over and the team that's going to own this thing. And that needs to be part of your project plan. When you do your planning, it's just you're actually going to execute that part of it here in closing. So who owns it? Who's going to be the application owner or the business owner? And what's their support structure? Who's going to manage those ongoing updates, right? What team

is going to work with the vendor or whomever it is to get the updates, test them out, get them ready for production and do that because you as the project manager or program manager, unless that's part of your job, you're not going to be there doing that anymore. After action review, right? This is the challenge for a lot of folks. Lessons learned is being objective with ourselves. What did I do well? What didn't I do well? What do I think the team could improve on? What could we all improve on? And what did we do well? What didn't I do well? What do I think the team could improve on? What could we all improve on? And what did we do really well that we can carry with us going forward, right? So areas for improvement, what are the strengths we can build on or emulate in the

future, have good documentation artifacts that you've documented so other folks can learn from those. And again, closing phase episode 35, I dive into it a bit more than to do in this video. There's more though. People process progress podcasts. It's on all the big platforms, even some smaller ones. Check that out wherever you listen to your podcast. Thanks for checking out this video. Subscribe, share the show, leave a review, please like this, subscribe to this channel

as well. Go to the website. Like I mentioned, there's more articles. I typically write an article and put a bunch of references for the podcast episodes that do or even some of the just blog posts. So you can listen to the show there too. Please stay safe out there. Wash your hands and Godspeed.