Lesson 03: Principles 4 and 5

We discuss the ‘Manage by Stages’ and ‘Manage by Exception’ principles in this lesson.

Based on AXELOS PRINCE2^® material. Reproduced under licence from AXELOS. All rights reserved.
Note: PRINCE2 2017 edition is now called PRINCE2 6th edition.

00:06 – So as promised, our next principle is Manage by Stages.
00:11 – So, Nader, the first question is what’s a management stage actually and why do we need it?
00:18 – Because it doesn’t seem realistic to plan everything in detail from the beginning because, well, first it’s really difficult to think about one year, for example, from now with all the details and the other thing is that even if we can do it now, things may change during the project. So what should we do then?" Yes. Lots of variables will change, yeah, outside the project as well, yeah.
00:44 – Yeah. So what we do may not be really useful and on the other hand, because we do have all those details in that scenario, we will have a false illusion of control over the project.
00:56 – So instead of that, PRINCE2’s approach is that we create a high level plan for the whole project and then detail that plan right before … oh, there was a bug …
01:05 – It’s a software bug.
01:07 – It was really hardware, I’m sure, yeah. Okay. Hardware bug, yeah.
01:12 – I felt it. Okay, so we detail it exactly before the stage. Yeah.
01:18 – So, for example, every month, two months, three months, we have more information, reliable information for creating the detailed plan, and I think that’s very helpful, that’s really great, and that’s something that nowadays that is very common in Agile projects.
01:39 – In Scrum, for example, we don’t have that type of high-level plan usually normally in Scrum projects.
01:45 – It’s only about the detailed plan that is created in the beginning of each sprint, and even not the whole plan is created in the beginning, but in DSDM, the other Agile methodology, we have a high-level plan and then we create the detailed plan for each iteration.
02:03 – So that’s the idea and it was there in PRINCE2 to begin with.
02:07 – Yes. The whole idea of stages, yeah, and of course, the Project Board then allows or permits the Project Manager to run the project stage by stage, but report to them. So, it’s much easier.
02:18 – So at the end, let’s see, of each stage, the Project Board then can review the work done in the last stage, so the progress to date.
02:25 – There they will look in the Stage Plan to see what they’ve done, the status of the project overall, so there they will use the Project Plan, that’s a high level plan that they use all the time.
02:36 – They can check the Business Case to see if the project is still worth doing, an overview of the risks, maybe it’s become too risky or maybe it’s still okay, and of course, they can decide to even have a quick look at the next Stage Plan, even though they never went into detail, but they should have an idea what to expect in the next plan as well, and then using that, they can decide whether to allow the project to continue or not.
03:01 – So it’s really a control point, let’s say, for the Project Board as well.
03:05 – Yeah, that’s also important. I didn’t mention anything about that, for the justification of the project, for example, we may forget to check the justification normally, but now we have Manage by Stages, we have certain points during the project at the end of each stage where we know that we have to update the Business Case, check the Business Case and other things, and have a formal authorization from the Project Board.
03:29 – Yeah. Each time. So they come in, spend a short amount of time reviewing the highlighted data and then they make a decision to allow. That gives them more control.
03:37 – For example, most Project Managers have a funding problem.
03:40 – They don’t have enough money. The money that they were promised in the beginning doesn’t arrive in the project, but when we have Manage by Stages, each time we go there, show them the plan for the next two months or three months, for example, say that this is the money we need, this is what we will create. Is it fine?
03:59 – And when they authorize, part of that authorization is that they commit to provide you with the funding you need.
04:05 – So that may prevent many of the problems. Yeah, to release it. Yeah, okay, good.
04:10 – Now, the choice of the appropriate stages for a project will depend on a number of factors.
04:16 – For example, the number of stages will depend on a number of factors.
04:20 – So I will name a couple of them and you can respond to each one to see whether it’s correct or not.
04:25 – So, one thing that will decide the number and length of a stage is the size and complexity of the project.
04:30 – Does that sound okay?
04:32 – Yes. When it’s more complex, it’s more uncertain and therefore we need to have more controls over the project, and many of the controls are done in the stages, in the boundaries of the stages, and therefore it’s a good idea to add more stages. Okay, good.
04:46 – What about the supplier organization policies and standards?
04:52 – Suppliers. Standards. That’s not the main driver.
04:59 – Yeah. If I said customer organization policies and standards, yeah. Then it would be, yes, but for the supplier.
05:05 – If we can consider that Maybe, maybe, maybe.
05:09 – Yeah, maybe the supplier is hard to get and they know how to do everything, maybe, but normally no, it’s customers' accounts. Okay.
05:18 – The project risk? Will that? Oh sure. Yeah? Why?
05:22 – When risks are higher, we need to have more controls to make sure which way we are going and what’s happening to the project.
05:28 – Okay. So more controls means more decisions. Yeah. More stages. Yeah, more decisions, okay.
05:32 – For example, maybe we have to stop the project.
05:35 – Yeah, and what about trust between the Project Board and the Team Manager?
05:39 – If that trust is high, will we have shorter stages?
05:43 – Between the Project Board and the Team Manager? Yeah.
05:46 – Why do we have a Project Manager then?
05:49 – I mean I can’t all the answers cannot be yes, you know. I got to keep you guessing.
05:55 – The relationships are between neighboring layers, so that’s between the Project Board and Project Manager, and then between Project Manager and Team Manager.
06:05 – Okay, so let’s pretend I asked you, you got the question right and you saw the trap.
06:10 – Okay, so let’s say I asked between the Project Board and the Project Manager.
06:14 – Does that make a difference? The trust between them?" Yeah, maybe they can have more stages to have more controls, but maybe easier than that is to have smaller tolerances.
06:27 – That’s the other alternative. Yeah, as well, yeah.
06:30 – Or more powerful Project Assurance to keep checking the Project Manager all the time.
06:36 – Yeah. I think I read once that if the Project Board are working with a new Project Manager at the beginning, they probably might keep the first two stages short, but after that, the trust is there and then they allow to have wider stages.
06:50 – I think that’s a good example, let’s say. Good.
06:53 – Now the Project Manager believes that stages provide review points for Project Assurance to assess the project’s viability at defined intervals.
07:04 – Does that sound correct? Because I’m not using, I’m saying Project Assurance, not Project Board. Does that make sense?
07:13 – Well, I see two problems here. The viability of the project is mainly a concern of the Project Board.
07:20 – Project Assurance can be part of the Project Board.
07:23 – I mean done by the same people in the Project Board, but when you say it like that, it’s a separate role.
07:29 – On the other hand, what the Project Assurance needs to do, I think, should be done continuously during the stages or only at the end of a stage. Is it so?
07:37 – Well, actually the answer to this question was yes, that it does provide intervals, defined intervals for Project Assurance, so that’s why I asked it, but I might have said actually no, like in your line, that’s the Project Board that do that, but in the manual it says, Project Assurance as well can use these as defined points to check also.
08:02 – Well, when we say Project Assurance, we can also see it as the thing that the Project Board members do.
08:08 – Yeah, because they report into the Project Board. Yeah, but Project Assurance shouldn’t be continuous?
08:14 – Well, let’s say if we spoke to whoever wrote the manual, they might say, “Well, when is it a good time for them to check?” you know, or a good time for the Project Assurance to do their job is when they have delivered the last stage, then just go and see what the Project Manager is saying, is it correct, you know.
08:32 – That’s probably what they mean. Okay.
08:36 – Maybe they meant because we divide the project up in stages, it’s easier for them to check, you know.
08:41 – Who knows how they would answer, but I’m trying to give some reasons.
08:46 – Alright, I’ve got one more question for you on the stages.
08:50 – In a low-risk project, the Project Board asked the Project Board to authorize two stages at a time because this will save them time, but it will also give the Project Board the necessary control.
09:04 – Is that appropriate for the Project Board? Who asked the Project Board?
09:06 – The Project Manager asked the Project Board.
09:09 – Okay. That’s not a good idea I think.
09:11 – The reason we have the stages is to plan the stages one at a time and check the stages one at a time based on everything that happens in the project, and the changes in the environment. If we want to do them two at a time, it’s like having one bigger stage. It doesn’t make any sense anymore, you know.
09:30 – So it’s not a good idea. No, it should not be done.
09:33 – So the Project Manager asks the Project Board one stage at a time and then they make one decision at a time to allow one stage to continue or not. Good.
09:43 – Now, the next principle is the exception one, it’s Manage by Exception.
09:49 – So here the Project Manager believes that the Manage by Exception principle is all about enabling the appropriate governance in the project.
10:02 – Does that make sense or does that seem right?
10:05 – It has a lot to do with governance, yeah.
10:08 – What do you mean by governance? Project governance?
10:10 – That’s always a difficult question.
10:13 – If you really want to give a practical answer, something that people can really understand.
10:18 – Okay. Let’s just say it’s how decisions are made then.
10:22 – Can I say that or is that too light? It’s not bad.
10:26 – Okay, it’s how decisions are made in a project.
10:29 – That’s the way I explain it. Maybe it’s not wide enough.
10:33 – Yeah, well, we need to have our own jargon, so governance. You can keep using that.
10:40 – So the answer to the question is yes, this is correct.
10:43 – The Project Manager is correct to believe that Manage by Exception principle is all about enabling project governance or enabling how decisions are actually made and how we hand down authority to do things and how we can how the level below can escalate up as well and then we can make decisions based on that.
11:04 – It’s about delegation and empowering people also.
11:08 – Yeah, yeah, that’s for sure. Okay, now in this principle as well, Manage by Exception, one of the six variables which they use in this principle is scope.
11:23 – So the PRINCE2 says that scope is an allowable variation of a planned product.
11:30 – So is scope linked to MoSCoW in any way?
11:36 – It can be if you want. What does that mean?
11:39 – But normally in many projects, we don’t have a flexible scope.
11:44 – We have a predefined scope and we may make adjustments to the scope.
11:50 – For example, replace the material somewhere with a different one.
11:57 – Usually we do not remove part of the scope in many projects, consider a construction project.
12:04 – You never say that, okay, let’s forget about windows, for example, but in some projects such as IT projects, we can have more flexibility.
12:15 – Okay. So what you’re saying is we have six project variables.
12:18 – One of them, the scope, may not be so variable.
12:21 – It could be kind of saying that’s what we’re going to get.
12:25 – Yes, in some types of project. In some types of projects, alright.
12:28 – But if you want, you can make it flexible and MoSCoW prioritization as you mentioned is a really good idea.
12:34 – A way of prioritizing the requirements. Yeah, and understand the role of each feature.
12:39 – No, it’s a little bit more than prioritizing because prioritizing can be a simple ordered list of features, for example, based on their importance, based on their value, the amount of value that they deliver, but MoSCoW prioritization mainly, contains that part, but it’s mainly about the role that that feature has in that product. Yeah.
13:02 – And in case you don’t know, in MoSCoW prioritization, we have must-have items, should-have items and could-have items, and won’t-have-this-time items.
13:12 – Must have is something that you need to have in your product, otherwise you won’t be able to use the product.
13:18 – Yeah. It won’t be practical, yeah. It won’t be a usable product.
13:22 – Or it may not be legal to use that product based on regulations that you have in your industry.
13:28 – A car without mirrors is one example that I give. Side mirrors. Yeah. It’s illegal to drive without it.
13:33 – Based on law, yeah, you are required. So that’s a must have, so you cannot use the product.
13:38 – You see it’s about the relationship.
13:40 – A should have is something that we will run into problems if we don’t have it, but we can find a work around for it.
13:47 – We cannot find a work around for the must-haves, and in an IT project, for example, you can do the thing manually.
13:54 – In one of our projects, we didn’t have the feature to reset the password.
13:59 – Yeah. That’s an example I give as well.
14:01 – Anytime someone wanted that, needed that, they could send an email to the admin and they will change the password for them.
14:07 – So that’s a should-have. And could-have, sorry, you want to tell something?
14:10 – No, go on, go on, let’s finish because I’ll give a comment then.
14:13 – Okay, and a could-have is something that adds value, but you won’t have problems without it. Okay.
14:20 – So could the scope be like the following, where the customer might say, “I want to have all of the must-have, I want to have all of the should-have and I want to have 20% of the could-have.” Could that be a scope requirement?
14:36 – You can agree on that if you want. That’s not the default MoSCoW system.
14:42 – You know, MoSCoW comes from DSDM, it belongs to DSDM. It’s proprietary.
14:47 – I was expecting you to say, “Frank, that’s a really good example, I should have told you that.” Well, in DSDM it’s not like that, but you can agree on something, I guess, if you want but the problem is that how you’re going to label different features.
15:01 – When you make that agreement, that’s the main part of the problem.
15:06 – Good. The fly came to visit me as well as you can see.
15:09 – So there are a number of advantages to using this principle, Manage by Exception, and PRINCE2 believes that one of the advantages is that the Project Assurance is not required to check if they are effective.
15:23 – Is that appropriate for the Project Manager to think like that?
15:27 – No. Manage by Exception will let the people in the lower levels of governance make the decisions, but still take a look to see if they are working properly and that checking is the Project Assurance.
15:40 – Project Assurance. The project cops, military police. Yeah.
15:43 – It is a good way, yeah, so Project Assurance should be used to ensure that such tolerances are controlled, are effective and in working condition, that’s their job, it’s the reason to be there.
15:56 – Okay. I think this is the last question on Manage by Exception.
16:00 – So the PRINCE2 manager sees that they are out of tolerance, okay, and now being out of tolerance for them allows them to access the change budget, so they can deal with the exception.
16:11 – Is this the correct way of using the principle, Manage by Exception?
16:16 – Maybe I didn’t understand the question properly. So, I’ll ask it again.
16:19 – because the change budget is about changes.
16:21 – So the Project Manager is out of tolerance, so they assume then, okay, above tolerance, great … no, they don’t say great, it means, “No problem, I can just go directly to the change budget, get the money to fix the problem and allow the project to go on.” My question is, is that a correct use of this principle, Manage by Exception?
16:40 – No, and there are two problems here. The first one is the Manage by Exception, having an exception means that you have to escalate it. Why?
16:49 – The Project Manager doesn’t look for the solution anymore. That’s what exceptions means. Yes.
16:54 – You ask the Project Board to make the decisions, that’s the first one, and the second one is that the change budget is used for changes to the scope, the request for change and not for anything else.
17:05 – Yeah, and that’s got to go through the change control cycle.
17:07 – The Project Manager cannot take that money without permission from the change authority. Also that, yes, yes.
17:12 – Good. Okay. I see. Now it’s the next principle, which is about the products one.
17:18 – This one is called Focus on Products. The Project Manager advises" What about coffee?
17:25 – Let’s focus on coffee now. Let’s focus on coffee. Yeah. Okay.

Next we will discuss the focus on products and tailor to suit the project environment principles.

Scenarios/questions we’ve discussed in this lesson:

Manage by Stages
- What is this principle about?
- Which of the following should be considered when deciding on the number of stages?
  - Size and complexity of the project
  - Supplier’s organizational policies and standards
  - Project risk
  - Trust between the project board and the team manager
- The PM believes that stages provide review points for project assurance to assess the project’s viability at defined intervals, rather than ad hoc. Is this correct?
- In a low-risk project, the PM asks the project board to authorize two stages at once, as this will save time and still give the project board the necessary control. Is this appropriate?
Manage by Exception
- The PM believes that the Manage by Exception principle is all about enabling appropriate governance. Is this correct?
- One of the six project variables is scope. Scope is the allowable variation in the plan’s products. Is scope linked to the MoSCoW technique in any way, or can it be?
- The PM believes that one of the advantages of this principle is that project assurance is not required to check whether such controls are effective. Is this correct?
- The PM sees that they are out of tolerance and they decide to use the change budget to deal with an exception. Is this appropriate?

Lesson 03: Principles 4 and 5

Contact your trainer to ask questions