Home›Blog›Organizational breakdown structure: who answers for what
FundamentalsBeginner
Published September 6, 2026 · By Vincent KENNEL
Organizational breakdown structure: who answers for what
Referentials do not agree on what an organizational breakdown structure decomposes, and the disagreement is older than the acronym itself. What the OBS is for, how far down it goes, and which reading binds on a contract.
In brief
An organizational breakdown structure (OBS) is the decomposition of the organisation that performs a project, taken down to the level where each element carries a single, unambiguous delivery responsibility (ISO 21511:2018). It exists for that project and for its duration only, which is what separates it from the permanent company organization chart.
A work breakdown structure can be complete, clean and agreed, and still leave one question open: who answers for each work package. On a large contract programme that question rarely surfaces while planning. It surfaces at the first variance, when someone has to be named to deal with it. The structure that answers it is the organizational breakdown structure, or OBS.
What an organizational breakdown structure is
ISO 21511:2018 defines it, in article 3.5, as the decomposition of the management team of an organisation, or of the management team that performs the work of a project or programme. Article 5.3.2 adds the condition that does the work in practice: where the work breakdown structure and the OBS are integrated, the lowest level of the work breakdown must hold elements whose delivery responsibility is single and unambiguous.
Three other referentials, from different traditions, converge on the same two points, the object decomposed and the stopping criterion. The PMBOK Guide glossary has not moved from the 1996 edition to the 7th edition (2021): a hierarchical representation of the project organisation, relating project activities to the organisational units that carry them out. The PMI Practice Standard for Work Breakdown Structures, 2nd edition (2006) requires a single point of responsibility for each work package. Guideline 2 of the EIA-748-D Intent Guide (2018) gives the contractual version: the OBS assigns responsibility, accountability and authority for all tasks to be performed.
The name itself is unstable, a first sign that the agreement is narrower than it looks. ISO 21511:2018 hesitates with itself, writing organizational breakdown structure in article 3.5 and organization breakdown structure in figure B.4, and the PMBOK Guide, 3rd edition (2004) records both spellings under one definition. The object has no settled name in French either: the AFITEP Dictionnaire de management de projet, 3rd edition (1996) carries three separate entries across two consecutive pages, one of which is its OBS. Why the referentials disagree on what is decomposed is the subject of the last section.
Figure 1: three objects, one subject
An OBS is neither the company organization chart nor the resource breakdown structure. ECSS-M-ST-10C Rev.1 (2009) is the only referential we have read that names both and opposes them: its article 4.3.7 sets the project OBS, with its interface and contractual responsibilities, against the company organization breakdown structure, which describes the functional aspects of the company. The confusion is old and it is tooled. Writing in PM Network in 1993, Harvey A. Levine found the term configured as a resource breakdown structure in one scheduling product and as a second variant of the work breakdown structure in the next.
Figure 2: the two axes of a project
Why a project needs an organisation of its own
The reason is not that the company lacks an organisation chart, but that an organisation chart does not carry what a project needs. Harold Stieglitz put it without hedging in 1964: an organisation chart is not an organisation, and what it clearly does not show is the degree of responsibility and authority exercised by positions on the same management level, two people at that level being able to hold very different degrees of it. That axis, with what authority, is what a project has to write down.
The second reason is that a project's organisation is temporary. John F. Mee tied the matrix form to the contract in 1964: it works where the work is performed for specific project contracts, the project manager's authority following the provisions of that contract, and completed or abandoned projects being deleted from the organisation. Fifteen years later Linn C. Stuckenbruck (Project Management Quarterly, 1979) gave the structural version, the project being temporary where the functional departments are more permanent. The two do not agree on how much authority the project manager holds, and this article does not arbitrate. It takes the consequence that holds either way: the degree of authority varies, so it is written rather than assumed.
The forms that organisation takes have names. The APM Body of Knowledge, 8th edition (2025) lists functional, matrix and project in article 5.7.1, and states that the choice is what creates the project's OBS. ECSS-M-ST-10C Rev.1 (2009) sets the bar for the result in article 4.2.2: all essential disciplines present, defined functions, clear reporting lines, interfaces, and an unambiguous allocation of roles, responsibilities and authorities.
What goes into it, and how far down
The stopping rule is a criterion, not a number of levels, and two independent referentials state it in the same terms: ISO 21511:2018 (article 5.3.2) asks for single and unambiguous delivery responsibility, the PMI Practice Standard for Work Breakdown Structures, 2nd edition (2006) for a single point of responsibility. The decomposition goes down until every element has one. None of the texts read for this article sets a general depth rule, and the one attested piece of codification, the level 0 to 3 codes in Moder, Phillips and Davis, Project Management with CPM, PERT and Precedence Diagramming, 3rd edition (1983), is an example rather than a rule.
What goes in is more prescribed than it looks. NF X 50-115:2017, the French standard in force, describes the project organisation in article 5.4.2 as answering three needs, each carried by a team: directing the project as a whole, which falls to the restricted project team and usually gathers the work package owners; managing the project management activities; and steering the product activities, with the architect. The same standard states that there is no single solution, and recommends that the organisation be validated by the governance body before it is implemented.
That standard also carries the clearest statement of the second axis. Its article 5.4.1 makes the work breakdown structure one of the inputs the project manager takes into account when defining the project organisation. The work breakdown is normatively an input to defining the organisation, not the reverse. Where the two are crossed, control accounts are established, and that crossing is the subject of a separate article.
One attested example rather than an invented one: McCarthy's NASA TM-81509 (1980) names the twelve entities that were enough to run a complex aerospace programme at the time. It is a real and dated list, not a template to copy.
Where it comes from, and why the referentials disagree
The mechanism is older than the word. USAF PERT Volume III (December 1963) already carries codes for the responsible and the performing organisation, and assigns each work package to one of them. Fourteen years later the crossing became contractual: the fifth organizational criterion of DoDI 7000.2, dated 10 June 1977, requires the contract work breakdown structure to be integrated with the contractor's functional organizational structure, so that performance can be measured by both. Neither document names the acronym.
It enters American doctrine between 1980 and 1995; the precise year is not established. The earliest trace among the texts read for this article is Moder, Phillips and Davis (1983); the first definition comes with the edited volume by Kerridge and Vervalin, Engineering and Construction Project Management (1986), which settles the reading early: a project has its own OBS whether it runs on a task force or on functional departments. By 1995 it is joint-service doctrine, in the Cost/Schedule Management Guide, Draft Version G. The PMI standardises the term with the 1996 edition of the PMBOK Guide, ISO with ISO 21511:2018.
Figure 3: one source, two lineages
The divergence begins here, and it does not set a rigorous text against a careless one: two traditions leave the same 1977 criterion. The normative one, carried by ISO and by European space work, holds that the OBS decomposes the project's own organisation. The one born of cost control holds that it decomposes the project portion of the permanent organisation, read by function, as the Planning & Scheduling Excellence Guide (PASEG) version 4.0 (2019) still does. The functional reading is not late carelessness: it sits in the founding criterion, with forty-two years of continuity. Its visible trace is the PMBOK Guide contradicting itself, glossary against main text, in its 3rd (2004), 5th (2013) and 6th (2017) editions, until the 7th edition (2021) aligned the two at article 4.6.4.
The doctrine that carried the acronym longest also gave it up: the DoD Earned Value Management System Interpretation Guide of 14 March 2019 renames it an organisational structure. One text reconciles the two readings instead of choosing: NASA/SP-20220009501 of May 2022 defines the OBS as the project hierarchy of line and functional organisations applied to the specific project. A reconciliation is not a consensus.
What settles the meaning of the word on a project is therefore not a consensus, since none exists, but the referential named in the contract.
In short
An organisation that is written nowhere is discovered at the first arbitration, when there is no longer time to negotiate it. The move is small: take the project's work breakdown, go down until every element has one owner who can be named, and write beside each owner the degree of authority actually held, since two people at the same level rarely hold the same. Then name, in the project's own documents, which referential the word OBS follows here. On a contract, that is the only definition that binds.
Stop guessing. See the real impact.
Frequently asked questions
Q.What is the difference between an OBS and a work breakdown structure?
One decomposes the work, the other the organisation that answers for it. They are also ordered: NF X 50-115:2017 makes the work breakdown one of six inputs to defining the project organisation, alongside its logic, requirements, stakeholder expectations, risks and interfaces.
Q.Do you still need an OBS if the company is already organised in project teams?
Yes. The edited volume by Kerridge and Vervalin settled that in 1986: whether a project runs on a dedicated task force or on functional departments, it still has an OBS of its own, showing which organisational elements are responsible for performing its work.
Q.Who approves the project organisation, and when?
NF X 50-115:2017 recommends that the project organisation be validated by the governance body before it is implemented. Defining it and approving it are two separate acts, and the standard puts that approval before implementation rather than after.
References
AFNOR - NF X50-115 - Management de projet et de programme, présentation générale - Décembre 2017
AFNOR, AFITEP - Dictionnaire de management de projet français-anglais-espagnol - 3e édition, 1996
APM - APM Body of Knowledge - 8th edition, 2025
Arthur E. Kerridge, Charles H. Vervalin - Engineering and Construction Project Management - 1986
DoD - Cost/Schedule Management Guide - Draft, Version G, 15 May 1995
DoD - DoDI 7000.2 - Performance Measurement for Selected Acquisitions - Edition of 10 June 1977
DoD - USAF PERT Volume III - PERT Cost System Description Manual - Advance Copy for AFSC Implementation, December 1963
DoD - DoD Earned Value Management System Interpretation Guide (EVMSIG) - 2019
ECSS - ECSS-M-ST-10C Rev.1 - Space project management, Project planning and implementation - 2009
Harold Stieglitz - What's Not on the Organization Chart - 1964
ISO - ISO 21511:2018 - Organigrammes des tâches en management de projet et de programme - 1st edition, 2018
John F. Mee - Matrix Organization - 1964
Joseph J. Moder, Cecil R. Phillips, Edward W. Davis - Project Management with CPM, PERT and Precedence Diagramming - 3rd edition, 1983
NASA - NASA/SP-20220009501 - Space Flight Program and Project Management Handbook - 2022
NASA - John F. McCarthy Jr. - NASA TM-81509 - Matrix Management for Aerospace 2000 - 1980
NDIA - EIA-748-D Intent Guide - Earned Value Management Systems - Revision D, 2018
