- Welcome to module 19, where we look at managing a stage boundary process. We will be looking at the purpose and objectives of managing a stage boundary process, and also looking at the context and activities. The purpose of the managing a stage boundary process is to enable the project manager to provide the project board with sufficient information so that they can make the key decisions about whether we continue with the projects. The objectives are, I've got several here, to assure the project board that all the products in the stage plan for the current management stage, once we're just about to finish, make sure that they've all been completed and approved and to prepare a stage plan for the next stage or an exception plan. If that's what we've been asked to produce. To explain what we're going to do in that next stage. It's also an opportunity to review the PID and update that if necessary. We also need to provide information so that the board can assess viability, and that means we're going to need to update our business case. At the same time, we can record any information or lessons that can help later management stages. We always do bear in mind that learn from experienced principal and at the end of it, we'll be gathering that information together, giving it up to the board with that request for authorization to start that next management stage. So it really is an information gathering exercise where we gather and update all the relevant documentation. Before we give it up to the board in directing a project process. And you can see that here in the overview diagram of the process, you'll see that in section 19.3, a little bit small bit tricky to read, feel free to annotate this as I go through these activities individually in the next slides. So the activities then in turn, first up, we have the activity to plan the next management stage. Now the entry comes in from the side because we start the managing stage boundary process. Once we're near the end of a management stage. So the project manager has been busy, controlling the stage, working with the team managers to make sure that our products are completed and approved, but near the end of the management stage, we start thinking about the next one. So we pause here in the managing a stage boundary process to reflect on how it's gone, but also to do this, plan the next management stage. So we're going to need to create a stage plan and to do that we may need to have a brainstorm, carry out some product based planning, and at the very least create product descriptions for products that we need to make here. If they haven't already got a product description for them. So we're making a stage plan and any product descriptions that's needs to be made for products that we're making in this stage. From there, we can update the project plan. We know what's happened in this stage that we're just about to finish. So we'll have actual figures for time and costs that we can update in the project plan. And we having made a stage plan, we'll have much better ideas about how much it's going to cost and how long it's going to take in the next stage and maybe better idea about costs of the rest of the project. So we'll update all of those actual figures and improve forecasts in the project plan. And that will have a knock on effect maybe, on our business case. So we'll need to update that. And when we update the business case, we're thinking about, are we still going to get the benefits? What are the new costs? Are there any new risks? Are there any other disbenefits that we need to bear in mind? We're hoping that this weighs up in the project's favour, but if at this point, benefits have dropped because we've had to descope the project in some way or cost and risk, and disbenefits have increased the project manager's gonna, "Oh, hang on a minute. I'm wondering if this is still viable." And later they might recommend to the board that we close this project prematurely. In any case, when we update the business case, as you can see here in my little speech bubble here, we also look at the knock on effects this might have on their existing benefits management approach. Are there more benefits than we thought that we've identified now? Do we need to change our benefits management approach to take into account and measuring those? Probably more likely actually that due to cost and time we've descoped, in which case we have to update the benefits management approach to remove future measurements of benefits that we've been anticipating. So whenever you amend the business case, really also got to think if there's a knock on effect on our benefits management approach. And really if you update one, you also update the other. So we've got a stage plan. We've updated the project plan, we've updated our business case. The last thing to do is reflect on everything and report the management stage end. And you'll do that in an end stage report. And usually this is a very good opportunity to create a lessons reports or add that into the end stage report, gather all this information, then pass it up to the board and directing a project process where they will make the decision. Do we carry on to the next management stage or not? So this is the flow through a normal planned end of management stage in our managing a stage process. But sometimes we might go into the managing a stage boundary process unexpectedly. And this is because we've had a major exception. Maybe we've had a problem with a supplier something's gone wrong. We're going to be delayed. And it might be that we've either going to breach a cost tolerance or a time tolerance to get back on track. That's a very common one. So the project board might request an exception plan and that triggers an unplanned stage boundary. So we use managing a stage boundary process to look at that. And the activity that we use when we start this process is to produce an exception plan. So the exception plan activity is very, very similar to the one at the bottom there where we plan the next management stage. But instead of making a stage plan, we're creating an exception plan here. We might still need to make product descriptions for products that maybe have been amended or we've identified new products that we'd like to make instead. So it is very similar to that very first activity down the bottom. So it doesn't really matter whether you enter the stage boundary process in a planned way or whether or not it's unplanned. And you've been asked to create an exception plan. Once you've got the plan and the necessary product descriptions created, you can then go and update the project plan, update the business case, and then report using the end stage report. So they're the two ways in, but only one way out of this process. And you can see there's quite a lot of documentation that we are creating. And, if there was a requirement for us to update the PID we'd also do that too. So this is a really a moment where we pause and reflect, update the documentation that we need to update and then give it all to the board. And they just love us. Lots of things for them to read before they make their decision. Do we carry on or not? And that's it That is the managing a stage boundary process.