Study guide
19.2 Organisational Breakdown Structure and RACI
APM Project Management Qualification PMQ
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Exam Format & Question Types 1.3 How to Study for APM PMQ
2 Life Cycles
2.1 Linear Life Cycles and Why Work Is Phased 2.2 Iterative and Hybrid Life Cycles 2.3 Project Life Cycles and Extended Life Cycles 2.4 Choosing a Life Cycle: Context, Culture, Strengths and Limitations
3 Governance Arrangements
3.1 Functional, Matrix and Projectised Structures 3.2 Governance Frameworks, Policies and Delegated Responsibility 3.3 Life-Cycle Impact on Governance and Limits of Financial Authority 3.4 Project Roles and Responsibilities 3.5 Project Manager and Project Sponsor Through the Life Cycle 3.6 Linking Projects to Organisational Objectives
4 Sustainability
4.1 Sustainability Responsibilities, Principles and Impact 4.2 Monitoring and Reporting Sustainability Measures
5 Business Case
5.1 Business Case Fundamentals and Analysis Tools 5.2 The Business Case as Baseline and Reviewing Change
6 Procurement
6.1 Procurement Strategy: Purpose and Contents 6.2 Supplier Selection and Negotiation 6.3 Features of Different Contractual Relationships 6.4 Supplier Reimbursement Methods
7 Reviews & Assurance
7.1 Reviews, Decision Gates, Benefits Reviews and Audits 7.2 What Gets Reported and Informing Decisions 7.3 Why Activities Are Re-Planned After a Review 7.4 Project Assurance
8 Transition & Benefits Management
8.1 Transition Requirements and Business-as-Usual Readiness 8.2 Knowledge Transfer and Agreeing the Transition Plan 8.3 Benefits Management: Identification to Realisation 8.4 Aligning and Communicating Benefits
9 Stakeholder Engagement & Communication
9.1 Stakeholder Analysis, Influence and Engagement 9.2 The Communication Management Plan and Its Benefits 9.3 Managing Stakeholder Expectations 9.4 Communication Methods and Tailoring the Message 9.5 Factors That Help and Hinder Communication
10 Conflict Resolution
10.1 Sources and Impacts of Conflict 10.2 Addressing Conflict and the Thomas-Kilmann Model
11 Leadership
11.1 Leadership, Motivation and Team Performance 11.2 Changing Leadership Styles for the Situation 11.3 Coaching, Mentoring and Emotional Intelligence
12 Team Management
12.1 Team Development Stages and Models 12.2 Characteristics and Benefits of Effective Teams 12.3 Leading Virtual and Hybrid Teams
13 Diversity & Inclusion
13.1 Diversity Characteristics and the Equality Act 13.2 Incorporating Diversity and Diverse Thinking 13.3 Conscious and Unconscious Bias and Fair Treatment
14 Ethics, Compliance & Professionalism
14.1 Continuing Professional Development and Competence 14.2 Sources of Specialist Advice and Standards 14.3 The Legal and Regulatory Landscape
15 Requirements & Solutions
15.1 Establishing Scope Through Requirements Management 15.2 Managing Scope Through Configuration Management 15.3 Solutions Development and Prioritisation
16 Quality Management
16.1 Quality Planning, Indicators and the Business Case 16.2 Quality Control and Success Criteria
17 Integrated Planning
17.1 The Integrated Project Management Plan: Format and Contents 17.2 Why an Integrated Plan Matters
18 Schedule Management
18.1 Defining Scope and Breakdown Structures 18.2 Dependencies and What Drives the Schedule 18.3 Re-Estimating and Schedule Optimisation
19 Resource Management
19.1 Determining Resource Requirements and Availability 19.2 Organisational Breakdown Structure and RACI 19.3 Categorising and Allocating Resources 19.4 Resource Smoothing and Resource Levelling
20 Budgeting & Cost Control
20.1 Creating a Budget and Cost Types 20.2 Earned Value and Cost Forecasting 20.3 Monitoring and Reporting Financial Performance 20.4 Closing Down Project Finances
21 Risk & Issue Management
21.1 Benefits of Risk and Issue Management and Contingency Planning 21.2 The Risk and Issue Management Processes 21.3 Proactive and Reactive Risk Responses 21.4 Governance in Risk and Issue Management
22 Change Control
22.1 The Change Control Process and Its Stages 22.2 What a Change Request Must Capture 22.3 Assessing Options and the Impact of a Change 22.4 Recommending Decisions and Updating Plans
19.2 Organisational Breakdown Structure and RACI
Key Takeaways Explain This Topic AI
The organisational breakdown structure decomposes who is available; crossing it with the work breakdown structure produces the responsibility assignment matrix.
Responsible means does the work; accountable means answers for the outcome; consulted means two-way input; informed means one-way notification.
Each work package must have exactly one accountable person — multiple accountabilities mean nobody is accountable.
Common errors include no accountable role, several accountable roles, over-consultation that stalls decisions, and a matrix never updated after the team changes.
A RACI is only useful if the named people have seen it and accept the roles it assigns them.
Last updated: August 2026
Outcome 21b is precise about the relationship: understand how an organisational breakdown structure is used to create a responsibility assignment matrix (RACI) . The mark is in the word used to create — the OBS and the WBS are the two inputs, and the RACI is what falls out when you cross them.
Organisational breakdown structure (OBS)
An organisational breakdown structure (OBS) is a hierarchical model of the organisation that will deliver the project — roles, teams, functions, suppliers, and sometimes governance bodies — used to show who exists to take work and accountability.
OBS feature Description
Hierarchy From sponsor/board or PMO down through project manager, workstream leads, teams, and key suppliers as appropriate
Roles not only names Enduring role boxes (Design Lead) with named incumbents where known
Project vs functional lines In matrix organisations, OBS may show project structure while functional managers still own staff development and often allocation
- External parties Critical suppliers or partners appear where they hold delivery responsibility
- Link to WBS OBS provides the "who" side of the responsibility matrix; WBS provides the "what"
- Why OBS matters
Visibility of delivery organisation — gaps in roles become obvious (no test lead, no commercial manager).
Basis for RACI — you cannot assign accountability to work if the organisation model is undefined.
Resource ownership — clarifies whether people report to the project manager, a functional head, or a supplier.
Communication and escalation — shows paths for decisions and issues.
Assurance — reviewers can test whether the organisation matches the risk and scale of the work.
OBS is not the WBS. WBS decomposes work/products ; OBS decomposes organisation . Confusing them produces activity lists mistaken for accountability charts, or org charts with no link to deliverables. WBS (what work) × OBS (who/roles) → Responsibility assignment matrix (RACI)
Scenario B — missing OBS role
A transformation WBS includes "data protection impact assessment" and "cutover runbook," but the OBS has only developers and a project manager. Nobody owns information-governance or operational-readiness roles. Work stalls or is done poorly. Building the OBS would have surfaced the need for a DPO liaison and a BAU operations lead before the schedule committed those packages.
Responsibility assignment matrix and RACI
A responsibility assignment matrix (RAM) maps work breakdown elements to organisational roles. The most common form in PMQ teaching is RACI .
Letter Meaning Practical rule
R — Responsible Does the work; may be more than one person/role Clear task ownership; enough capacity to execute
A — Accountable Ultimately answerable for completion and quality; one A per work package Approves or owns the outcome; the "buck stops here"
C — Consulted Two-way input before/during the work Limited to those whose expertise materially affects the result
- I — Informed One-way updates on progress or decisions Keeps stakeholders aware without meeting overload
- Constructing a RACI
List WBS work packages (or key activities/deliverables) as rows.
List OBS roles as columns (not every named individual if roles are stable).
Assign R, A, C, I for each cell that needs a relationship — leave blank where none.
Enforce one Accountable per row.
Ensure every package has at least one Responsible (or a clear path to assign one).
Review with role holders so assignments are accepted, not only published.
Align the RACI with the resource plan so Responsible parties are actually available.
Control changes when scope or organisation changes.
Example fragment (simplified)
- Work package Project manager Design lead Test lead Ops manager Sponsor
- Requirements baseline A R C C I
- System design pack I A/R C C I
- UAT execution I C R A I
- Go-live decision R (coordinate) C C C A
In the UAT row, operations is Accountable for accepting that BAU can run the process; the test lead is Responsible for running the tests. That split is often missed when projects treat UAT as "IT-only."
Common RACI errors
Error What goes wrong Correction
Two or more Accountables Diffused ownership; each A assumes the other will decide One A per work package; split the package if true dual ownership is needed
No Accountable Work orphans; quality and deadlines drift Assign a single A before baselining
A and R confused Senior person listed as R for everything they cannot personally do A owns outcome; R executes (A may also be R on small packages)
- Everyone is C Consultation paralysis; slow decisions Restrict C to material expertise; move others to I
- Missing BAU / supplier columns External dependencies invisible Include critical OBS external roles
- RACI not resourced Named R is 150% allocated Reconcile with availability and smoothing/levelling
- Set once, never updated Matrix drifts from reality after reorganisation Review at phase gates and major change
- Too granular or too coarse Unmaintainable noise, or useless slogans Match WBS control level
- Scenario C — RACI conflict
A design package lists both the design lead and the project manager as A . When a standards conflict arises, each waits for the other. Correct practice: design lead is A for technical adequacy of the design pack; project manager is A for overall plan integration and may be I or C on the design package itself. Escalate only the cross-cutting trade-off (cost/time/quality) to the sponsor if needed.
Scenario D — consultation overload
Every work package marks eight stakeholders as C . Workshops cannot be scheduled; progress freezes. Rebuild the matrix: two genuine C roles for technical input, remaining stakeholders I via structured updates, and a single A empowered to decide within delegated limits.
Putting identification, OBS, and RACI together
For PMQ long responses on resource identification and accountability:
Name resource types required by the activities (people, equipment, materials, facilities).
Compare need vs availability with timing, not only totals.
Use OBS to show the delivery organisation and gaps.
Build or critique a RACI from WBS × OBS with one A per package.
Link errors (dual A, unresourced R, ignored BAU) to schedule and risk impacts.
Recommend firm commitments, re-planning, or escalation where availability is not real.
That chain satisfies LO21a–b and prepares the next section: once resources are identified and assigned, allocation, smoothing, and levelling keep the schedule feasible across linear and iterative life cycles.