Table of Contents

Organisational Structure

The organisational structure of a project, programme, or PMO determines how decisions are made, how information flows, and how effectively teams work together. Getting the structure right is a critical enabler of delivery success.

Why Structure Matters

Key Principle: Structure follows strategy. The right organisational structure depends on what you are trying to deliver, the culture of the host organisation, and the complexity of the change.

A well-designed structure:

  • Clarifies decision-making authority and accountability
  • Enables efficient communication and escalation
  • Aligns resources to delivery priorities
  • Provides clear reporting lines and governance
  • Reduces duplication and confusion
  • Supports effective stakeholder engagement

Types of Organisational Structure

Organisations typically adopt one of three structural models, each with different implications for project delivery.

Comparison of Structural Models

Characteristic Functional Matrix Projectised
Authority of PM Low Moderate to High High
Resource availability Low Moderate High
Budget control Functional Manager Shared Project Manager
PM role Part-time, coordinator Part-time to full-time Full-time
Admin support Part-time Part-time to full-time Full-time
Team location Within functions Mixed Co-located or dedicated

Functional Structure

In a functional structure, staff are grouped by specialism (e.g., IT, Finance, HR). Projects are delivered within functional silos.

Advantages:

  • Clear line management and career paths
  • Deep specialist expertise within functions
  • Stable team structures

Disadvantages:

  • Cross-functional projects are difficult to coordinate
  • Project managers have limited authority
  • Resource conflicts between project and BAU work

Matrix Structure

A matrix structure overlays project teams across functional departments. Staff report to both a functional manager and a project manager.

flowchart LR A[Executive
Sponsor] --> B[Functional
Manager A] A --> C[Functional
Manager B] A --> D[Project
Manager] B --> E[Team
Member 1] C --> F[Team
Member 2] D --> E D --> F classDef blue fill:#108BB9,stroke:none,color:#fff class A,B,C,D,E,F blue

Types of matrix:

Matrix Type PM Authority Resource Control Best For
Weak matrix Low Functional manager controls Small projects within a function
Balanced matrix Shared Negotiated between PM and functional manager Medium-complexity projects
Strong matrix High PM has primary control Large, cross-functional projects

Projectised Structure

In a projectised organisation, teams are formed specifically for the project and report directly to the project manager. Resources are fully dedicated.

Advantages:

  • Clear authority and accountability
  • Dedicated resources with no competing priorities
  • Faster decision-making

Disadvantages:

  • Inefficient use of specialists across projects
  • Team members face uncertainty at project end
  • Knowledge can be lost when teams disperse

Choosing the Right Structure

flowchart LR A{Project
Complexity?} -->|Low| B{Cross-functional?} A -->|High| C[Strong Matrix
or Projectised] B -->|No| D[Functional] B -->|Yes| E[Weak or
Balanced Matrix] classDef blue fill:#108BB9,stroke:none,color:#fff class A,B,C,D,E blue

Consider the following factors when selecting a structure:

Factor Favours Functional Favours Matrix Favours Projectised
Project size Small Medium Large
Duration Short Medium Long
Complexity Low Medium High
Strategic importance Low Medium High
Cross-functional dependency Low High High
Resource availability Shared acceptable Some dedication Full dedication needed

Project Team Structure

A typical project team structure includes the following roles and layers.

Core Project Roles

Role Accountability Reports To
Senior Responsible Owner (SRO) Overall accountability for the project outcome Executive Board
Project Sponsor Secures funding, removes barriers, champions the project SRO or Executive
Project Manager Day-to-day delivery, planning, reporting Sponsor or SRO
Business Change Manager Ensures the organisation can adopt the change SRO or Sponsor
Technical Lead Technical design, build, and quality Project Manager
Business Analyst Requirements, analysis, process design Project Manager
Test Manager Test strategy, planning, and execution Project Manager
Team Members Specialist delivery tasks Project Manager or Team Lead
Common Mistake: Combining the Sponsor and SRO roles, or making the Project Manager accountable for business change. Keep these roles separate to maintain proper checks and balances.

Programme Structure

Programmes require additional structural layers to coordinate multiple projects and manage benefits realisation.

Programme Roles

Role Accountability
Programme Director Strategic leadership of the programme
Programme Manager Day-to-day management and coordination of projects
Business Change Manager(s) Transition management and benefits realisation
Programme Office Standards, reporting, resource coordination
Project Managers Delivery of individual projects within the programme
Design Authority Technical coherence across projects

Programme Governance Layers

Layer Forum Purpose Frequency
Strategic Programme Board Direction, funding, major decisions Monthly
Management Programme Team Meeting Coordination, dependency management Weekly or fortnightly
Delivery Project Boards Individual project governance As defined per project
Assurance Assurance Reviews Independent scrutiny At stage gates or quarterly

PMO Positioning

The Project Management Office (PMO) can sit at different levels in the organisation, each serving different purposes.

PMO Type Scope Function Authority
Project Office Single project Admin support, reporting, scheduling Low
Programme Office Programme Standards, resource coordination, reporting Medium
Enterprise PMO Organisation-wide Portfolio governance, capability, methodology High
Centre of Excellence Organisation-wide Best practice, training, maturity improvement Advisory
Best Practice: The PMO should have a clear mandate. An under-empowered PMO becomes an admin function; an over-empowered PMO can become a bottleneck. Define the PMO's authority in its terms of reference.

RACI for Governance

A RACI matrix clarifies roles and responsibilities across governance activities. Assign one of four levels to each role per activity:

Letter Meaning Description
R Responsible Does the work
A Accountable Ultimately answerable (one person only)
C Consulted Provides input before the work is done
I Informed Notified after the work is done

Example RACI

Activity SRO Sponsor PM BCM Team
Approve business case A R C C I
Manage day-to-day delivery I I A/R I R
Approve stage gate A R C C I
Manage benefits realisation I C I A/R I
Manage risks and issues I C A/R C R
Stakeholder engagement C A R R I
Rule: There must be exactly one "A" per row. If accountability is shared, no one is truly accountable.

Governance Boards

Board Design Principles

  • Clear terms of reference – purpose, authority, membership, quorum, frequency
  • Decision rights – what the board can approve and what must be escalated
  • Right membership – senior enough to make decisions, not so senior that attendance drops
  • Regular cadence – predictable rhythm that aligns with reporting cycles
  • Documented decisions – all decisions recorded in minutes and a Decision Log

Typical Governance Hierarchy

flowchart LR A[Portfolio Board] --> B[Programme Board] B --> C[Project Board] C --> D[Working Groups] classDef blue fill:#108BB9,stroke:none,color:#fff class A,B,C,D blue

Team Sizing

Research and experience suggest practical limits for team sizing.

Guideline Size Rationale
Scrum team 5-9 people Optimal for agile delivery; beyond this, communication overhead increases
Span of control 5-7 direct reports Manageable workload for a single line manager
Project core team 8-12 people Enough expertise without excessive coordination
Programme team 3-7 project managers One programme manager can effectively coordinate this many workstreams
Brooks' Law: Adding people to a late project makes it later. Communication overhead grows exponentially with team size. Consider this before scaling up.

Common Structural Problems and Solutions

Problem Symptoms Solution
Unclear accountability Decisions not made, blame culture Define RACI, clarify terms of reference
Too many reporting lines Conflicting priorities, confused teams Simplify structure, establish single point of accountability
Missing Business Change Manager Change not adopted, benefits not realised Appoint a dedicated BCM with authority
Sponsor not engaged Blockers unresolved, no air cover Escalate or replace; agree minimum time commitment
PMO without authority Standards ignored, reporting inconsistent Strengthen PMO mandate in governance framework
Siloed teams Poor communication, duplicated effort Introduce cross-functional forums, shared tools, and integrated planning
Overly complex governance Slow decisions, meeting fatigue Simplify layers, delegate authority, reduce meeting frequency
No Design Authority Inconsistent technical decisions Establish a Design Authority with clear remit

Structure Checklist

Criteria Yes / No
The project or programme has a defined organisational structure  
All key roles are filled with named individuals  
A RACI matrix exists and has been agreed  
Terms of reference exist for all governance boards  
Reporting lines are clear and documented  
The structure matches the complexity and scale of the initiative  
The PMO has a clear mandate and appropriate authority  
Team sizes are manageable with appropriate spans of control  
There is a single point of accountability for the overall outcome  
Last updated: 19 March 2026