Roles and tailoring across the early processes

Lessons 2 to 10 followed the early processes activity by activity. This lesson looks across them from two angles. First, roles: who is responsible for producing, reviewing and approving each key product of starting up, directing and initiating, and where responsibilities are most often confused. Second, tailoring: how the early processes change for very small projects, agile delivery and projects within programs. PRIN-150 treats tailoring and Practitioner scenarios in depth; here the focus is on the first three processes.

Who does what in the early processes

PRINCE2 assigns responsibilities to roles, not to named people, and it distinguishes several kinds of involvement: producing a product, reviewing it, approving it, and being consulted or informed. Study guides often present these in tables using letters such as P for produces, R for reviews and A for approves. The table below summarizes common practice for the key products of the early processes in our own words. Exact allocations in the official manual may differ in detail, and every project tailors them.

A few patterns stand out. The project manager produces almost everything but approves almost nothing in these processes: approval sits with the executive, often with senior users and senior suppliers for products that commit their resources. Project assurance reviews nearly everything, because its job is to give the board confidence. The business layer appears only at the edges: it provides the mandate, appoints the executive, sets project tolerances and is consulted on the business case and informed of decisions.

Common confusions about roles

In exam questions, these confusions often appear as plausible distractors. A question might ask who is responsible for preparing the outline business case and offer both the executive and the project manager. The usual reasoning is that the executive is responsible, because the executive owns the business case, even though the project manager may help draft it. Read such questions carefully for the distinction between ownership or accountability and the work of producing a document.

Building and checking a RACI matrix

Some organizations express role responsibilities as a RACI matrix: responsible (does the work), accountable (one person who approves and answers for it), consulted and informed. The code below builds a RACI matrix for Ridgeline Water's early products and checks two rules: every product has exactly one accountable role, and no role is both responsible and accountable for the same assurance-sensitive product without a recorded reason.

roles = ["BL", "EX", "SU", "SS", "PM", "PA"]
raci = {
    "Project mandate":          {"BL": "A", "EX": "I"},
    "Team structure":           {"EX": "A", "SU": "C", "SS": "C", "PM": "R", "PA": "C"},
    "Outline business case":    {"BL": "C", "EX": "A", "SU": "C", "SS": "C", "PM": "R", "PA": "C"},
    "Project brief":            {"EX": "A", "SU": "C", "SS": "C", "PM": "R", "PA": "C"},
    "Initiation stage plan":    {"EX": "A", "SU": "C", "SS": "C", "PM": "R", "PA": "C"},
    "Management approaches":    {"EX": "A", "SU": "C", "SS": "C", "PM": "R", "PA": "C"},
    "Project plan":             {"EX": "A", "SU": "A", "SS": "C", "PM": "R", "PA": "C"},
    "PID":                      {"EX": "A", "SU": "C", "SS": "C", "PM": "R", "PA": "C"},
}
print(f"{'Product':24}" + "".join(f"{r:>4}" for r in roles))
for product, m in raci.items():
    print(f"{product:24}" + "".join(f"{m.get(r, '.'):>4}" for r in roles))
problems = []
for product, m in raci.items():
    acc = [r for r, v in m.items() if v == "A"]
    if len(acc) != 1:
        problems.append(f"{product}: {len(acc)} accountable roles ({', '.join(acc)})")
    if m.get("PA") in ("R", "A"):
        problems.append(f"{product}: assurance is producing or approving")
print("Problems:", problems if problems else "none")

Product                   BL  EX  SU  SS  PM  PA
Project mandate            A   I   .   .   .   .
Team structure             .   A   C   C   R   C
Outline business case      C   A   C   C   R   C
Project brief              .   A   C   C   R   C
Initiation stage plan      .   A   C   C   R   C
Management approaches      .   A   C   C   R   C
Project plan               .   A   A   C   R   C
PID                        .   A   C   C   R   C
Problems: ['Project plan: 2 accountable roles (EX, SU)']

The check finds one problem: the project plan has two accountable roles, the executive and the senior user. In the produce, review and approve table above, several board members approve the project plan, because it commits their resources. A RACI matrix forces a single A, so the project should decide whether the executive is accountable with the senior user consulted, or record that board approval is collective with the executive deciding in case of disagreement. Either is acceptable if it is explicit; the danger is two people each thinking the other is accountable.

Tailoring for small projects

On a small, low-risk project, the early processes can be very light. Starting up and initiating might take a few days in total. The project brief and PID might be one document that evolves: a short brief for the decision to initiate, extended with a plan, a few paragraphs on controls and approaches and a refined business case for the decision to authorize. The board might be the executive alone, combining the senior user role, with a supplier representative attending only for key decisions. The decisions still happen: someone with authority decides to invest in initiation and then decides to authorize the project.

Tailoring for agile delivery

In agile environments, the early processes still provide governance, but their products look different. The project product description may be expressed as a product vision and goals, with acceptance criteria focused on outcomes rather than detailed features. The project plan may be a release roadmap. Management stages may align with groups of releases or a fixed number of sprints. Scope is often the flexed performance target, while time and cost are fixed by tolerances. The initiation stage typically produces an initial backlog, a definition of done, team working agreements and a release plan, alongside the business case and controls the board needs.

The danger in agile settings is to skip starting up and initiation in the name of speed. Without a deliberate decision to invest, without a business case and without agreed tolerances, an agile team can deliver features efficiently for months without anyone checking whether the project is still worth doing. The early processes, scaled down, are what give agile delivery its governance.

Tailoring within a program

When a project is part of a program, the program provides much of what starting up would otherwise create. The program's project brief or project definition may serve as the mandate and much of the project brief. The program may appoint the executive, define the business case's contribution to program benefits, provide management approaches through program standards and set project tolerances. The project's starting up becomes a short confirmation exercise, and initiation focuses on what is specific to the project. Benefits are usually managed and reviewed by the program rather than the project.

In the Canadian federal context, projects within programs follow Treasury Board's policy framework and departmental project management standards, which define approval gates that a PRINCE2 project would map to its stage boundaries, and provincial governments have comparable frameworks.

Role descriptions in practice

Role descriptions are the practical tool that turns the responsibility tables into agreed commitments. A useful role description for an early-process role is short and specific to the project: it names the role holder, states what they will produce, review or approve, gives an estimate of the time required in each stage, states any limits on their authority, and records their agreement. Copying the generic PRINCE2 role description into every appointment letter tells the role holder very little.

Tailored role descriptions also make later disagreements easier to settle. If, during the pilot, the billing manager is asked to release staff she had not expected to provide, the role description shows what was agreed. If the commitment needs to grow, that is a change to the plan and to her commitments, handled openly rather than through informal pressure.