The organizing practice I: the project management team

The purpose of the organizing practice is to define and establish the project's structure of accountability and responsibilities, the who of the project. A project brings together people from different parts of an organization, and often from several organizations, for a limited time. Without a deliberately designed structure, decisions stall because nobody knows who can make them, or they are made by people without the authority or knowledge to make them well. The organizing practice prevents both failures by setting out roles, their responsibilities and the relationships between them.

PRIN-110 covered the principle of defined roles, responsibilities and relationships, and PRIN-120 covered roles as people: choosing role holders, onboarding them and supporting them. This lesson and the next focus on the structure itself: the levels of management, the roles in the project management team, what each is responsible for, how assurance and support fit in, and how the structure is documented. Lesson 6 then covers combining roles, delegation, change authority and communication.

Three interests on every project

PRINCE2 starts from the view that every project has three primary interests, which must all be represented in decision-making. The business interest asks whether the project is value for money. The user interest asks whether the products will meet the needs of those who will use them and enable the benefits. The supplier interest asks whether the products can be delivered with the resources and skills available. A project board that represents only one or two of these interests will make decisions with a blind spot.

Suppliers may be internal or external. Ridgeline Water's billing integration is delivered by its own IT team, so the IT manager is a senior supplier alongside the external meter supplier. A project can have more than one senior user or senior supplier, but PRINCE2 strongly favours a single executive, so that one person is accountable for the business case and the final decision.

Levels of management

The organizing practice places the project management team within the four layers discussed in PRIN-120: the business layer, which commissions the project and sets project tolerances; directing, the project board; managing, the project manager; and delivering, the team managers and their teams. Each level manages within the tolerances set by the level above and escalates when those tolerances are forecast to be exceeded.

The diagram shows reporting lines, not seniority. The project manager reports to the board, not to any one board member, and team managers report to the project manager for the work in their work packages, even if they belong to a supplier company with its own management chain. The dotted lines for project assurance and change authority show that these roles support the board but do not sit in the line of command between board and project manager.

The project board

The project board is accountable for the success of the project within the remit set by the business layer. It approves the project and each stage, sets stage tolerances, decides on exceptions, provides direction and resources, and authorizes closure. It does not manage the project day to day; that is the project manager's job. PRINCE2 calls this management by exception: the board directs through decisions at key points and through tolerances, rather than through constant involvement.

Board members need authority, credibility, the ability to delegate and enough availability, as PRIN-120 discussed. A useful test for each board member is whether they could commit their part of the organization to a decision in the meeting. If the senior user must go back to their director before agreeing to release staff for training, the wrong person is in the role.

The project manager and team managers

The project manager runs the project day to day on behalf of the board, within the stage tolerances. Their responsibilities include planning, delegating work packages to team managers, monitoring progress, managing risks and issues, reporting to the board and preparing the management products. The project manager is responsible for delivering the project's products to the required quality, within cost and time, and for ensuring the products are capable of achieving the benefits.

Team managers are responsible for producing the products allocated to them in work packages, to the agreed quality, time and cost, and for reporting progress through checkpoint reports. The team manager role is optional in the sense that on small projects the project manager may manage the team directly; on larger projects, and particularly where suppliers deliver products, team managers are essential.

Note the customer change team. Lesson 4 showed that most of the benefits depend on customers responding to leak alerts. Making that work a team manager's explicit responsibility, with its own work package and products, is the organizing practice responding to what the business case revealed.

Project assurance

Project assurance is the board's own means of checking that the project is being conducted properly. Each board member is responsible for assurance of their interest: business assurance for the executive, user assurance for the senior user and supplier assurance for the senior supplier. Board members may do this themselves or appoint people to carry it out. Assurance must be independent of the project manager; the project manager cannot assure their own work.

Project assurance is different from quality assurance. Quality assurance is an independent check by the wider organization that the project's direction and management are adequate and that organizational standards are followed; it is outside the project management team. Project assurance belongs to the board and is part of the team. PRIN-131 covers quality assurance in the quality practice.

Project support

Project support provides administrative services and guidance to the project: configuration management, record keeping, maintaining registers and logs, supporting meetings and helping with planning tools. In larger organizations, a project office or portfolio office may provide project support to several projects. Project support may be combined with the project manager role on small projects, but it should not be combined with project assurance, because assurance must be independent of those it checks.

Accountable, responsible and consulted

Many organizations describe roles using a responsibility assignment matrix, often called a RACI chart: who is responsible for doing a task, who is accountable for it, who must be consulted and who must be informed. PRINCE2 describes roles through responsibility descriptions rather than a RACI chart, but the two can be used together. What matters most is that every key decision has exactly one accountable role.

roles = ["Exec", "SU", "SS", "PM", "Assur", "Supp"]
decisions = {
    "approve business case":     {"Exec": "A", "PM": "R", "SU": "C", "SS": "C", "Assur": "C"},
    "specify benefits":          {"SU": "A", "PM": "R", "Exec": "C", "Assur": "C"},
    "approve stage plan":        {"Exec": "A", "SU": "C", "SS": "C", "PM": "R", "Assur": "C"},
    "accept a product":          {"SU": "A", "SS": "C", "PM": "R"},
    "approve work package":      {"PM": "A", "SS": "C"},
    "maintain issue register":   {"Supp": "R", "PM": "A"},
    "approve minor change":      {},
}
print("decision".ljust(26) + " ".join(r.ljust(5) for r in roles))
for d, m in decisions.items():
    print(d.ljust(26) + " ".join(m.get(r, "-").ljust(5) for r in roles))
print()
for d, m in decisions.items():
    n = list(m.values()).count("A")
    if n != 1:
        print(f"problem: '{d}' has {n} accountable roles")

decision                  Exec  SU    SS    PM    Assur Supp 
approve business case     A     C     C     R     C     -    
specify benefits          C     A     -     R     C     -    
approve stage plan        A     C     C     R     C     -    
accept a product          -     A     C     R     -     -    
approve work package      -     -     C     A     -     -    
maintain issue register   -     -     -     A     -     R    
approve minor change      -     -     -     -     -     -    

problem: 'approve minor change' has 0 accountable roles

The check finds one gap: nobody is accountable for approving minor changes. In PRINCE2 terms, that gap is exactly what the change authority role addresses: the board may delegate authority for approving changes within limits to a change authority, or keep it itself. Lesson 6 explains how. The matrix also shows that the executive is accountable for the business case while the project manager is responsible for preparing it, which is the distinction lesson 2 made.

Documenting the organization

The project management team structure and role descriptions are documented during starting up and confirmed during initiation, as part of the project initiation documentation. Role descriptions should be tailored to the project: generic descriptions copied from a template, with no mention of the project's products, suppliers or risks, are a warning sign. The structure is reviewed at each stage boundary, because the right team for design may not be the right team for rollout.