The organizing practice II: role combinations, delegation and change authority

Lesson 5 described the roles in a PRINCE2 project management team. In practice, few projects have a different person for every role. Small projects combine roles; large projects split them among several people and delegate parts of them. Both are legitimate tailoring, provided the combinations do not create conflicts of interest and the accountability that each role carries remains clear. This lesson looks at which combinations work, how delegation operates within the structure, how authority for changes is handled through the change authority, and how the structure supports communication.

Roles are not jobs

A PRINCE2 role is a set of responsibilities, not a job title or a full-time position. One person can hold several roles, and one role can be shared among several people. The executive of a small project might spend an hour a fortnight in the role; the project manager of a large one might work full time on it with a team of assistants. Thinking of roles as bundles of responsibilities makes it easier to tailor the organization without losing anything essential.

Which roles can be combined

Some combinations are common and sensible; others create conflicts of interest that undermine the checks the structure provides. The principle is that a person should not be in a position to check, approve or accept their own work, and that the three board interests should each have a voice. The following summary reflects general PRINCE2 guidance; the official manual should be consulted for the authoritative wording.

The code below encodes these rules and checks a proposed set of role assignments for a small project. Encoding rules like this is not part of PRINCE2, but it is a quick way for a project office to check many projects consistently.

forbidden = {
    frozenset({"PM", "Exec"}), frozenset({"PM", "SU"}), frozenset({"PM", "SS"}),
    frozenset({"PM", "Assurance"}), frozenset({"Support", "Assurance"}),
}
care = {frozenset({"Exec", "SS"})}

def check(assignments):
    by_person = {}
    for role, person in assignments.items():
        by_person.setdefault(person, []).append(role)
    ok = True
    for person, held in by_person.items():
        for i, a in enumerate(held):
            for b in held[i + 1:]:
                pair = frozenset({a, b})
                if pair in forbidden:
                    print(f"NOT ALLOWED: {person} holds {a} and {b}")
                    ok = False
                elif pair in care:
                    print(f"check carefully: {person} holds {a} and {b}")
    print("structure acceptable" if ok else "structure needs changes")

proposal = {"Exec": "Dana", "SU": "Dana", "SS": "Lee", "PM": "Sam",
            "Support": "Sam", "Assurance": "Sam"}
check(proposal)
print("--- revised")
proposal["Assurance"] = "Priya"
check(proposal)

NOT ALLOWED: Sam holds PM and Assurance
NOT ALLOWED: Sam holds Support and Assurance
structure needs changes
--- revised
structure acceptable

The first proposal fails because Sam, the project manager, would also carry out assurance; the checker flags it twice, once against the project manager role and once against project support. Combining executive and senior user in Dana, and project manager and support in Sam, is fine for a small project. Moving assurance to Priya, who is independent of Sam, fixes the structure. In a real project, Priya might be a colleague from the finance or audit team who spends a few hours per stage on assurance reviews.

Delegation within the structure

PRINCE2 relies on delegation through tolerances. The business layer delegates to the board within project tolerances; the board delegates to the project manager within stage tolerances; the project manager delegates to team managers within work package tolerances. Each level can act freely within its tolerances and must escalate when they are forecast to be exceeded. This allows senior people to spend their time on genuine decisions rather than on detail.

Board members can also delegate their assurance responsibilities and, within limits, some of their authority. A senior user who cannot attend every quality review may appoint user representatives to review products on their behalf. What cannot be delegated is accountability: the senior user remains accountable for the user interest even if others do the work.

Change authority

Every project faces requests for change: to products, scope, requirements or approach. PRIN-131 covers how changes are assessed and controlled through the issues practice. The organizing practice establishes who has authority to approve them. By default, the project board approves changes. On projects with many changes, the board may delegate authority for approving changes within defined limits to a change authority, which might be the project manager, a board member, or a small group. The board sets the limits, usually expressed as a change budget and rules on the size of individual changes.

Delegating change authority is a trade-off. If the board approves every small change, decisions are slow and senior time is wasted. If the change authority's limits are too generous, the project can drift away from its approved scope through a series of individually small changes. A change budget, which is money set aside to fund approved changes, makes the limit concrete and visible.

Communication and the structure

The organization defines formal communication channels as well as authority. The board receives highlight reports from the project manager at agreed intervals and exception reports when tolerances are threatened. The project manager receives checkpoint reports from team managers. The business layer receives reports from the board as agreed. PRIN-120 covered the communication management approach, which describes how the project communicates with stakeholders beyond the project management team; the organizing practice ensures the internal reporting lines match the structure of authority.

A structure in which reports flow but decisions do not is a common failure. If the board receives highlight reports but never acts on the risks they contain, or if team managers send checkpoint reports that nobody reads, the structure exists only on paper. A quick test is to ask, for each report, what decision it supports and whether that decision is being made.

Multi-organization projects

When customers and suppliers are different organizations, the organizing practice must reflect the commercial relationship. The senior supplier may be from the supplier company, and the project may have two project managers, one on each side, with clearly defined responsibilities. PRIN-120 covered customer–supplier relationships and contract types. From the organizing point of view, the key is that the contract and the PRINCE2 roles are aligned: the person who approves a change in the project should be someone who can also commit the supplier contractually, or the change process must include the contract owner.

Public-sector projects in Canada often add governance layers such as departmental project review committees or, for municipal projects, council committees. These usually sit in the business layer and should be reflected in project tolerances and escalation routes rather than added as extra board members.