Welcome to Module 12, Part one. This module is discussing the progress theme and we're going to be looking at the Prince two requirements for progress. And we're also going to discuss tolerances and talk about what they mean. The purpose of the progress theme is to establish mechanisms to monitor and compare actual achievements against those planned. So it's about control.

We have a plan for the project and for each stage and how are we going to make sure that we're on track. That's what it's really all about here in the progress theme. We do have some requirements, and first up, we need to define our control approach in the PIDS. So we will record project controls and put them in the project initiation documentation.

We will, as part of our control, have stages and prints to those tasks. It's one of our principles that we must manage by stages. So we have all stage plans and as part of this progress theme, we got to think about how we're going to manage and track and control each stage. We will use managing by exception our principle there to set tolerances.

Tolerance is a really powerful mechanism for us, and I'll talk about how we use that very shortly. And I mentioned this already managing by exception then is what we'll be needing those tolerances for. And again, I'll explain that in a minute. We will use this progress theme to help us regularly review business justification and make sure that we still have a viable project.

So part of the progress theme in our approach we write down in the pit is making sure we have the appropriate controls where we pause and reflect and make sure that this project is still desirable, viable and achievable. And we learn lessons. I see this appearing in quite a lot of our themes. We will learn as we go, and maybe if we track the progress of a particular plan and it seems that we're underestimating cost consistently, let's say by 20%, then we need to help that inform future planning and help us regulate what's going on in the stage when we track the remaining progress of it.

So learning lessons important to us. Tolerances I need to talk about here are set for our various project objectives and there are six aspects of project performance that we need to track and monitor and control. And these would have been decided very early on, naturally, but certainly at project level, we're going to have been set limits for cost, time, quality, scope, benefits and risk and tolerances.

They'll be within and tolerances will be set either side of those targets. So we might have decide this project is going to be £1,000,000 and take a year. So that's a cost and a time target there. And we can sentence all of these aspects of project performance, but I'll just focus on those to just give an example. The corporate program or customer has set us that target of £1,000,000 and then we'll set tolerances, we'll negotiate with them and they'll set tolerances so they won't allow us to overrun by 10%, but they might prefer us to under own by 20% as a cost in timescale.

They might. As I said, we've got a year, but they might allow us, they might tolerate then an overrun of a month, but they would really much prefer us to finish a month early. So tolerances are always expressed in the range. And actually the official definition there is that they are the permissible deviation above and below our plans targets without escalating that deviation to the next level of management.

So this means that I've only looked at cost and time though, but if we were forecast to overrun by 5%, the project manager is just fine just to carry on. They'll take corrective action if they can, to bring it down, but they don't have to escalate that forecast up to the next level up because the next level up is already agreed that they can overrun by 10%.

So this is not a problem. They will keep the next level up informed with regular progress reports. But otherwise, we don't need to pause and wait for decisions and have lengthy meetings and, you know, waste time. So this is very time efficient mechanism for us. So we'll set tolerances for cost time, quality, scope, benefits and risk. So we have six types of tolerance, but we also have four levels.

And this diagram can explain how that works. So in the example I used earlier, a corporate program management of the customer, they set targets and tolerances for time and cost, although they would have been tolerances for the other objectives as well. But these would be called project tolerances. So we'll set project level tolerances for time costs, quality, scope, benefits and risk.

Those would be given to the project board. So corporate give project tolerance, the board then give it out amongst the stages as stage tolerance. So tolerance is given to you by the level above you. So the board get that tolerance from corporates. That's project tolerance given to the project board and then the project will give it to the next level down as stage tolerances.

The project manager then wants the stage, the next stage is approved, will have to negotiate work packages with the team manager and they'll be given targets for time and cost and quality, etc. And so now the project manager is going to give their statements out as work package tolerance. So a particular work package, maybe it's going to take three weeks and that's the time target.

But the tolerance might be you can over one by week or we prefer you to finish a week early in two weeks. So for each of the aspects of project performance, time, cost, quality, scope, benefits and risk, we will set tolerances. And there are the three different levels. So corporate give the project tolerance. The board then spread out of the stages.

The project manager spreads their stage tolerance amongst the work packages, but they cannot give out more than they have. They don't have authority to do so. So that's how we give out our tolerances. And this now allows us to manage by exception. The team managers have their work packages. They can just get on with making the products, but they can't just get on with it and just work in isolation.

The project manager wants to keep control. This is the progress thing and we need to know how we're going to keep control. And one way to keep control is to have regular reports. And so I need to talk to you about progress reporting and you can see the power there from the team manager. The team manager will inform the project manager on a regular basis what the progress is.

And we call that report that progress report, a check point report. The team manager may have come across several issues that they might have just dealt with and just got on with because they had the tolerance to do so. And so let's say they were, you know, three week work package. They can overrun by a week and let's say something went on maybe or someone was sick for a few days, two months.

You just dealt with it because it didn't mean that we were going to breach your work package telling us they were fine and they'll just inform the project manager in the next check point report. Well, we're on track with used a bit of tolerance, but you know, we're still going to finish within our tolerance. It's all fine. So that's your checkpoint report and that will happen on a regular interval, a periodic basis.

In fact, the work package will tell the team manager how often to write this report. If the team manager came across something which meant that they actually were going to breach their tolerances, then they would have to raise an issue. So we do this by just raising an issue. However, we've decided we're going to raise issues in our change control approach.

So it might be that we email issues to a project manager or we might have a very special bespoke workflow system where they fill in a form in the send it off and it gets automated so the team knows you'll know how that works. It'll all be documented in the work package. But so over however they raise an issue, they raise an issue and it goes to the project manager to deal with.

The project manager will then want to look at that issue and if they can do so, they will suggest how the team manager should proceed. They will take corrective action and they might then just notify the project board about this in the next highlight report. So the stage progress report that the project manager sends the board on a regular interval is called the Highlight Report.

And so the project manager might say, Oh yes, I dealt with this small issue in a work package. You know, it's just all within our tolerances, you know, just letting you know so they'll send out the regular hire reports, but we'll see if there's a major issue or the team manager has. And when the project manager looks at it, they think, Oh, hang on a minute, I can't afford to take the corrective action.

I won't because I don't have enough cost tolerance. Well, now we've got an exception. We're going to if we deal with it the way we want to deal with it, we're going to breach the cost tolerance. So this is when the project manager has to escalate that exception and they will do so using exception reports. And that's all been discussed in the change theme.

So we'll pause that and part that for now. But what I'm trying to get at here is that there are regular reports reporting progress. So the project manager has control. The team have been sending up the check reports and the project manager will report a summary of all the work package progress reports, all the check points up to the board in their highlight reports.

Now the board will get these regular reports, but they'll also get reports from the project manager at the end of the stage or at the end of the project. So we do have our regular reports for them. It's the highlight report, but they also get to read the end stage reports and the project reports so that they know how the stage is performed or how the whole project is performed.

We also need to keep corporate program management or customer informed on progress. Now, Prince, too, doesn't recommend any particular reports that the project board write. In fact, in Prince to the Project board, don't officially write any reports. So we what we are really expecting here is that the project manager writes the highlight report and then the project board forwarded on up to corporate program action or the customer, if they want anything different, will have to put that in all strategies and approaches.

But for foundation, let's assume the board don't write anything except their own emails potentially, and they're forwarding up the progress reports that the project manager has written them. And if the board get an exception that they can't deal with because it's too because it's going to breach a project tolerance, the board consider sort that's exceptional. They'll have to escalate.

That's up to corporate as well. Corporate will have to make a decision about project level exceptions. So it's quite a lot going on here in this diagram. But hopefully you can see that tolerance has filtered down through the different levels and then progress reports filter up. People can get on with what they need to get on with as long as it stays within their tolerance.

They send the regular reports up As soon as there is something that happens that breaches the times they've been given, then they have to escalate it and the appropriate level in the in our structure here then makes the appropriate decision. And then we take corrective action and get back on track. Something to talk about here also is I don't know if you've noticed the language I'm using, but some of our reports are regular, all time driven, and some of them are triggered by events.

I've only mentioned actually the end stage report and then project report are event driven, but clearly at the end stage that's an event at the end of a project, that's an event that triggers that particular report. We also have a regular on physical time driven. I'm actually there are only two time driven reports here in Prince too, and those are the checkpoint reports from the team manager and the highlight reports from the project manager.

So that's just something to bear in mind because that often does arise in some foundation questions and practitioner questions. But that's it for me. For now. We're going to explore those reports in more detail in the next part.