Who Owns the Work? OBS for Major Projects

Chapter 1

The Question Nobody Answers: Who Owns the Work?

A walk through late LNG, airport and fertilizer projects and the silence that follows the simplest question in project management: “Who owned this?”

1.1 Three Projects at 2 a.m.

LNG plant

It is 02:17 at an LNG plant. The flare draws a thin orange line in the sky, tanks cast heavy shadows, and inside a temporary office a commissioning manager is staring at a Gantt chart that still says “On Track”. Everyone in the room knows it is not. A valve hasn’t arrived, a tank is lagging hydrotest, a critical system is one bad weld away from slipping first gas.

Around the table sit the Owner’s PM, the EPC construction manager, the tank subcontractor, the controls specialist, the planner and a sleepy QS. Somebody finally asks: “Who owned this piece of work?” The room goes quiet.

Airport earthworks & drainage

On another continent, an airport runway extension is under floodlights. Earthmoving trucks crawl across a wet platform; a drainage line is still open; the paving crew is waiting. A week ago, the forecast said “earthworks critical, drainage on the path, paving just in time.” Today the forecast still says the same.

In the progress meeting, Owner, EPC and earthworks subcontractor argue about who “should have ensured” that stormwater drainage was in before the big rain. Again the question hangs over the table: “Who actually owned the interface between drainage and paving?”

Urea–ammonia complex

At a fertilizer complex, the urea granulation unit is not ready for performance tests. The ammonia plant is making product; the urea synthesis loop is stable enough; but the granulation air system and off-spec handling are late. Storage silos are not fully commissioned. Dispatch logistics improvise.

The Owner board wants to know: “Is this an EPC failure, a package vendor problem, or our own long-lead governance?” The PM looks down at a tangle of change orders and realizes the same structural question is unanswered: “Who owned this slice of work?”

Different sectors, different acronyms, different cultures. The silence is always the same.

1.2 The Blind Spot Behind “The Contractor”

In most project conversations, there are three favorite villains: “the contractor”, “the client” and “the subcontractor”. They are spoken of as if they were three individuals sitting in a room.

In reality:

“The contractor” on an airport project may mean earthworks and paving, terminals, airside lighting, baggage handling and more.
“The contractor” on a fertilizer plant may mean process units, utilities, marine export, storage and specialized packages.
“The client” is an Owner with ministries, regulators, portfolio boards, finance and operations.
“The subcontractor” might be a tank specialist, a local earthworks firm or a baggage OEM with its own global supply chain.

Vertical infographic showing the Responsibility Stack: Owner disc at top marked Accountable, EPC and Subcontractor discs below marked Responsible, connected by a RAM line. — Vertical Accountability: the Responsibility Assignment Matrix (RAM) acts as the vertical spine connecting the Owner (Accountable) to the EPC and Subcontractors (Responsible). If this line breaks, “orphan work” is created.

Bad pattern

We treat each of these complex organizations as a single box. Then we are surprised when nobody can trace exactly who failed to approve a runway drainage change, who mismanaged an ammonia compressor delivery, or who failed to mobilize the paving crew.

This book is about replacing that fuzzy blame triangle with something sharper and more useful: a clear, tabular, testable answer to “who owns this work?” whether that work is a runway subgrade, an LNG flare stack or a urea bagging line.

1.3 What an OBS Really Is

In standards language, an OBS (“Organizational Breakdown Structure”) is “a hierarchical representation of the project organization arranged so as to relate work to responsible organizational units”.

In this book we insist on a harder definition:

Working definition

An OBS is the structural map of accountability and responsibility for each slice of project work, down to the level where Control Accounts (CAs) and Work Packages (WPs) live.

The Law

If you cannot point from any Control Account — whether for runway drainage, urea granulation or LNG tank welding — to a single OBS node that owns it, you do not have an OBS. You have artwork.

1.4 What This Book Promises

What you will get

Concrete OBS patterns for Owner, EPC, subs, PMC and OICAL.
Examples set in LNG, airport (earthworks, terminals, systems) and fertilizer plants (ammonia, urea, utilities, storage).
Side-by-side good and bad practices, with consequences.
A data view: tables and codes for OBS, WBS, CAs, WPs and RAM that can be implemented in real tools.

What this book demands

That you redraw at least part of your project organization.
That you treat tables and codes as seriously as drawings.
That you are willing to ask “Who is the CAM?” on real field problems.

Chapter 2

From Org Charts to OBS: Why Boxes on PowerPoint Aren’t Enough

The crucial difference between “who reports to whom” and “who owns which work” — and why mixing them up destroys predictability.

2.1 Org Chart vs OBS: Two Different Questions

An org chart answers one question: “Who reports to whom?”

An OBS answers a different question: “Who is accountable and responsible for which piece of work?”

They are related but not interchangeable. A fertilizer plant can have a beautiful org chart and a broken OBS. An airport can have clear reporting lines and still have no structural owner for runway drainage.

2.2 Why Org Charts Seduce Us

Airport “Project Organization” slide

In a boardroom of a new airport, a slide appears titled “Project Organization”. It shows the Owner at the top, the EPC in the middle, a PMC on the side, and logos of key subcontractors — earthworks, paving, baggage — at the bottom. There are arrows. People nod. The slide is printed and pinned to walls.

Six months later, when taxiway pavement fails and drainage is underdesigned, nobody can answer which entity owned the integration between geotechnical data, stormwater design and paving sequences. The slide had logos, not accountability.

Fertilizer org chart

At a urea–ammonia complex, the EPC presents an “Organization for Execution”: Project Director, Ammonia Manager, Urea Manager, Utilities Manager. It looks tidy. But there is no place where the granulation vendor, bagging plant sub and export teams meet under one accountable entity. When product piles up with nowhere to go, everyone points back to the same pretty slide.

Failure mode

Confusing an org chart with an OBS leads to “orphan work”: chunks of scope that exist in the WBS and schedule but have no clearly defined accountable entity — like apron drainage, flare drains or ammonia off-spec handling.

2.3 Turning an Org Chart into an OBS

The practical path is usually:

Start with your existing org chart.
Strip away layers that never directly own work (pure admin).
Group remaining entities by function (earthworks, paving, tanks, utilities, etc.).
Decide which levels are:
- Divisions — big pillars (Civils, Mechanical, E&I).
- Departments — sub-functions (Airside, Tankage, Offsites).
- Teams — places where Control Accounts live (CAM homes).
- Crews — where Work Packages are executed.

Airport example

Org chart: “Construction Manager – Airside”; below, “Earthworks Engineer”, “Pavement Engineer”, “Drainage Engineer”.

OBS version:

AIR.EPC.03.01 – Earthworks & Subgrade Team (CAM home).
AIR.EPC.03.02 – Pavements & Surfacing Team (CAM home).
AIR.EPC.03.03 – Drainage & Utilities Team (CAM home).
AIR.SUB.CIV.03.03.01 – Drainage Crew West (WP executors).

Fertilizer example

Org chart: “Ammonia Manager”, “Urea Manager”, “U&O Manager”.

OBS version:

FERT.EPC.01.01 – Ammonia Unit Team (CAM home).
FERT.EPC.01.02 – Urea Unit Team (CAM home).
FERT.EPC.02.01 – Utilities & Offsites Team (CAM home).
FERT.EPC.03.01 – Storage & Marine Export Team (CAM home).

2.4 How This Book Relates to the WBS Standard

Three roles, three documents

This book assumes you already use the separate Ekton WBS standard (Deliverables & Acceptance plus the Deliverable-Oriented Naming Guide). To avoid bloating this text, we keep the split very clear:

WBS (other book) is the tree of what is delivered — product and service leaves that close on Mechanical Completion (MC) or Service Acceptance (SAC). Phases, disciplines and contractors do not appear in WBS element names.
OBS (this book) is the tree of who is organized to own and perform work — Owner teams, EPC departments, subs, PMC and OICAL.
CA & WP registers (data model) are where WBS and OBS intersect: each Control Account ties one WBS leaf (or a controlled non-WBS scope code) to one accountable OBS node; Work Packages sit under CAs and carry phase, discipline, contractor, area and system attributes.

When you see WBS examples in this book (runway drainage, urea granulation, LNG tankage), treat them as pointers; the full rules for building those WBS leaves live in the WBS textbook.

2.5 Tank Farm and Taxiway: A Simple Lens

Suppose “Tank Farm” and “Taxiway & Apron” appear as single Level-2 WBS items. The org chart shows “Construction Director”, “Tank Superintendent”, “Airside Manager”.

An OBS that can host CAs might define:

FERT.EPC.03.01 – Ammonia Tankage & Refrigeration Team.
FERT.SUB.TNK.01.02 – Tank Shell & Roof Crew.
AIR.EPC.03.01 – Runway & Taxiway Earthworks Team.
AIR.SUB.CIV.01.01 – Earthworks & Paving Sub – Western Platform Crew.

The Law

In a working OBS, every major chunk of work in the WBS — a taxiway subbase, a urea prilling tower, an LNG tank foundation — can be mapped to at least one CAM home and, below it, to one or more execution crews.

Chapter 3

Designing the EPC OBS That Actually Runs the Project

Building the EPC side of the OBS so that real teams, not just departments, carry Control Accounts and deliver systems, subsystems and infrastructure.

3.1 Starting Point: EPC Responsibilities

When the EPC is EVMS holder, the OBS must be capable of owning the entire scope: process units, utilities, offsites, buildings, infrastructure and temporary facilities. The right question is not “What departments does the EPC have?” but “Which entities must be accountable for what work?”

In an LNG project this includes process trains, storage tanks, marine facilities, utilities and flare; in an airport it includes earthworks, pavements, structures, MEP and systems; in a fertilizer plant it spans ammonia, urea, utilities, storage and export.

3.2 EPC OBS Levels

A robust EPC OBS usually has four practical levels:

Level 1 – Company / JV (EPC enterprise for the project).
Level 2 – Project Business Units (Engineering, Construction, Commissioning, Project Controls, etc.).
Level 3 – Functional Delivery Teams (e.g., Airside Civils, LNG Tankage, Urea Units).
Level 4 – Execution Crews / Cells (piping crews, paving crews, tank welding crews, E&I crews).

LNG example

EPC.LNG.00 – EPC Company (Project).
EPC.LNG.CON – Construction Division.
EPC.LNG.CON.TNK – LNG Tankage Team (CAM homes).
EPC.LNG.CON.TNK.C1 – Tank 1 Shell & Roof Crew.

Airport example

AIR.EPC.00 – EPC Company (Airport Project).
AIR.EPC.CON – Construction Division.
AIR.EPC.CON.AIR – Airside Works Team (earthworks, pavements, drainage).
AIR.EPC.CON.AIR.PV1 – Paving Crew – Runway & Taxiways.

3.3 How Deep to Go?

The CAM must sit at a level where they can influence methods, sequence and resourcing — typically Level-3 functional teams. Crews at Level 4 execute Work Packages but do not own Control Accounts.

Too shallow and you get vague “Construction” CAs that nobody truly owns. Too deep and each crew becomes its own universe, impossible to manage and audit.

Rule of thumb

A good OBS node for CAM ownership usually covers 3–15 related Work Packages, not hundreds and not just one or two.

3.4 Mapping Systems and Infrastructure

The EPC OBS must be constructed with systems, subsystems and infrastructure in mind. Tanks, flare systems, runways, taxiways, terminals and process units are all delivered through this tree.

For example, the EPC Tankage Team must clearly own the CA for “LNG Tank 1 Mechanical Completion” and “LNG Tank 2 Mechanical Completion”; the Airside Works Team must own “Runway 09–27 Infrastructure” CAs with WPs for earthworks, drainage and paving.

3.5 EPC OBS Anti-Patterns

Anti-pattern: departments only

OBS nodes are just “Civil Dept”, “Mechanical Dept”, “E&I Dept”. Nobody can tell which team owns the eastern tank, the baggage hall or the urea prilling tower.

Anti-pattern: people as OBS nodes

OBS nodes are personal names (“Ahmed”, “Sophie”), so every turnover forces a recode and destroys continuity in EV data and RAM.

The Law

The EPC OBS must be stable over time and granular enough to host Control Accounts. It is a tree of roles and teams, not a list of individuals.

Chapter 4

Using the EPC OBS to Build Control Accounts and Work Packages

Connecting WBS and OBS so that every Control Account has exactly one CAM, and Work Packages align with real execution units on site.

4.1 CA = WBS × OBS

Once the EPC OBS is defined, Control Accounts are no longer mystical. A CA is simply the intersection of a slice of the WBS with an accountable OBS node.

Example: LNG Tank 1 shell and roof welding:

WBS: 31-TANK-01-MECH-MC (Tank 1 Mechanical Completion).
OBS: EPC.LNG.CON.TNK (Tankage Team).
CA ID: CA-TANK-01-MECH-EPC.LNG.CON.TNK.

Isometric diagram showing a blue WBS block and a grey OBS block locking together into a glowing Control Account (CA) node, with Work Package slices stacked below. — The Structural Handshake: the Control Account (CA) is created exactly where the Work Breakdown Structure (WBS — the “what”) and the Organizational Breakdown Structure (OBS — the “who”) intersect. Stacked Work Packages (WP) flow down for execution.

4.2 When CAs Exist Without WBS Leaves

In a disciplined model, almost every CA is tied to a WBS leaf: a system, subsystem, building or service outcome. But a small, controlled family of CAs represents continuous governance work that deliberately has no WBS leaf.

The 95–5 Rule

At least 90–95% of CAs should anchor to WBS leaves (product or service). The remaining few are explicitly tagged as Governance / Continuous and point to a non-WBS scope code instead of a WBS element.

Think of two distinct families:

Family A — Deliverable-Tied CAs

Always have a WBS leaf: tank MC, runway section MC, ORAT campaign SAC, etc.
Use milestone or quantity-based EV methods.
Drive the readiness of real assets and services.

Family B — Governance & Continuous CAs

No WBS leaf; use a Non_WBS_Scope_Code like GOV-EVMS-Y1.
Examples: EVMS operations, Owner PMO, OICAL analytics, routine reporting.
Usually use Level of Effort (LOE) EV method with clear time bounds.

Service WBS leaves vs continuous work

The WBS standard already defines Service leaves for one-off outcomes such as:

“EV Rules of Credit Configured – v1.0” (SAC).
“Reporting & Assurance Framework – v1.0”.
“ORAT Campaign 01 – Terminal 1 Completed”.

Those are real WBS leaves with evidence and an end state; they belong to Family A. In contrast, continuous work such as “EVMS Operations – Year 1” or “Independent Analytics – Phase 1” is modeled as a Family B governance CA with a non-WBS scope code.

4.3 From CA to Work Packages

Work Packages sit one level below the CA and describe executable chunks of work for a crew or cell — “Tank 1 Shell Course 1–3 Welding”, “Apron A West Concrete Paving”, “Urea Granulation Scrubber Erection”.

Each WP is linked to exactly one CA and to at least one crew-level OBS node.

Airport paving example

CA: CA-AIR-TXWY-PAV-EPC.CON.AIR.
WP-01: WP-AIR-TXWY-SUBBASE-ZONE-1 (Earthworks Crew West).
WP-02: WP-AIR-TXWY-PAVING-ZONE-1 (Paving Crew 1).
WP-03: WP-AIR-TXWY-JOINTS-ZONE-1 (Finishing Crew).

4.4 Evidence-Based Slicing

A WP is not “one week of work” or “whatever fits on a page”. It is a slice of work that can be planned, supplied, executed and verified as a unit.

Evidence-based criteria

Clear start and finish conditions.
Measurable progress (quantities, tests, milestones).
Stable scope and minimal cross-team interfaces.
Reasonable time box (days or weeks, not months).

4.5 EPC Examples: LNG, Airport, Fertilizer

LNG tank WP set

WP-TNK-FND-01 — Foundation and ringwall.
WP-TNK-BOT-02 — Bottom plates zone 2.
WP-TNK-SHL-03 — Shell courses 1–3.
WP-TNK-ROOF-04 — Roof structure and deck.

Urea plant WP set

WP-UREA-REA-01 — Reactor and stripper installation.
WP-UREA-GRAN-02 — Granulator steel and drum.
WP-UREA-GRAN-03 — Granulation air system.
WP-UREA-BAG-04 — Bagging line mechanical completion.

4.6 EVMS and Field Reality

When CA and WP design follows the OBS, EV metrics become field-credible. The Tankage CAM can look at CPI/SPI and immediately see which WPs are driving performance. The Airside CAM can see that taxiway drainage WPs are lagging and act before paving is stranded.

The Law

EVMS only works if every CA has a real CAM and every WP maps to a real crew. The OBS is where those people live on paper.

Chapter 5

Owner as EVMS Holder: Designing the Owner OBS

When the Owner, not the EPC, is accountable for EVMS, the OBS must reflect capital governance, operations and portfolio reality without duplicating contractor structure.

5.1 What Changes When the Owner Holds EVMS

On many mega-projects, especially in regulated sectors, the Owner is EVMS holder. The EPC still executes work, but EV data is rolled up and owned by the Owner’s project controls organization.

The Owner OBS must therefore be capable of owning Control Accounts that represent:

Major facilities (LNG trains, terminals, process units).
Major contracts (EPC, EPCm, key packages).
Cross-cutting scopes (land, interfaces, permitting).

5.2 Owner OBS Levels

Level 1 – Enterprise / Portfolio (e.g., “National Airports Authority”).
Level 2 – Program / Project (Airport Expansion Program, Fertilizer Complex).
Level 3 – Owner Functions (Project Delivery, Engineering Authority, Operations Readiness, Finance, Commercial).
Level 4 – Project Owner Teams (Airport Terminal Delivery Team, LNG Tankage Oversight Team, Fertilizer Utilities & Offsites Team).

Airport Owner OBS fragment

OWN.AIR.00 – Airports Authority.
OWN.AIR.PROG – Airport Expansion Program.
OWN.AIR.PROG.PD – Project Delivery Directorate.
OWN.AIR.PROG.PD.AIR – Airside Delivery Team (CAM home for airside CAs).

5.3 Owner Control Accounts and Delegation of Authority

Owner CAs are not copies of EPC CAs. They represent Owner accountability for outcomes: “Runway and Taxiway Delivered”, “LNG Storage Ready for Operations”, “Fertilizer Export Corridor Ready”.

Each Owner CA references:

A section of the WBS (e.g., “Airside Works”).
An Owner OBS node (e.g., OWN.AIR.PROG.PD.AIR).
One or more performing entities on the EPC side in the RAM.

5.4 Typical Owner OBS Mistakes

Everything = “The Project”

The Owner OBS has only two levels: “Company” and “Project”. Every CA is effectively owned by the Project Director. No one else has clear A/R.

Mirror of EPC

The Owner simply copies the EPC’s OBS and calls it their own. This makes it impossible to see multi-contract risk and blurs the line between governance and execution.

The Law

The Owner OBS must be independent of any single contractor and aligned with Owner decisions, not contractor org charts.

Chapter 6

EPC OBS Revisited: EPC as R-Side in a Multi-Party Setup

How the EPC OBS plugs into an Owner-held EVMS, and how responsibility is shared and proven through RAMs and contracts.

6.1 A/R/C/I Across Owner and EPC

Once the Owner holds EVMS, the same physical work — an LNG tank, a runway, a urea granulation unit — appears twice:

As an Owner CA, owned by an Owner OBS node.
As one or more EPC CAs, owned by EPC OBS nodes.

The RAM defines that, for that CA:

Owner OBS node is A (accountable for outcome).
EPC OBS node is R (responsible for execution).
Others (PMC, OICAL, regulators) may be C or I.

6.2 Keeping the EPC OBS Stable

The EPC OBS defined in Chapter 3 remains valid; what changes is how it is referenced in multi-party RAMs and contracts.

The EPC Tankage Team that owns CA-TANK-01-MECH is now “R” in the Owner CA “LNG Storage Ready for Operations”. The Airside EPC team that owns CA-TXWY-PAV is “R” in the Owner CA “Runway and Taxiway Delivered”.

6.3 Flow-Down to Subs

The EPC may flow down parts of a CA to subcontractors (tank builder, paving contractor, bagging plant specialist). The EPC OBS should still hold the CA, while Sub OBS nodes are modeled at least one level down for RAM and interface control.

6.4 Contractual Alignment

For EVMS and legal reality to align, contract exhibits must reference the same structures:

WBS for scope structure.
OBS codes for obligation owners.
CA and WP registers for performance measurement.

The Law

If your contracts, schedules, cost systems and OBS use different structures and naming, you will pay in confusion and claims.

Chapter 7

Subcontractor OBSs: How Far Down You Model Subs

Deciding when a subcontractor needs its own OBS nodes in the master model and how deep to go without drowning in detail.

7.1 Why Sub OBSs Matter

Many critical failures occur in scopes owned by subcontractors: tank welding, runway paving, baggage systems, granulation packages.

If you do not model these subs at all, you cannot see where risk sits. If you model every crew, you create noise.

7.2 Principles for Modeling Subs

Model subs explicitly when they own a critical path facility (e.g., LNG tanks, runway, granulation unit).
At minimum, include a Level-3 node per major sub (e.g., SUB.TANK.01, SUB.PAVING.01).
Only go to crew level where you need to assign WPs directly or manage interfaces at that granularity.

Airport example

AIR.SUB.PAV.01 – Main Paving Subcontractor.
AIR.SUB.PAV.01.C1 – Runway Crew.
AIR.SUB.PAV.01.C2 – Apron Crew.

7.3 RAM Across EPC and Subs

In the CA “Runway and Taxiway Paving”, EPC Airside Team is still A/R on the EPC side; the Paving Sub is R for specific WPs; the Owner Airside Team is A at Owner level.

Modeling this explicitly makes it obvious who must be in a recovery meeting when paving slips.

7.4 When Not to Model Subs

Not every sub deserves structured OBS nodes in the master model. Small, low-risk suppliers whose work is fully integrated into an EPC CA/WP can remain “inside” the EPC node.

The Law

Model subcontractors explicitly when their failure would materially change project outcomes. Otherwise keep them inside the EPC’s OBS node.

Chapter 8

PMC and OICAL: Structuring Owner Extensions and Independent Assurance

Where to place PMC and OICAL in the OBS so that they add control instead of confusion — with Ekton as an example OICAL/PMC hybrid.

8.1 PMC vs OICAL

A PMC (Project Management Company) acts as an extension of the Owner’s project delivery function. It may coordinate contractors, manage interfaces and sometimes run the site PMO.

An OICAL (Owner’s Independent Controls & Analytics Layer) provides independent schedule, cost and risk controls — checking data, forecasts and claims without being responsible for execution.

8.2 Placing PMC in the Owner OBS

The PMC belongs inside the Owner OBS, usually under Project Delivery or Program Management. Its nodes might look like:

OWN.AIR.PROG.PMC – PMC Coordination Team.
OWN.AIR.PROG.PMC.AIR – PMC Airside Coordination.
OWN.AIR.PROG.PMC.TER – PMC Terminal Coordination.

These nodes can be R or C in RAMs, but rarely A — accountability stays with Owner OBS nodes.

8.3 Placing OICAL as Separate OBS

The OICAL must be structurally independent, even if the same company also provides PMC or EPC support. We usually define a separate OBS tree:

OWN.OICAL – Owner’s Independent Controls & Analytics Layer.
OWN.OICAL.SCH – Schedule & Progress Analytics.
OWN.OICAL.CST – Cost & Risk Analytics.

In RAMs, OICAL nodes are mostly C (consulted) with clearly defined check and challenge activities.

Split-screen infographic showing PMC gears and pilot wheel on the left and an OICAL magnifying glass on the right, separated by a glowing ekton.us firewall. — Visualizing structural independence: the glowing “firewall” represents the necessary separation of duties between the delivery-focused PMC and the audit-focused OICAL. Independence is a position in the OBS and RAM, not just a label.

8.4 When One Company Wears Many Hats

A company like Ekton may act as:

PMC component (running the Owner’s PMO).
OICAL (independent controls and analytics).
EPC support (BI, dashboards, planning support).

The OBS must keep these roles separated in different trees or branches, with conflict rules documented in governance.

The Law

Independence is not a logo, it is a position in the OBS and RAM. If the same node is both R and independent C on the same CA, the model is broken.

Chapter 9

The Full Multi-Organization RAM: Owner / EPC / Subs / PMC / OICAL Together

Building a single RAM that ties all OBS trees together for a system, facility or infrastructure element — with LNG, airport and fertilizer examples.

9.1 The RAM Table

A multi-organization RAM lists key deliverables or CAs down the rows and OBS nodes across the columns. Each cell contains A, R, C or I.

For a given LNG process system or airport runway, you should be able to read the RAM and know exactly:

Who is A on the Owner side.
Which EPC team is R.
Which subs are R for specific WPs.
Where PMC and OICAL provide C.

9.2 LNG System Example

Take LNG system “Boil-off Gas Recovery” as an example CA at Owner level.

Owner OBS: OWN.LNG.PROG.PROC – A.
EPC OBS: EPC.LNG.PROC.BOG – R.
Key Compressor Vendor: SUB.CMP.BOG – R for specific WPs.
PMC: OWN.LNG.PROG.PMC.PROC – C.
OICAL: OWN.OICAL.SCH – C on progress analytics.

9.3 Airport Taxiway Example

For “Taxiway & Apron Completed”:

Owner Airside Team – A.
EPC Airside Team – R.
Paving Subcontractor – R (specific paving WPs).
PMC Airside Coordination – C.
OICAL Schedule – C.

9.4 Fertilizer Export Corridor Example

For “Fertilizer Export Corridor Ready”:

Owner Logistics & Export Team – A.
EPC Offsites & Marine Team – R.
Jetty Subcontractor – R on marine works.
Port Authority – C/I depending on agreements.
OICAL Cost & Risk – C.

The Law

If you cannot fit all key players for a system on one RAM row with clear A, R, C, I, your OBS and CA design is not finished.

9.5 Pattern Library: Governance & Continuous CAs

The same non-WBS governance CAs appear again and again on major projects. Keeping them in a small pattern library avoids random “admin buckets” and makes RAM design faster.

CA name pattern	Typical OBS_A	Who is usually R	Typical EV method	Notes
Owner EVMS Governance & System Admin – Year N	Owner Project Controls / EVMS Team	Same Owner team, sometimes with PMC support	LOE over defined period	Runs the EV engine; no WBS leaf; Non_WBS_Scope_Code = GOV-EVMS-YN.
Independent Controls & Analytics Reviews – Phase N	OICAL Schedule/Cost Node	OICAL analysts	LOE or milestone per review	Evidence is review reports, findings log, challenge minutes.
EPC Project Controls Operations – Site	EPC Project Controls Dept	PC engineers & planners	LOE	Supports all delivery CAs; should not hide scope that belongs to WBS leaves.
PMC Support to Owner PMO – Year N	Owner PMO node (staffed by PMC)	PMC personnel	LOE	Accountability stays on Owner OBS; CAM may be a PMC lead by delegation.

Treat this list as a menu, not a dumping ground: if a CA does not clearly fit a pattern, ask first whether it should actually be modeled as a deliverable-tied CA anchored to a WBS leaf.

Chapter 10

The Integrated Data Model: WBS, OBS, CA, WP, RAM

Turning the concepts into a simple, robust data model that your tools and reports can actually implement.

10.1 Core Tables

At minimum you need the following master tables:

WBS_Registry – WBS ID, description, parent.
OBS_Registry – OBS code, name, parent, type (Owner/EPC/Sub/PMC/OICAL).
CA_Register – CA ID, Scope_Ref_Type, Scope_Ref_ID, WBS ID (optional), Non_WBS_Scope_Code (optional), OBS code A, OBS code(s) R, EV method, description.
WP_Register – WP ID, CA ID, performing OBS code, description, quantities, phase, discipline.
RAM_View – CA ID, OBS code, RACI letter.

Scope_Ref_Type simply records whether a CA points to a WBS_Leaf or a Non_WBS_Governance scope. The Scope_Ref_ID then holds the corresponding WBS ID or governance code. This one field pair is what allows the model to support both product/service CAs and the small family of continuous governance CAs described in Chapter 4 and 9.5.

10.2 Relationship Diagram

Conceptually:

WBS is a tree of scope.
OBS is a tree of entities.
CA links one scope reference (usually a WBS leaf) to one OBS node A plus one or more performing nodes.
WP links to one CA and one crew-level OBS node.
RAM expands CA ↔ OBS relationships with RACI letters.

10.3 Examples Across Sectors

The tables can host all three sectors in parallel, distinguished by project code or WBS root. The same modeling logic applies whether the CA describes an LNG tank, an airport runway or a fertilizer bagging line.

10.4 Typical Data Pitfalls

Free-text OBS names with no codes → impossible joins.
Multiple CA registers (by contractor, by discipline) with no master key.
Schedules and cost systems each invent their own WBS codes.

The Law

If you cannot join WBS, OBS, CA, WP and RAM with clean keys, you cannot automate EVMS or produce credible analytics.

Chapter 11

Tool Integration: Schedule, Cost, Risk, Contracts & BI

Making sure Primavera, cost systems, risk registers, contract databases and BI tools all see the same OBS-anchored reality.

11.1 Schedule

Activities should carry:

WBS ID or governance scope reference.
Responsible OBS code (CAM home).
Optional executing OBS code (crew).

This enables schedule reports by CA, by OBS node and by system.

11.2 Cost

Cost accounts should map to CAs and WPs. Commitments and actuals flow into CA level, preserving Owner vs EPC vs sub breakdown.

11.3 Risk & Contracts

Each material risk should be linked to at least one CA and one OBS node A/R. Contract line items should reference WBS and OBS codes so that claims can be traced back to accountable entities.

11.4 Business Intelligence Layer

BI dashboards become dramatically more powerful when they use the OBS-anchored model: you can see CPI / SPI by Owner function, by EPC team, by sub, by system, by airport zone or fertilizer unit.

The Law

BI without a solid OBS is just pretty charts. BI with a solid OBS is a microscope on accountability.

Chapter 12

Governing and Auditing the OBS & EVMS

Keeping the OBS and CA/WP model healthy over the life of the project, and using audits as learning tools instead of rituals.

12.1 Governance Basics

A good OBS and Control Account model does not maintain itself. It behaves like a living standard: somebody owns it, changes are controlled, and history is preserved. When nobody owns the model, it silently diverges from reality and all the elegant theory in previous chapters collapses.

At minimum, governance requires:

A nominated OBS/EVMS custodian on the Owner side and another on the EPC side (they may be supported by PMC or OICAL, but accountability is clear).
A simple change control workflow for OBS nodes, CAs and WPs: who can propose, who approves, how impacts on schedule, cost and RAM are evaluated.
Versioning and history so that an auditor can see which CA, WP or OBS code existed at the time a decision or claim was made.
A short, written “EVMS Rule Book” that describes how WBS, OBS, CA, WP and RAM fit together on this specific project.

Why this matters for schedule & estimates

Without governance, people quietly re-code activities and cost accounts to match “how the job is really run”. The schedule stops reflecting the CA/WP model, EV loses its anchor, and CPI/SPI become decorative numbers instead of early-warning signals.

12.2 CAM Discipline

CAMs are not symbolic names on a RACI chart. They are the first line of defense between the model and the field. A real CAM:

Understands their CA scope, quantities, WBS reference, systems, areas and milestones — and can explain them in plain language to a field superintendent.
Owns the forecast for that CA: remaining work, expected cost, risk, opportunities and required corrective actions.
Reviews EV metrics (EV, AC, PV, CPI, SPI) and challenges data quality when the numbers and reality do not match.
Leads or actively participates in recovery planning when the CA is slipping, instead of passively receiving decisions from elsewhere.

Anti-pattern: CAM in name only

A CA is assigned to “Project Director” because “they are responsible for everything”. Nobody below feels ownership, forecasts are produced by the planning team alone, and EV becomes a monthly reporting ritual.

12.3 Audits

Audits are not about catching people; they are about testing whether the structures in this book exist in real life. A practical audit program will routinely:

Pick a random CA and find the CAM. Do they know they are the CAM? Can they show the latest forecast and explain the path to completion?
Pick a WP and find the crew or supervisor. Do they recognize the description, quantities, and location? Are progress measurements consistent with what is reported to EVMS?
Pick a recent delay or major change (e.g., runway drainage, LNG tank roof, urea granulation air system) and trace accountability across Owner/EPC/Sub using the RAM. Is A/R/C/I unambiguous?
Compare the approved CA/WP structure against the current schedule and cost system. Are all active activities and cost accounts attached to known CAs?

The Law

An OBS that cannot survive a simple walk-through audit — from CA to CAM, WP to crew, delay to accountable nodes — is not a control system, it is decoration.

12.4 Common Governance Failure Modes

Across LNG, airport and fertilizer projects, the same governance mistakes keep appearing. Recognizing them early is one of the fastest ways to protect schedule and estimate reliability.

Untended model: OBS, CA and WP registers were clean at baseline, but nobody was assigned to maintain them. Six months later, schedule and cost use new codes that do not exist in the registers.
“Admin bucket” CAs: large Level of Effort CAs called “Construction Management” or “Project Controls” absorbing everything that was hard to classify. These hide real problems and make CPI/SPI meaningless.
Uncontrolled splitting/merging: teams split or merge CAs midway through the job with no history. Trend analysis is destroyed and forensic analysis becomes impossible.
Shadow spreadsheets: planners or cost engineers maintain unofficial CA/WP mappings in private files because updating the official model is “too slow”. Within months, nobody knows which version is real.

Governance countermeasures

A single “golden source” for WBS, OBS, CA and WP registers.
A weekly or bi-weekly checklist where the custodian reconciles changes in schedule and cost against the model.
A simple rule: no new CA or OBS code goes live without an updated RAM and CAM assignment.

12.5 Minimal Owner & EPC Governance Charter

Before the project ramps up, the Owner and EPC should sign a short OBS & EVMS Governance Charter. Typical topics include:

Who approves changes to the WBS, OBS, CA and WP registers.
How Owner, EPC, subs, PMC and OICAL are represented in the RAM and who maintains it.
How EV rules of credit are documented and updated when construction methods or sequences change.
How EV metrics feed decision forums (daily, weekly, monthly) so that governance is linked to real actions, not only reports.

Chapter 13

Case Studies & Failure Patterns

Realistic scenarios from LNG, airport and fertilizer projects showing how OBS mistakes surface as delays, claims and political problems.

13.1 LNG Storage Delay

An LNG project suffers a nine-month delay in achieving storage readiness. First gas is technically possible, but without certified storage the commercial date keeps slipping and liquidated damages accumulate.

Root cause analysis shows:

Tankage scope split across three vague CAs (“Tankage Civil”, “Tankage Mechanical”, “Balance of Tankage”) with overlapping work.
No single Tankage CAM with authority over schedule, sequence and vendor interfaces. Each discipline optimized its own work; nobody owned the integrated tank path.
Vendor, civil and mechanical subs not modeled in the RAM. When welding productivity collapsed, nobody knew whether the real bottleneck was vendor supervision, scaffolding, or inspection.

When the OBS is rebuilt with a clear Tankage Team node and explicit sub OBS nodes, the second tank progresses predictably. CAs map to real systems (foundation, shell, roof, internals), RAM clarifies A/R, and disputes shrink because everyone can see where responsibility starts and ends.

13.2 Airport Runway and Drainage

At a new airport, runway and taxiway pavements show early cracking and pumping. Remediation is expensive and politically sensitive because the opening date is fixed.

Investigation shows that the drainage system was late and incomplete when pavements went down. The schedule had shown “green” because:

The OBS had one node “Airside Civil” with no separation between drainage and earthworks/paving. No team felt personally accountable for the interface.
The CA register treated the entire airside as one CA. Progress on earthworks masked delay on drainage.
The RAM gave the EPC Airside node both A and R, with the Owner Airside team only “informed”. Independent review (PMC/OICAL) was not formally involved.

After re-structuring, separate CAs are created for drainage and pavements, with distinct OBS teams and CAMs. PMC and OICAL receive explicit C roles. Future decisions about “Can we pave?” are taken against clear, system-level readiness criteria, not subjective impressions.

13.3 Fertilizer Export Corridor

A fertilizer plant starts producing urea, but the export corridor is not ready. Product piles up in temporary storage, demurrage costs rise, and government stakeholders ask why the “finished plant” cannot ship.

Storage silos, conveyors and marine facilities were each managed by different sub-teams with no single export CA or OBS node:

Mechanical team focused on silos and conveyors.
Civil/marine team focused on jetty and mooring.
Logistics team assumed “export” was someone else’s problem.

With an Export Corridor CA anchored in the WBS and mapped to an Owner Logistics A-node and an EPC Offsites R-node, plus RAM entries for port authority and marine contractor, decisions and recovery programs become coherent. Future corridor-style scopes are planned and controlled as first-class systems, not as a tail of several unrelated contracts.

13.4 Cross-Case Patterns

Across these cases, the same structural patterns appear:

No single accountable OBS node for a critical system (tankage, drainage, export corridor).
Over-aggregated CAs that mix several systems or disciplines into one performance bucket, hiding problem areas.
Weak RAMs where Owner, EPC, subs, PMC and OICAL roles are blurred or missing.
Schedules decoupled from OBS, so activities move without any CAM clearly feeling the impact.

The Law

Most schedule and estimate failures trace back to structural choices made early: how you defined OBS, CAs, WPs and RAM. Fixing them later is possible but always more expensive than getting them right up front.

Chapter 14

Exercises, Exams & Ready-to-Use Templates

Putting the ideas to work: structured exercises, exam-style questions and starter spreadsheets for your own projects.

14.1 Design Exercises

Exercise 1 — Airport OBS
Given a simplified WBS for an airport (earthworks, runway, taxiways, terminal, baggage, utilities), design an EPC OBS and assign A/R for three key CAs. Then propose one Owner CA and RAM row for “Runway & Taxiways Delivered”.
Exercise 2 — Fertilizer OBS
Using an ammonia–urea–utilities WBS, design Owner and EPC OBS trees and build a RAM for the urea granulation system. Identify at least two subcontractors that require explicit Sub OBS nodes.
Exercise 3 — LNG Tankage Governance
Starting from a tank WBS (foundation, shell, roof, internals), propose a CA/WP structure and define which nodes in the Owner, EPC and Sub OBS trees will be A and R. Draft two audit questions you would ask the Tankage CAM.

14.2 Exam-Style Questions (Conceptual)

Below are examples of exam-style questions. They are intentionally short in this HTML version.

In a given RAM snippet, identify which OBS node has ambiguous A/R and propose a correction consistent with the “one A per CA” principle.
Given a delay in runway drainage, trace which Owner, EPC and Sub OBS nodes should appear in the recovery meeting and explain their roles.
For an EVMS where 30% of activities have no CA ID, explain the impact on CPI/SPI and what structural fixes are needed.

14.3 Templates

Suggested Excel/CSV templates (simple columns, no macros required):

OBS_Registry.xlsx – OBS_Code, OBS_Name, Parent_OBS_Code, OBS_Type (Owner/EPC/Sub/PMC/OICAL), Level, Notes.
CA_Register.xlsx – CA_ID, Scope_Ref_Type, Scope_Ref_ID, WBS_ID (optional), Non_WBS_Scope_Code (optional), OBS_A_Code, Primary_OBS_R_Code, EV_Method, Description, CAM_Function.
WP_Register.xlsx – WP_ID, CA_ID, Performing_OBS_Code, Area, System, Subsystem, Discipline, Phase, Planned_Qty, Unit, ROC_ID.
RAM_Matrix.xlsx – CA_ID, OBS_Code, RACI (A/R/C/I), Notes. A pivot table can then generate RAM views by CA or by OBS node.

The Law

Do not wait for the “perfect tool” before modeling your OBS and CAs. Start with simple tables; gravity will pull everything else toward them.

14.4 Interactive Q&A — Avoiding Classic OBS & EVMS Mistakes

The questions below are designed for self-study or group discussion. Click on each question to reveal the answer. Most answers link back to “laws” and examples from earlier chapters.

1. Why is an org chart not the same as an OBS?

An org chart shows who reports to whom; an OBS shows who owns which work. Org charts are about reporting lines; OBS nodes are about accountability for specific CAs and WPs. You can have a beautiful org chart and still have orphan work if no OBS node is clearly accountable for, say, runway drainage or LNG tank internals. Treating the org chart as the OBS is a primary root cause of unclear ownership and unreliable EV metrics.

2. What happens when a Control Account has more than one CAM?

When more than one person is named as CAM for a CA, nobody is truly accountable. Forecasts become negotiation exercises, corrective actions are delayed, and EV indicators lose meaning. The “one CA – one CAM” rule is crucial: many people can contribute, but only one OBS node (and named CAM) holds A for that CA in the RAM.

3. Why must most CAs be tied to WBS leaves?

Tying CAs to WBS leaves anchors EV to real scope. It allows you to see cost and schedule performance per system, subsystem or facility. If CAs are not mapped to WBS, you cannot reliably answer “How are we doing on Tank 1?” or “Is the export corridor on track?”. The only exception is the small family of governance/continuous CAs explicitly tagged as Non_WBS_Scope_Code, described in Chapters 4 and 9.5.

4. When is Level of Effort (LOE) acceptable, and when is it dangerous?

LOE is acceptable for continuous governance work (EVMS operations, OICAL reviews, PMC support) where progress is primarily time based. It is dangerous when used for deliverable-driven scope such as tank welding, runway paving or urea granulation. Using LOE there hides productivity issues and breaks the link between EV and physical progress, making CPI/SPI useless for control.

5. How does a weak OBS break schedule reliability?

If schedule activities are not coded to OBS nodes, no CAM feels responsible for them. Activities slip without structured ownership, float is consumed silently, and re-sequencing is done ad hoc by the planner. A strong OBS allows slice-and-dice views by team, system and area, making it clear which CAM must lead recovery.

6. Why should the WBS avoid embedding phases, disciplines or contractor names?

WBS describes what is delivered, independent of how, by whom or in which phase. If you embed “Civil”, “Mechanical”, “EPC” or “Sub A” in WBS IDs, you lock structural decisions (like who executes which phase) into the scope tree. This makes rephasing, replanning and re-tendering painful and breaks the clean WBS×OBS separation needed for CA design.

7. Why is it risky to create large “admin” CAs like “Construction Management”?

Large admin CAs become dumping grounds for mis-coded work, time writing, and costs that nobody wants to classify. They often use LOE and end up consuming a significant share of the budget without providing control information. They also distort performance metrics because overruns in real work are hidden under an amorphous management bucket. It is better to create focused governance CAs with clear scope and evidence.

8. How do you decide when to model a subcontractor explicitly in the OBS?

Model a subcontractor explicitly when its failure would materially affect project outcomes (critical path facilities, high-value packages, complex interfaces). Typical examples: LNG tanks, runway paving, baggage systems, granulation packages. For small, low-risk subs whose work is fully integrated into an EPC CA/WP, keep them inside the EPC node to avoid unnecessary complexity.

9. What are the signs that your EV metrics (CPI/SPI) are not trustworthy?

Red flags include: activities without CA IDs, frequent manual EV overrides, large admin CAs, heavy use of LOE where physical progress should be measured, and CAMs who cannot explain their numbers. Another sign is when field teams are surprised by EV reports — meaning measurements and reality are disconnected.

10. Why is versioning of CA/WP registers critical for claims and forensics?

Claims and forensic analysis rely on reconstructing who was accountable for what at a given time. If CAs and WPs are changed without history, it becomes impossible to prove whether a delay was in scope, who owned it, and which mitigation options existed. Simple effective versioning (date, reason, approver) provides a defensible record for both Owner and EPC.

11. How should continuous reporting and meetings be represented in the model?

Routine reporting and coordination meetings are usually part of governance CAs (EVMS operations, PMO, OICAL) rather than separate CAs for each meeting. They should support deliverable-tied CAs, not replace them. Creating CAs for every meeting is a smell that governance is being modeled instead of the work itself.

12. What is the impact of not involving OICAL or PMC explicitly in the RAM?

If OICAL/PMC roles are not visible in the RAM, their challenge and assurance activities become ad hoc. Reviews may happen, but they are not systematically linked to specific CAs or decisions. Explicit C roles in RAM clarify where independent assurance is expected (e.g. tankage readiness, runway drainage, export corridor) and make it easier to resist pressure to “just approve”.

13. How do you fix a broken OBS mid-project without stopping the job?

Start by stabilizing the model going forward: freeze the current WBS, define a clean target OBS and CA structure, and map existing activities and cost accounts gradually. Use a “coexistence period” where old and new codes are cross-referenced in a migration table. Do not attempt a big-bang recode in the middle of critical work; focus recovery first on high-risk systems and CAs.

14. Why must governance distinguish between Owner A and EPC R on the same CA?

Blurring A (Owner) and R (EPC) roles on the same CA creates confusion during delays and claims. The Owner is accountable for the outcome and funding; the EPC is responsible for execution. When these roles are not explicit, it becomes easy to shift blame and hard to agree recovery plans. RAM rows that show OWNER.A and EPC.R make conversations sharper and faster.

15. What are good indicators that your CA/WP granularity is appropriate?

Each CA should group 3–15 related WPs; each WP should represent a coherent bundle of work with clear start/finish criteria and a duration in days or weeks (not hours, not many months). CAMs should be able to discuss each CA/WP in weekly meetings without being lost in hundreds of tiny slices or drowning in giant buckets.

16. How does a multi-organization RAM help during schedule recovery?

When a system slips (e.g. export corridor, runway, granulation), the RAM tells you exactly who must be in the room: which Owner, EPC, Sub, PMC and OICAL nodes carry A/R/C. Without it, recovery meetings become crowded and unfocused; key players may be missing; and decisions are taken without those who actually control resources or approvals.

17. Why is it dangerous if planners are the only people who understand CA IDs?

If CA IDs are “planner language” only, CAMs and field supervisors cannot relate EV data to their daily work. Forecasts become a set of numbers adjusted in Primavera or the cost system, rather than a lived understanding of remaining work. Every CA should have a plain language description that field teams recognize.

18. What should trigger the creation of a new CA?

A new CA is justified when a distinct scope (usually a WBS leaf or governance scope code) requires its own accountable entity, forecast and performance tracking. Triggers include a new contract, a major change in execution strategy, or the realization that an existing CA mixes systems or areas that behave very differently in risk and performance terms.

19. How can you see from reports that CAs are mis-aligned with how the job is run?

Symptoms: all CAs look “green” while field teams are in trouble; major areas or systems cannot be isolated in reports; EV trends are flat despite obvious productivity issues; or one CA dominates value while others are tiny. Interviews reveal that supervisors think in a different breakdown (e.g. by pier, runway section, train, corridor) than the CA structure uses.

20. Why should CA and WP changes be synchronized with schedule and cost baselines?

If you change CAs/WPs without re-baselining schedule and cost (or at least clearly mapping old to new), history is split across multiple structures. Trend analysis and forensic review become unreliable, and you may double-count or miss work. Synchronizing changes keeps EV, schedule and cost coherent.

21. What is the danger of having WPs that span multiple systems or areas?

Multi-system or multi-area WPs blur location and scope. When part of the work is complete and part is not, progress assessments become subjective. In claims or recovery planning it is difficult to know which part of the WP caused delay. Wherever possible, WPs should be homogeneous in system/area so that progress and responsibility are clear.

22. How can governance prevent “shadow EVMS” spreadsheets?

Governance should require that all official EV calculations and CA/WP mappings live in controlled systems or master spreadsheets. If people feel forced to maintain private files, it is usually because official processes are slow or inflexible. Fix the bottlenecks, involve users in improving the templates, and explicitly forbid decisions based on ungoverned copies.

23. Why should Owner and EPC agree upfront on how non-WBS governance CAs are used?

If governance CAs are not defined consistently, parties may hide execution scope or commercial risk under “management” labels. Agreeing on a small, named set of governance CAs (EVMS operations, PMC support, OICAL reviews) keeps the model transparent and makes it harder to obscure cost or delay behind vague categories.

24. What is the single most important discipline habit to keep the model alive?

A simple weekly ritual where the OBS/EVMS custodian and key CAMs review: (1) any proposed CA/WP or OBS changes, (2) mismatches between schedule/cost and the model, and (3) one or two CAs in detail. This habit keeps structures close to reality and surfaces problems while they are still small.