- Welcome to Module 17 where we look at the Controlling a Stage process. And in this module we're going to be looking at the purpose of the process, the objectives and the context. And the purpose of the Controlling a Stage process is to assign and monitor the work to be done, deal with issues and report progress as we run through that stage and to insure, basically, that the management stage stays on track and remains within tolerance. So this is really the day to day work of a project manager once the delivery stages are underway. The objectives, then, are to focus on the delivery of those products. We're going to hand out work packages and we're going to keep an eye on those team managers with their work packages to make sure they are delivering the products as we require them to. We're going to try and avoid any uncontrolled changes. We have a change control process and we're going to use it. And we want to keep everyone focused on the task so we don't want to lose that focus. We're gonna be keeping our risks and issues under control and always keep that business case under review. So really, our main aim there is to insure those products are delivered within the constraints that we've given our team managers and the quality standards in those product descriptions. And to insure that we're going to get products that will deliver the benefits that our corporate customer programme want from this project. And all the way through, keeping our project management team focused on those targets and making sure that we're delivering what we need to deliver within the tolerances we've been given. So those are the purpose and objectives. We're going to have a quick look at how the Controlling a Stage process fits amongst the other processes and we have this diagram 17.3., and that's the section in the book to find this, and just like in our other process videos, you can see here on my screen this is quite small text and it's quite a lot going on there, and I will go through a version of that with my slides. And feel free to annotate it. But the Controlling a Stage process does link up to a number of other processes and we'll talk about that in my next slides. The first activity in the Controlling a Stage process then is to authorise work packages. Now this has been triggered, this whole process has been triggered once the project Board have authorised the Stage plan. So once they have said, "Yup, we authorise the Stage plan", this is the first activity. There's nothing else that the project manager can do really here. We've got to give out work packages and then there's going to be feedback from the teams as to how we're progressing and that's, this is what it's all about here, keeping everything on track. So the first activity is to authorise the work packages with the team managers. It might take a little while as we negotiate the terms of how much we're going to pay them, how long it's going to take, particularly if they're external team managers for us. And once that has been accepted and we have created the final work package for them, they understand exactly what they've got to do, team managers will just go off and make those specialist products for us. And the project manager will wait patiently for their first checkpoint report. The checkpoint report will be written by the team manager down in Management Product Delivery. That will be sent up to the project manager here. They will then review the work package status, that's their activity for this, and they will use the information from this checkpoint that they've just received and all the other checkpoint reports they receive from all the other team managers, cause there could be many team mangers all working on various different products. The project manager will read all those checkpoint reports because everybody reads everything they're given around here and they will use that information to understand where we are against the stage plan so to measure progress effectively. They will review the stage status, given the information they've received. They won't keep that to themselves. They need to send up the regular report up to the project Board. So this the activity then, fourth one here, is to report highlights and they'll do that in their regular highlight report. That will go up to the Directing a Project process where the Board read and decide whether or not they need to give any ad hoc direction. So this will happen time and time again, it depends how often we need our checkpoint reports and how often we need to report our highlights, but these activities here, that you see in front of you, are going to be the activities that we use most in the opening parts of the management stage. At some point though, the work packages will be completed, the products will be made, tested and approved, and the team manager will formally deliver the completed work package to the project manager. And the project manager then needs to check that all the documentation has been updated properly, they'll review the work package status, check it off, "That's complete, great", they'll then go to the Stage Plan and review Stage Status. And they'll look at the Stage Plan and think, "Hmm, great. "Well that's done. "Excellent. "Can we give that team manager another work package?" And if the answer is yes, then off we go again, authorising a new work package, wait for the checkpoint reports, refer to the Stage Plan, "Are we on track?", send up more highlights to the Board. So there's a little bit of a cycle going on here and wouldn't it be great if that's all we had to do? Wait for checkpoint reports and then mark them off against the Stage Plan. However, in reality, and even in prints too, which is what everyone considers reality all the time, there are going to be issues. And so, the next activity we need to look at is the Capture and Examine Issues and Risks activity. The project manager is probably going to be bombarded with emails and phone calls about various things they need to deal with and some of those issues will need to be dealt with formally so they will be recorded in the issue register but some of them, if particularly they're quite complex or tricky or need to go to other people for discussion and advice and decisions, some of them may need an issue report. So we create an issue report for some of the issues that need to be explored in more depth. So the issue report might actually be sent to a number of different people, but we might well send it up to the Board and they will read that issue report and then they will give us some ad hoc direction and hopefully guide us to make the right decision. The issue report might not be required at all. Some of these issues might be very straight forward, easy to deal with. Somebody might actually be telling us that a risk has been realised and we go to our risk register. We know exactly what to do. So we will then take corrective action and we don't need to go to anyone for advice. Well, at least that's what we hope anyway. But the Board is always there to give ad hoc direction when required and will always give their advice when asked. Now the project manager will take corrective action as they see fit. But sometimes they cannot take the corrective action they want to take because to do so would mean that they've reached their tolerances for time, cost, scope, quality, risk or benefit. So if they cannot take the corrective action that the want to take, we are now in exception and they have to raise that up to the Project Board. And they will do that using an exception report. So that will go up to the Project Board. If it was a stage tolerance breach, the Board will come back with their decision on what you've got to do. If it was a project tolerance breach, they'll have to escalate it up to Corporate, Corporate will filter down by the Board what they want us to do. And then the project manager will take the corrective action that has been agreed upon. So there's quite a lot going on here in the Controlling the Stage process. There's lots of, I think of it as plate spinning or juggling going on, as the project manager tries to keep everything on track. And they will try and do so the best they can within their tolerances, taking corrective action as they see fit but, on occasion, they are going to have to escalate it up to the Project Board and they will then come back with decisions on how we're going to proceed. Eventually, once we've got to the end of Controlling a Stage, we will now then need to start thinking about Managing a Stage Boundary or maybe Closing a Project. So we do have outflows into other processes as well but the most of the interaction with the other processes here are to do with the team managers down in Managing Product Delivery and the Board up there in Directing a Project Process. So that's the Overview of Controlling a Stage process. I'll just talk though, as another summary there, just to look at it in a slightly different way, what we're trying to do here then, in summary, is to authorise our work packages, review the work packages, receive the completed work packages, all the while monitoring and reporting our progress and managing our issues and risks. So that's the Controlling a Stage process.