The Organization Theme - Part 2
The Organization Theme - Part 2

The course focuses on the components of the method and how they help to structure project delivery. Delegates should note that evening work will be assigned which is not expected to exceed two hours per night.

Specific course content will include:

PRINCE2 Overview

  • The structure of the method and the guide will be introduced before we discuss the context within which a PRINCE2 project operates.
  • Principles
  • The seven PRINCE2 principles provide the framework for managing the project and are built on good practice developed from successful and failed projects.
  • Themes and Processes


The seven PRINCE2 themes are aspects of the project that must be continually addressed and integrated as the project journeys through its life cycle.

  1. Business Case
  2. Organization
  3. Quality
  4. Plans
  5. Risk
  6. Change
  7. Progress


The seven PRINCE2 processes encompass the chronological activities that are required to direct, manage and deliver the project successfully. The activities include pre-project, initiation and delivery, and end with project closure.

  1. Starting up a Project
  2. Directing a Project
  3. Initiating a Project
  4. Controlling a Stage
  5. Managing Product Delivery
  6. Managing a Stage Boundary
  7. Closing a Project


PRINCE2® is a [registered] trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

The Swirl logo™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved


- There are nine project management team roles recommended by PRINCE2 and we're going to take a look at these in each of them in turn. In fact, actually, we've got four up there, straight away. We've got the executive who controls the project board. It's not a democracy that we vote on anywhere around it. It's the executive that makes all the final decisions and we must only have one executive. The executive reports up to corporate which is not shown but it will be above the board on this diagram, outside of our project management team. And the executive is representing the business then. They want to make sure that what we're doing is delivering value for money and they're also going to be keeping an eye on the business case because they are ultimately then, if they control the board, they're ultimately accountable for the success of the projects and we measure success by whether or not we're going to get the benefits or think we're going to get the benefits as much as whether or not we've met our cost or time targets et cetera. So, the executive represents the business and there's only one of those. They are supported by the senior user or users because we can have more than one of those. And the senior user is going to represent those who will use the product, get benefits to the product or impacted in some way by the final project product. So, there may be actually a fair number of people or roles that could be senior user in the project. And if there are very many of them, then we don't want the project board to become too big and unwieldy because they'll never get anything done so there may be a committee, a subcommittee of users to the side and one of those will be elected or the executive will choose them to be the senior user and they go on the board. So, the senior users are concerned with whether or not our product is fit for purpose. It's a quality angle that they're taking on things here. They need to make sure by telling the rest of the project management team and project manager what we are going to make. So, they need to know what we're going to make and what would be acceptable within it. So, we will gather our quality criteria for quality expectations, sorry, from them and pin them down to measurable acceptance criteria. So, the senior users will tell us what they want and what would be fit for purpose. And so, they're going to be keeping an eye on that and they're going to be making sure that we're going to get a suitable project product at the end of this that will give us the benefits that the organisation requires. So, we have the senior users then and we also have the senior suppliers and they are on the board because they have got lots of expertise, technical expertise and they can tell us what skills and resources are required to complete the products in our projects. There may be one single senior supplier but there could be many others. You could again find yourself in a situation where a committee of suppliers might be formed and then one representative comes on to the project board, may be elected by the executive if nothing else. And the senior suppliers then are thinking about what skills and resources are required. So, we've got the three project interests then represented in our project board and when they come together to make board level decisions, they then become the project board and they will make decisions based on information raised to them by the project manager and they may then go up to the corporate or programme level or customer level above, if they need further advice or to inform the corporate level above of major decisions they've made. So, they're not on the diagram but they are always above the project board. And in fact the project board then acts as a buffer between the rest of the project management team and the corporate level. So, there you have four roles, the project board is made up of three, the senior user, the executive and the senior supplier. The next role to discuss is that of the project manager and we'll return to that in a minute and give you another insight into how much they have to do but the project manager and there is only one of them, they're very busy in a PRINCE2 project because there's lots of things that they've got to manage and delegate and monitor and control. They're going to be responsible for the day-to-day running of the project and they're doing that because they've been given permission to do that by the board. So, the project board will delegate responsibility to the project manager to run the project, one management stage at a time. So, there's a lot of planning, lots of monitoring, lots of controlling going on there. And the project manager is going to be delegating to the team manager or team managers because we could have many team managers. We might have hundreds of products that we need to create within this project and many team managers to create them. So, the project manager will be giving work packages to the team managers and the team managers will then be organising their team members to get them created but notice their team members are not in our project management team. So, the teams will create the products and they'll regularly report progress to the project manager who will then in turn report progress to the board. And the project manager is supported by project support. Project support carries out the administrative tasks and this is not an optional role, none of them are optional actually. There must be somebody carrying out project support, at least one person or maybe a group. In some situations, as I'm sure some of you are aware, it's quite difficult to find enough project support and in fact the project manager often ends up taking on that role as well. Project support are also there to support the team managers and the team managers sometimes end up taking on project support as well. So, we can share those roles. In fact, the project manager could be team manager in smaller projects, particularly if they have the technical expertise and can complete the products themselves. So, the project manager, team manger and project support represents the delivery part. Project manager's managing it but it's the project support and team managers working with the team members that are going to be working together to get through the management stages and make those products. The next role to discuss is the role of change authority because it's inevitable that we will have change requests. We thought we knew what we were going to do at the start but you know things change and issues are raised and some of those issues are requests to change things that have already been agreed. We have a change authority role which is there to examine the change requests and decide whether or not to accept the change or reject the change. And the project manager will, they will receive these change requests and they will, if they have been given some change authority 'cause they could have some themselves, they will actually just make that decision if it's within their limits to do so. But if it's a bigger change and they're not allowed to spend that much money or take that long on one change request like that, then they can escalate up to the change authority. So, the project manager might be given the ability to authorise change that maybe costs a thousand pounds, maybe delays the project by no more than a day but above that limit any change requests go to the change authority and they might have a limit of maybe 10,000 or a week so any changes that will cost more than that and delay more than that would have to be escalated to the board, if the board want that. So actually, the levels of delegated authority will depend on what the project board have decided. They will decide what those levels of authority would be. So, the change authority is a role but the project manager might carry out some change authority responsibilities and also the board would as well but certainly for the big changes, they would make the decisions on those. And the final role to talk about is project assurance. Project assurance give confidence to the project board that the project is on track and that it is being run properly and there are actually three types of project assurance. You can see there we've got connectors from project assurance up to the project board and the members of the board because the senior user will be concerned that things are still going to be fit for purpose and so they will nominate someone in project assurance to audit the work of the project manager, team managers, project support to give them confidence that things are going to be fit for purpose. Now, the executive who represents the business, they want confidence that things are being run properly, that we're using the right policies and procedures and that it still looks like we're going to get value for money. So, they will have somebody in project assurance who will examine and audit the work that's been going on in relation to the business interests. And also the suppliers might have their own policies and procedures and so they will want project assurance to audit the work that's being carried out to ensure that we are using the correct policies and procedures and everything is going as it should. But project assurance is not all about auditing, they are there to support the project manager and team manager and project support as necessary. So, project manager, team manager, project support, they could always go to project assurance and ask for their advice at any time, that's what they're there for. So, the key words to think of when we're thinking about project assurance is giving advice and auditing the work of the project and they're doing that to give confidence to the project board. So, there you go. That's the project management team and all the roles within it and a very quick summary of their responsibilities. And I would suggest that you take a look at chapter seven, we've given you a reading assignment, go and have a look at the different roles there and read in more detail what they're responsible for because that's always good just to have as knowledge in the background, even at foundation level. And we also have appendix C, right at the back of the manual which goes into a lot more detail about what the individual responsibilities should be or are recommended at least by PRINCE2. So, that's another one of your reading activities but that's an extension task, more useful if you're going to come along later to the practitioner part of the course but it's there and it's always interesting to see what they think the different roles should be doing. It would be useful also particularly for the foundation exam to understand the rules around combining roles. Now, I have mentioned that some of the roles can be combined so the project manager could be team manager and project support, project support could also be given to the team manager as well. So, all of those roles could be shared and it depends on the complexity of the project and what's appropriate. But also we need to think about other things as well and we've got that here on the right. We need to think about conflicts of interest. So, where there are conflicts of interest, then we won't combine those roles. We also need to consider individuals capacity. Are they able in all sorts of different ways to do two jobs at the same time? It might be to do with training, capability, time issues. So, do have a think about that. We really want to avoid bottlenecks and I know in a lot of situations resources, human resources are very scarce but ideally, you want to allocate roles so there are no bottlenecks or conflicts of interest and everyone's working within their capacity. So, bearing that in mind, all the roles can be combined, except the executive and project manager. You cannot have one person carrying out the role of executive, making all the final decisions and the project manager who is managing the project day-to-day. I mean the whole point of PRINCE2 is that we have these three levels within the structure. We've got the board directing, the project manager managing and then the team managers delivering products and the project manager has no one to go to if they're going having to go to themselves as executive for decisions, it's you need a, two people at least to carry out those two roles. There's conflicts of interest there. There can only be one executive or project manager and I have mentioned that so that's definitely the rule and that's largely to do with decision making and planning issues. We need only one executive because they make the final decisions. If there's any conflict, it goes up. If it can't be resolved, it goes up to the executive and they make the final decision. But if there's conflict between themselves because there's two of them, well then we're in trouble. So, only one executive around here and there's only one project manager because they need to be that central point of contact. I'll discuss that in a moment. If we've got two or more people as project manager, things slip through the net. Now, it's quite usual to have junior project managers, certainly in large organisations with complex projects and that would be tailoring, if they were managing groups of team managers. But often people are called junior project manager, when actually they're just acting as a team manager and managing a team. So, it sounds more impressive on a business card or on a signature. So, have a think about that we can change the language and the titles of our project management team, that would be tailoring but certainly for our exam just remember the nine that we have here. And another rule then is that the executive's accountability for project success cannot be delegated. It's absolutely their responsibility and they can delegate a lot but they cannot delegate that. They are accountable for the success of the project. And lastly, bearing in mind conflict of interest, assurance roles should not be given to the project manager, team manager or project support. And I mentioned that project assurance are there to audit the work of project manager, team manager, project support. So, if you give them also the audit role, they are auditing themselves and that's definitely a conflict of interest. They are checking their own homework and they might not spot the mistakes. So, bear those in mind, those are the rules and sometimes when you get exam questions, they need you to, well, you need to know those rules in order to get the answer right. The last thing we'll look at then is the role of the project manager. And as you can see here, from the diagram in chapter seven, crikey, that's a lot, yes. The project manager is very busy. They have got an awful lot of responsibility. They are the single focus for day-to-day management in the project and they've got you know line management issues, cost management, they've got to communicate and manage the stakeholders and that's a large part of their job. They're still thinking about quality, not to mention things like change and I won't go through all of these but but clearly you can see this is a very complex role. And this is why I recommend that you take a moment to read about these roles in more detail in the chapter so that you can understand fully what they involve. And there you go. That's it from me. That's the end of this part.

About the Author
Learning Paths

A hard working, self-motivated and dedicated IT Consultant with extensive experience and a proven track record in the areas of Management, Networking, Communications and Security. A capable organiser, quick to grasp and make good use of new ideas and concepts. Reliable and conscientious in all work aspects. Possesses exceptional interpersonal skills and utilises communicative abilities to build, develop and maintain effective relationships. A motivational and inspirational manager, who enjoys being part of a successful and productive team, and thrives in highly pressurised and challenging working environments.