PRINCE2 2017 Organisation Theme: Roles, Interests and the Project Board
Build a temporary project organisation in which business, user and supplier interests are represented and every important decision has a clear owner.
Executive summary
Three interests
The project organisation must engage business, user and supplier interests so value, usability and technical feasibility are all represented.
Board directs, manager manages
The project board makes key decisions and exercises overall control; the project manager performs day-to-day management within delegated stage tolerance.
Delivery has its own management level
Team managers coordinate specialist work packages and report progress to the project manager.
Assurance is distinct from support
Project assurance checks that the project is being conducted properly on behalf of board interests; project support provides administrative or specialist support to management.
Purpose of the Organisation theme
The source gives the Organisation theme a clear purpose: define and establish the project’s structure of accountability and responsibility. A temporary project often draws people from several functional areas and may involve external suppliers. Their operational reporting lines do not automatically tell them who has project authority, who accepts products or who decides whether the project should continue.
The method therefore creates a temporary management structure with defined roles. The structure is not intended to duplicate the permanent organisation; it exists to make project decisions and accountabilities explicit for the life of the project.
The three project interests
Business
Protects the investment and business justification. The Executive represents this interest and is ultimately accountable for the business case within the project.
User
Represents people who will use, operate, maintain or otherwise depend on the products and who are expected to realise benefits. Senior User roles protect this perspective.
Supplier
Represents the specialist capability required to design, build or provide the products. Senior Supplier roles protect technical feasibility and supplier-resource interests.
The defined-roles principle requires all three interests to be represented even when one person holds more than one compatible role on a small project. The value of the model is the perspective, not the job title. A decision about a product should consider whether it remains worthwhile, whether it will meet user needs and whether it can be delivered reliably.
Management levels and accountability
| Level | Core roles | Primary management purpose |
|---|---|---|
| Corporate/programme/customer | Commissioning authority outside the project | Commissions the project, sets project tolerance and receives escalations beyond project-board authority. |
| Directing | Project Board: Executive, Senior User(s), Senior Supplier(s) | Makes key decisions, authorises stages/project/closure, provides direction and remains accountable for project success. |
| Managing | Project Manager | Plans and controls day-to-day project work within the authorised stage and project framework. |
| Delivering | Team Manager(s) and specialist teams | Accept, execute and deliver work packages and provide accurate progress information. |
Project Board
The board contains the Executive, Senior User and Senior Supplier interests. The Executive chairs the board and represents the business interest. Senior Users represent the people who need and use the products and are accountable for specifying benefits and user requirements. Senior Suppliers represent those who provide the specialist resources and expertise needed to produce the products.
The board is a decision-making body, not a committee for day-to-day coordination. Manage by exception allows it to delegate daily management to the project manager while retaining authority for initiation, project authorisation, stage and exception-plan approval, ad hoc direction and closure. An effective board therefore needs the authority, credibility, availability and competence to make those decisions when required.
A board that exists only on an organisation chart but cannot make timely decisions does not provide effective project governance. Members need enough authority to represent their interest and to commit the organisation within the project’s delegated limits.
Project Manager and Team Manager
The project manager is responsible for day-to-day management. This includes planning stages, authorising work packages, monitoring progress, maintaining registers and logs, managing risks and issues within authority, reporting to the board and escalating forecast exceptions. The project manager does not personally need to perform the specialist work; the method expects delegation to teams.
The team manager coordinates one or more work packages. They agree the work with the project manager, prepare or use an appropriate team plan, manage specialist production, ensure specified quality methods are performed, report through checkpoint information and notify the project manager when work-package tolerance is forecast to be exceeded.
| Question | Project Manager perspective | Team Manager perspective |
|---|---|---|
| What is being controlled? | Management stage and project information | One or more authorised work packages |
| Who delegates authority? | Project Board via stage tolerances | Project Manager via work-package tolerances |
| Routine progress output | Highlight information to board; stage-level monitoring | Checkpoint information to project manager |
| Exception interface | Escalates forecast stage/project issues to board | Escalates forecast work-package issues to project manager |
Project Assurance and Project Support
Project assurance provides an independent view, on behalf of project-board interests, that the project is being conducted properly. The source distinguishes this from quality assurance. Project assurance is independent of the project manager but is part of the project; quality assurance is normally an organisational function outside the project and checks compliance with wider quality standards and policies.
Project support, by contrast, assists the project manager and team with administration or specialist tools. Depending on scale, support may maintain registers, configuration records, quality records, reporting systems or planning tools. Project support can be a formal office function or a set of responsibilities performed by individuals.
| Function | Position | Typical focus |
|---|---|---|
| Project Assurance | Inside the project governance structure but independent of the project manager | Business, user and supplier assurance that the project is being managed appropriately. |
| Quality Assurance | Independent organisational function outside the project | Compliance with organisational, programme or customer quality policies and standards. |
| Project Support | Service to the project manager and management team | Administration, tools, records, configuration information and reporting support. |
Combining roles on smaller projects
The source allows roles to be combined when tailoring makes this sensible, but accountability still needs to be clear. Combining roles should not undermine assurance independence or create a situation in which one person approves their own work without an appropriate check. The Executive role cannot simply disappear because the project is small; the business interest and business-case accountability still need a home.
When roles are combined, document the combination in role descriptions or the project initiation baseline. State which responsibilities have moved and how any necessary separation of duties will be preserved. For example, the project manager may also coordinate specialist delivery on a small project, but work packages should still be defined so team-level commitments and tolerances remain visible.
Designing an effective project organisation
Start with decisions rather than titles. List the important decisions the project must make: approve the business case, define benefits, agree product requirements, confirm technical feasibility, authorise stages, accept products, approve change within delegated authority and decide how to respond to exceptions. Then map each decision to a role and confirm that the person filling the role has the authority and information needed to exercise it.
Identify interests
Map business, user and supplier stakeholders.
Define decisions
List the approvals, acceptance decisions and escalation responses the project will need.
Assign roles
Allocate Executive, Senior User, Senior Supplier, Project Manager, Team Manager, assurance and support responsibilities.
Check authority
Confirm role-holders can make the decisions they are expected to own.
Check capacity
Confirm role-holders have enough time and access to information.
Document and communicate
Publish role descriptions and keep the structure current as the project changes.
Role design through decision rights
A practical organisation design exercise begins by listing decisions rather than names. Identify who can approve the Business Case, commit business/user/supplier resources, accept the project product, authorise a stage, approve change within delegated authority, respond to an exception and own benefits after closure. Only then assign people to roles. This exposes situations in which a nominated role-holder lacks the organisational authority required to perform the role.
Also map information paths. Team Managers need a route to the Project Manager for Work Package issues; the Project Manager needs routine access to Board members for ad hoc direction; the Board needs a route to the commissioning authority for project-level exceptions. Project Assurance needs enough independence and access to evidence to provide meaningful challenge. Project Support needs clear responsibilities for records without becoming an unrecognised decision-maker.
Review the structure when suppliers, users or organisational ownership changes. Defined roles and responsibilities are not satisfied by an organisation chart that became obsolete after initiation. Keep role descriptions, delegated authority and escalation routes aligned with the actual people performing the work.
Practical verification checklist
- Represent business, user and supplier interests explicitly in the project organisation.
- Confirm the Executive is accountable for the business case and has sufficient authority.
- Define what Senior Users own for needs, acceptance and benefits.
- Define what Senior Suppliers own for specialist feasibility and supplier capability.
- Give the project manager clear day-to-day authority within stage tolerance.
- Use team-management roles and work packages to separate management of delivery from management of the stage.
- Keep project assurance independent of the project manager and distinguish it from external quality assurance.
- Document any combined roles and check for conflicts or lost independence.
- Keep role descriptions and team structure updated when personnel or project context changes.
Common mistakes to avoid
- Using job titles as a substitute for explicit project roles and decision rights.
- Creating a project board that cannot actually commit resources or make timely decisions.
- Making the project manager accountable for post-project benefits that belong to business/user ownership.
- Confusing project assurance with project support or with independent organisational quality assurance.
- Combining roles on a small project without considering conflicts of interest or assurance independence.
- Allowing external suppliers to operate with no clear project-manager/team-manager interface.