Define roles, responsibilities and relationships

The third principle states that a PRINCE2 project has defined and agreed roles and responsibilities within an organization structure that engages the business, user and supplier stakeholder interests. PRINCE2 7 extended the wording to include relationships. A perfect organization chart is useless if the people in it do not talk to each other, trust each other or understand each other's pressures. This lesson looks at the structure the principle requires, the authority that goes with each role and the relationships that make the structure work.

Three interests, always

Every project involves three primary stakeholder interests.

• The business interest needs the project to deliver value for money. It is represented by the executive, who owns the business case and has the final say on the project board.
• The user interest covers those who will use the project's products, operate and maintain them, or be affected by them. It is represented by one or more senior users, who specify what is needed and are accountable for realizing benefits.
• The supplier interest covers those who provide the expertise, resources and skills to build the products. It is represented by one or more senior suppliers, who commit supplier resources and are accountable for the quality of what is delivered.

The three interests are not always in harmony. Users want more features; the business wants lower cost; suppliers want clear requirements, realistic timescales and to be paid. Bringing all three to the same table, with defined authority, is how PRINCE2 turns those tensions into decisions rather than conflict.

Four levels of management

The principle defines who does what across four levels.

Three supporting roles complete the structure. Project assurance checks, on behalf of the board members, that the project is being run properly and that the business, user and supplier interests are protected. Assurance is independent of the project manager. The change authority is a person or group delegated by the board to approve changes within agreed limits. Project support provides administrative help, configuration management and tools.

Roles are not jobs

A PRINCE2 role is a set of responsibilities, not a job title. One person can hold more than one role, and one role can be shared by several people, with some limits. On a small project the executive and senior user might be the same person. The project manager might also act as team manager. What PRINCE2 does not allow is combining roles in a way that removes accountability or independence. The executive role cannot be shared: there must be one person ultimately accountable. The project manager and executive roles should not be combined, because the person who approves the work should not be the person who manages it day to day. Project assurance should not be held by the project manager, because assurance is meant to be independent.

Responsibility, accountability and authority

Defining roles means more than listing names. It means agreeing who is responsible for doing something, who is accountable for its outcome, who must be consulted and who must be kept informed. A RACI matrix is a common tool for this. PRINCE2 does not require one, but many projects use it to make the principle concrete.

Look again at the final check. A decision with two accountable people effectively has none, because each can assume the other will act. A decision with nobody accountable will drift until it becomes an issue.

Relationships make the structure work

PRINCE2 7 places much more emphasis on people than earlier editions, and the addition of relationships to this principle reflects that. A board whose members meet only at stage boundaries and do not trust each other will make slow, defensive decisions. A project manager who sees the senior supplier as an adversary will get less information early. Relationships are built by regular contact, honest communication, keeping commitments and understanding what each party needs.

Practical ways to build relationships include a kick-off workshop at initiation where board members agree how they will work together, short informal check-ins between stage boundaries, shared risk workshops with the supplier, and a communication management approach that sets out who needs what information and how often. The communication management approach is part of the project initiation documentation, and it is one of the clearest pieces of evidence that this principle is being applied.

Board composition and size

An effective project board is small enough to make decisions and senior enough to commit resources. A board of three to five people is typical. Large boards with many senior users from different departments slow decisions; one remedy is to create a user group that feeds a single senior user, or to appoint a lead senior user. Board members also need enough authority. A senior user who cannot commit staff time to testing, or a senior supplier who cannot commit the supplier's resources, is a sign that the role is filled by the wrong person.

Roles in commercial relationships

When the supplier is an external company, the principle becomes more complex. The customer and supplier each have their own organizations, management and commercial interests. PRINCE2 assumes a customer-supplier environment and recognizes that the supplier may run its own project, possibly using a different method. The senior supplier on the customer's board may be a representative of the supplier company, or the customer may appoint an internal senior supplier who manages the commercial relationship. The contract, the work package descriptions and the communication approach together define the relationship. Lesson 9 returns to commercial contexts.

Failure modes

Role descriptions and acceptance

Defining roles is only useful if the people in them understand and accept their responsibilities. PRINCE2 provides outline role descriptions that organizations adapt. During initiation, the project manager should confirm each role with the person who holds it, including what they will decide, how much time they will need and what authority they have. A senior user who does not realize they will need to make staff available for testing, or an executive who expects the project manager to make investment decisions, will cause problems later. A short conversation at the start, recorded in the project initiation documentation, prevents many of them.

Time commitment deserves particular attention. Board members are usually senior people with other responsibilities. A project that needs a decision every week from a board that can meet only monthly will stall. Estimating the board's time, for stage boundary reviews, exception handling and assurance, and agreeing it in advance, is part of applying this principle.

Project assurance in practice

Project assurance is often misunderstood. It is not quality assurance of the specialist products, though it may check that quality methods are being followed. It is the board's own independent view of whether the project is being run properly. Each board member is responsible for assurance of their interest: the executive for business assurance, the senior user for user assurance and the senior supplier for supplier assurance. They may do it themselves or delegate it to others, such as a finance analyst, a user representative or a technical architect. What they cannot do is delegate it to the project manager.

Good assurance asks questions such as: are the business case figures based on realistic estimates? Do the product descriptions reflect what users actually need? Are the technical solutions feasible and are quality methods appropriate? Are risks being managed rather than just listed? Assurance that only reads highlight reports, without checking evidence, adds little.

When relationships break down

Sometimes relationships deteriorate despite good intentions. A supplier misses deadlines and the customer loses trust; a senior user feels ignored and stops attending; the executive and project manager disagree about how to report a problem. The principle suggests a few responses: make the disagreement explicit rather than letting it fester; return to the agreed roles and authority; use the board to resolve conflicts between interests; and, where necessary, change who holds a role. Changing a board member is a legitimate decision when the current holder cannot provide the authority or commitment the role needs.