Speaker 1: Hello, there. It's your friend, Phil here, project management trainer and coach. We got a great question in from one of our students, Mario. Mario, thank you very much for your question. And Mary is asking, once the project planning is complete, say I'm halfway in executing, I might also doing some planning slash initiating processes to either help build slash generate change requests. For instance, we have change requests as an output for identify stakeholders, or to replan the baseline out of a huge approved change request. How does this work? So here's the bottom line, Mario, in the world of project management changes can be for any reason, at any point in time outside of developing the project charter. Once the project charter is developed, as the project begins, things could happen. Now the first thing that happens as documented in the PMBOK guide after developing the charter is the identification of stakeholders. Now on the first go round, there may not be any changes. But as you do that in an iterative fashion, there could be change requests, the same for all the other processes. So there's no rule, rhyme or reason as far as change requests are concerned. Change requests could come from a variety of places. And I'm going to show you in a few seconds here a few ideas to help you to help you just see through what exactly is happening, because there are many permutations and combinations that are possible in the world of project management. If you go to page, I believe it's 555 of your favorite book. Let's go there, 555. I believe that's the page. Aha, right there. Take a look at that, Mario. Do you see the overlap that could happen on a project? All sorts of overlap. And I've actually covered this in a previous video, I need to find that video for you. But there are many different permutations and combinations as far as how processes could happen, and when changes could suddenly emerge, you know. So the answer, the short answer is yes, you could be in executing, and you could still be planning, because planning is iterative, you know, rolling wave planning. You've heard the term rolling wave planning in the PEMBOK guide, I guess. Well, rolling wave planning exemplifies the iterative approach to project management. On many a project, it's not a one-way street. It is many different forwarding and backwarding of change requests and analyses and different things, okay? So let me share this with you really quick here, Mario. Take a look at the screen. This is what the PEMBOK guide is suggesting, okay? So imagine the y axis, and that's the level of effort on a project, and the x axis, okay? The x axis is the passage of time. The summary of it all is this. Let's go for a red line for initiating here. So let's say this is, let's say this is initiating. Let me come out of that. Okay, let's say this is, this line right here is initiating. And you can see if you look in the PEMBOK guide, the level of effort is not expected to be that much, and by effort, we're talking about resources, putting in time, effort, energy, brainpower, what have you, okay? Now, if that is initiating, planning, as you can see, requires more effort. Of course, a lot more time is spent in planning. So you see the effort is more, but you do see there is overlap. You can see that overlap there between initiating and planning. Let's change the color to red. Okay, so that's planning. You can see a greater level of effort, but what you see is overlap. And then you throw executing into the mix. As you can see there on the same page, executing has a slightly higher amount of effort. And I mean, this could vary on projects. This is not to be a cookie cutter formula, but this is just to show you the realities of project management. See that? So executing, we could, we could slide it to the side and say it happens just a little bit after planning, or it could actually happen at the same, pretty much the same time as you're planning, then you execute. And there could be just a tiny little gap in the passage of time between those. See, that's the overall idea. Monitoring and controlling, as you can see, it spans across the entire project. So you've got something like that for monitoring and controlling. And what this is showing you, Mario is monitoring and controlling change requests, and so on. It spans across up to the very end, you could still be involved in dealing with change requests. You see that? And then when you take a look at closing, it is very similar to what you saw in the beginning with initiating. Now, this is not meant to be pinpoint precisely what the PMI have there. But it's really to give you a rough idea of how this happens. Closing out of phases does not need to wait to the end, we close out phases a little bit into the project. See. So what this is really showing you, what this is really showing you is, there's a lot of interaction between the process groups, there's a lot of interaction between the processes. And as you read the PMBOK guide, just remember that this does not happen in a cookie cutter fashion. There are many, many different possibilities for change requests. There could be change requests in the dying hours of a project, unlike another project, and there's not. So let me go back. So you said, so we have change requests as an output of identify stakeholders or to replan the baseline. Yes. So let's go to that one place that you mentioned. Let's go to 13.1, Mario, really quick here. Because I want to show you what those change requests pertain to. So 13.1, identify stakeholders. Let's take a look at the outputs and change requests. It says, during the first iteration of identifying stakeholders, there will not be any change requests. It makes sense. But it says, as stakeholder identification continues through the project, new stakeholders or new information about stakeholders may result in a change request to the product, project management plan, or project documents. So what am I trying to make you see there? This right here, this in this image that I drew, this first blue section here, which was for initiating and let me make it a little bit different. Let me make it and make it bigger. Okay, that that little thick blue line there. Here. Let's change it. Let's make it dotted line just for effect purposes. Okay, there you go. So that blue dotted line there, that right there is a bucket. That is all it is. It's nothing more than a bucket. You see, people often get process groups mixed up with phases. process groups are not phases. They're just categories. They're just buckets. So they're not meant to be done in cookie cutter sequential order, you could have initiated and then planning could be happening. And executing could actually begin happening. Let me give you a classic example. In the pen book guide, you've got pre assignment as a way of acquiring resources. Let's go to the page because you may not have gone to chapter nine. But let's go to acquire resources here 9.3. There's a tool and technique here on page 333 called pre assignment. pre assignment, it says when physical or team resources for project are determined in advance, they are considered pre assigned, this situation can occur if the project is the result of specific resources being identified as part of a competitive proposal or if the project is dependent upon the expertise of particular persons. Watch this pre assignment may also include team members who have already been assigned in develop project charter process, watch this, or other processes before the initial resource management plan has been completed. So what are we saying we're saying even before your project charter has made its rounds, they could have been pre assignment, right in there saying, if this is a goal, then this person will be assigned as a resource, or you might even have promises being made, even in contracting, if we get the deal, we're going to put our best person, Bob, Mary, Jill, Jane, they're all going to be on the project. That's pre assignment in an executing process. But this is happening way back in time. You see what I'm saying? Way back in time. So in this image, I'm showing you pre assignment would have been happening somewhere around here, or even here. Okay, so look at these process groups as buckets. Okay, they are just buckets, change could happen at any time. There's no fixed, you know, way of it has to be at this time, or after this time, change requests can no longer happen. No, there's all sorts of things that could happen. But the logical reasoning is, once your stakeholders have been identified, you can expect change requests from any of those folks at any point in time for any reason, either to change the lineup of stakeholders on the project, maybe to include more people, maybe to change a product to change the requirements, a number of things. Okay. So I hope this spells out what exactly happens for you, Mario. And if you've got any other questions, be sure to let me know. Okay, take care, and I'll speak to you soon.