Welcome to module 12, part two, where we finish up the progress theme. We're going to be looking at the different types of control that we have. We're going to also look at the way we review and report progress. And we're going to go through quite a few different management products that will help us do that. So, types of controls, just touched on it ever so briefly in part one. We have event-driven controls, triggered by events, strangely enough, and we have time-driven controls, which we will use to monitor and report progress. And there are only two of those. We'll just revise those in a moment. So bear in mind, we have quite a lot of ways to keep control of the projects. Most of them will be triggered by events, and we'll just report when we need to report. 

So those are event-driven. But if there's anything that we're asked to do on a regular basis, or periodic, then we would consider those to be time-driven. If we look at those reports from a slightly different angle, and different ways to control, we can control progress either by baselined products, and we're talking about things like the project plan, stage plan, exception plan, our work packages, anything that we need to create and then agree, they are then baselined. We're not going to change the project plan, unless we go through formal change control. We're not going to change the work package once it's agreed, until we go through formal change control. So, those items will be baselined and become reference documents. I mean, that's really the point here. They become reference documents by which we measure our progress. So they are event-driven. We make them when we need to make them. Progress reporting, on the other hand, is not. They're not considered baseline documents. We will create a checkpoint report, if we're a team manager and have to report progress, just as the project manager has to report progress as a highlight report. 

So those are considered time-driven because we're making them at regular intervals. We know how often to make the checkpoint report, because it tells us in the work package, if we're a team manager, and the project manager will know how often to write the highlight report because the board would have told them when they created the PID, or project initiation documentation. And then there are the event-driven reports, the end-stage report, and the end-project report that we, strangely enough, make at the end of every stage, and the end of the project. And that will report on how we progress through the stages and how we performed at the end. So we will need to look at those management products a little bit more closely, just so that you're happy about what they're for, for the foundation exam. And the project plan, we'll look at first. That's entry A.16 in appendix A. This will, in terms of control, include project-level performance targets. 

So what are our targets for time, cost, quality, scope, benefit, and risk? What are the tolerances? Those are set by corporate, programme management, or the customer. We also have control at stage level, and that's in the stage plan. The stage plan will form the basis for day-to-day management by the project manager within each management stage. And that will include the stage tolerances that they've been given by the project board. We also have exception plans. So, if there had been some kind of issue that caused an exception, we may, as project manager, be asked to create an exception plan that might well replace a project plan or a stage plan. It depends on what tolerance was breached in the first place. 

So the exception plan may be requested by the project board after considering an exception report that we've given them. And that will also then include tolerances for the new plan. And the last baseline control management product that we need to look at is the work package, which records the agreement between the project manager and the team manager. It's an agreement of the work that's going to be completed in the work package. And it will, that work package will also include product descriptions for the products that are going to be created. So, with all of that information, the team manager knows exactly what the targets are and tolerances are for time, cost, quality, and scope. And there may also be some targets for risk as well. 

So this work package then will be agreed, it's baselined, and the project manager can measure progress against that work package as they receive the checkpoint reports from the team manager. If we have a look at the progress reporting management products, I've already told you about the checkpoint reports, time-driven, regular, providing details of the progress of the work package, produced by the team manager, and going to the project manager. And I've already told you about the highlight report that the project manager will write. Given the information that they've read from all the checkpoint reports, they can use all of that to write their highlight reports, which will go to the board, providing details of progress for the stage that we're in and a summary of the whole project. They will also have the end-stage reports that they read at the end of every stage. 

Event-driven, this one, it's an update on progress, and it will help the board decide whether or not this project is still viable, whether or not we're still on track, and whether or not we should continue to the next stage. This is produced by the project manager, as most of our reports are. I think the only exception there is our checkpoint, which is produced by the team manager. The end-project report is again, event-driven. We create it near the end of the project, strangely enough, and we then give information to the board, and that will help them evaluate whether or not we're ready to close. And again, produced by the project manager. Now you thought we were nearly finished, but actually there are some additional management products to tell you about as well. I've talked about the daily log in passing. Just to pause and just give you something to read about that here on screen, the daily log then records informal issues, required actions, or significant events not captured by our other PRINCE2 registers or logs. 

So that's our catch-all document, your inbox, your outbox, your notebook that you carry around. We have the exception reports, which will be produced when a stage plan or a project plan is forecast to exceed its tolerance. We need to inform the next level up that there has been a tolerance breach, that we are in exception, so we need to report it. That's the exception report. We also have a lessons log. I've talked a lot about how important learning lessons and learning from experience is to PRINCE2. It's one of our principles. And we do need a lessons log to hold those lessons, a repository, as they call it here, that apply to this project, and also could be applied to future projects. So as we learn lessons, we're going to put them in our lessons log, and we're going to use those to help us when we write our reports. 

So if we learn lessons, important lessons, as we go along, we'll include them in our regular reports, our regular highlight report, and we'll also maybe give a summary of these. In fact, usual to give a summary of these key lessons learned at the end of every stage in a end-stage report, and certainly at the end of every project in an end-project report. And in fact, you might even call it, that part of your end-project or end-stage report, a lessons report. So it's almost like its own thing, a lessons report. It supports lessons log. If more information is required, we can use it to pass on lessons that can be applied to other projects or indeed even business as usual. That's also appropriate. So there you go, lots of management products that help us control and track progress in our projects. And that completes our progress theme.