Project roles as people

PRIN-110 covered the principle of defined roles, responsibilities and relationships: why every project needs the business, user and supplier interests represented, which roles may be combined and why accountability must be clear. This lesson looks at the same roles from the other side. Roles are filled by real people, with their own skills, workloads, ambitions and blind spots. A perfectly drawn organization chart achieves nothing if the executive never has time for the project, the senior user lacks credibility with the users, or the project assurance role is held by someone who reports to the project manager. Here we look at how to choose, prepare and support the people who hold PRINCE2 roles.

The project management team in people terms

The project management team includes the project board, the project manager, team managers, project assurance, project support and, where used, a change authority. Each role demands not just a set of responsibilities but particular personal qualities. The table below summarizes what to look for when the role is filled.

Choosing board members

Experienced practitioners often summarize what a good board member needs in four words: authority, credibility, ability to delegate and availability. Authority means having the power in the permanent organization to make the decisions the role requires, such as committing budget or staff. Credibility means being respected by the people the role represents, so that decisions are accepted. Ability to delegate means being willing to let the project manager manage within tolerances rather than interfering. Availability means having enough time to attend board meetings, review reports and respond to exceptions promptly.

Availability is the quality most often missing. Senior managers are busy, and project board duties compete with operational responsibilities. A board member who misses meetings or takes two weeks to respond to an exception report slows the project and undermines management by exception. When availability is a concern, it is better to raise it openly at the start and agree realistic arrangements, such as fewer but well-prepared meetings or a clearly authorized deputy, than to appoint someone who cannot fulfill the role.

Onboarding the board

Many board members have never been trained in PRINCE2 or in project governance generally. They may expect to be kept informed rather than to make decisions, or they may expect to manage the project themselves. A short onboarding session at the start of initiation pays for itself many times over. It should explain what the board is accountable for, how management by exception works, what tolerances mean, what reports they will receive, what decisions they will be asked to make and how quickly. Role descriptions, written in plain language and tailored to the project, give each board member something to refer back to.

Users beyond the senior user

The senior user role represents the users, but one person rarely knows everything users need. Good projects involve wider user representatives in specifying requirements, defining quality criteria, reviewing products and testing. PRINCE2 7 emphasizes co-creation: building products with users rather than for them. Co-creation improves the fit of products, reduces late surprises and builds the ownership that makes adoption easier. The senior user should agree who these representatives are, make sure they have time released from their normal work and make sure their views are fed back to the board.

A practical warning: user representatives who are seconded full time to a project for many months can lose touch with day-to-day operations and become, in effect, part of the project team. Rotating representatives, or combining a small core group with a wider network of occasional reviewers, helps keep the user voice authentic.

Project assurance as a people role

Project assurance monitors the project on behalf of the board, checking that it remains viable, that the users' needs are being met and that products are of the required quality. Each board member is responsible for assurance of their own interest, and may appoint others to carry out assurance on their behalf. In people terms, assurance only works if it is independent of the project manager and trusted by both the board and the project team. Assurance providers who behave like auditors, appearing only to criticize, push the team into defensive behavior. Those who behave like critical friends, raising concerns early and helping solve them, strengthen the project.

Mapping organizational roles to PRINCE2 roles

Most organizations already have their own role titles: sponsor, steering committee, product owner, delivery lead, business analyst, quality manager. PRINCE2 does not ask organizations to rename everyone. It asks them to make sure the PRINCE2 responsibilities are held by someone. A simple mapping table clarifies who holds which PRINCE2 role and avoids gaps and overlaps.

Note the care needed with the product owner. In agile terms the product owner prioritizes the backlog and accepts work. In PRINCE2 terms that looks partly like the senior user and partly like a team-level role. The right mapping depends on authority: if the product owner can commit user resources and accept products on behalf of users, they may act as senior user; if not, they are better treated as a user representative reporting to the senior user.

Role clarity and role conflict

Two people problems recur on projects. Role ambiguity arises when people do not know what is expected of them. Role conflict arises when people face incompatible expectations, for example a team member whose line manager wants them on operational work while the team manager wants them on the project. Both cause stress and reduce performance. Clear role descriptions, agreed with each person and with their line manager, reduce ambiguity. Explicit agreements about time allocation, recorded in the plan and supported by the senior user or senior supplier, reduce conflict.