P6 EPS, OBS and Enterprise Data
Last reviewed 16 September 20267 min read
The structures above the project — and why a shared database goes wrong when nobody owns them
🟩 In one line: The EPS says where a project sits, the OBS says who is responsible and who can see it, and enterprise data (global calendars, codes, resources, UDFs) is shared by every project in the database — which is why a planner should create as little of it as possible and never import it casually.
👤 Who this is for: J/M. Prerequisites: setting-up-a-p6-project. Companion to p6-global-vs-project-data and cleaning-an-xer-before-import.
First, let's be honest about why this page exists
On a standalone laptop none of this matters. On a company database with 40 projects and 12 planners it matters every week: someone imports a subcontractor's XER with "Keep Existing" unticked and every project's 6-day calendar now has the subcontractor's holidays; someone creates a global activity code called "Area" that clashes with the one already there; someone deletes an EPS node and takes three archived projects with it.
The fix is not technical. It is knowing which four things are shared, agreeing who owns them, and treating everything else as project-level.
🟨 The standard — what "good" looks like
| Source | What it asks for (paraphrased) | Relevance |
|---|---|---|
| PMI Practice Standard for Scheduling, 2nd ed. | Schedule model components structured consistently; data integrity maintained | Enterprise data is the shared component |
| AACE RP 38R-06 | Schedule basis records the coding structures and calendars used | Which are global and which are project must be stated |
| GAO Schedule Assessment Guide, BP 1 | Capture all activities within a defined structure | EPS/WBS relationship |
| DCMA 14-Point | Assessed per project | An EPS node summarising several projects is not a schedule for assessment |
| Client schedule specifications (typical Gulf) | Often prescribe activity code names and calendar names | Prescribed names are project codes in your database, mapped on export |
🟢 Rule: EPS and OBS belong to the database owner; a planner creates project-level codes, project calendars and project UDF values, and treats every global object as read-only unless the owner says otherwise.
How it actually works
1. The three structures
| Structure | What it is | Who owns it | What a planner does with it |
|---|---|---|---|
| EPS (Enterprise Project Structure) | Hierarchy of nodes holding projects — e.g. Company → Region → Client → Project | Database admin / PMO | Places the project in the right node; never creates or deletes nodes without agreement |
| OBS (Organisational Breakdown Structure) | Hierarchy of responsible managers; drives security — a user sees only projects under OBS nodes they are assigned to | Database admin | Assigns the project's Responsible Manager; asks admin for access changes |
| WBS (per project) | The project's own breakdown, below the EPS | The planner | Builds it (wbs-structure-design) |
The EPS is not a WBS for the whole company. Summarising a node gives you a roll-up of unrelated projects — useful for a portfolio dashboard, meaningless as a schedule.
2. Enterprise (global) data — what is shared
| Object | Global / project options | Convention |
|---|---|---|
| Calendars | Global, Resource, Project | Project for anything project-specific; global only for enterprise standards the admin maintains |
| Activity codes | Global, EPS, Project | Project for Area, Level, Discipline, Sub, Change Ref, Split From; global only for enterprise reporting codes (e.g. Sector) |
| Project codes | Global only | Admin sets (Client, Region, Sector, Status) |
| Resources and roles | Global only | One resource pool; planner adds resources only under the node agreed for the project; quantity-loaded jobs use non-labour resources per trade |
| Cost accounts | Global only | Mirror the company's cost code structure; admin owns |
| UDFs | Global definitions; values per project | Definitions created once by admin (Duration Basis, Qty, Unit, Rate, Crew); values are the planner's |
| Notebook topics | Global (Admin Categories) | Created once: Logic Basis, Forecast Basis, Change Basis, Recovery Basis |
| Currencies, units of measure | Global | Admin |
| Filters, layouts, reports | Global or User | User for personal; global only when the team agrees a standard |
| Baselines | Per project | Planner, per the baseline register |
3. Where it goes wrong — the import
An XER carries the project and every global object it references. On import with default options, incoming global objects overwrite yours. The production rule from cleaning-an-xer-before-import: received files go into a sandbox database first; production import config = Keep Existing / Do Not Import for global data, Delete unticked; original file archived unedited.
| Incoming object | Safe import setting | Consequence of getting it wrong |
|---|---|---|
| Global calendar with the same name as yours | Keep Existing | Every project's holidays change |
| Global activity code "Area" | Do Not Import (or Keep Existing) | Code values merge; filters break |
| Resources | Do Not Import unless agreed | Pool polluted with 300 duplicate labour resources |
| Cost accounts | Do Not Import | Company cost structure gains foreign nodes |
| UDF definitions | Keep Existing | Duplicate "Qty" fields, one empty |
4. Housekeeping the admin should run
| Task | Frequency | Tool |
|---|---|---|
| Orphan global calendars (no assignments) | Quarterly | Enterprise → Calendars, "Used By" |
| Duplicate activity codes / values | Quarterly | Enterprise → Activity Codes |
| Resource pool hygiene | Quarterly | Enterprise → Resources, filter unused |
| Archived projects moved to an "Archive" EPS node, status Inactive | At project close | Enterprise → Projects |
| OBS access review | Quarterly | Admin → Users; OBS |
5. What the planner records
In the SBM tool-settings section: EPS node, OBS responsible manager, list of project calendars, list of project activity codes, list of global objects relied on (with owner). On export for submission, note in the transmittal which global objects the file carries — so the receiving planner can set their import options before, not after.
🟥 Where people go wrong
- Creating global codes for a single project. They follow every XER out of the database and clash with someone else's the moment they land. Project-level, always, unless the admin asks for global.
- Importing straight into production. The subcontractor's calendar overwrites the company's. Sandbox database first; Keep Existing / Do Not Import in production.
- Deleting an EPS node to tidy up. Every project under it goes too, with its baselines. Move projects to an Archive node and set them Inactive; deletion is the admin's decision.
- Using EPS summary as a programme. The client asks for the "master schedule" and receives a summary of five unrelated projects with a critical path that means nothing. Inter-project logic needs a deliberate set-up, not a node.
- Resources created per project in the global pool. "Mason", "Mason (T1)", "Mason – Tower", "Masons" — four rows, one trade. Agree resource names with the admin before loading.
- No named owner. When nobody owns the enterprise data, everyone edits it. One name, written in the department's procedure, with the right to say no.
⚖️ When you're challenged
"The client wants their code names exactly. I need to create them globally." Create them as project codes with the client's names — project codes export with the same name and the client's database reads them identically. Global only changes what happens inside our database, and there it causes clashes.
"I can't see the project. Give me access." Access is by OBS, not by project. Your user needs the OBS node the project sits under — that's a five-minute change for the admin and it's the right way round, because it also controls who can edit the baseline.
"Just import the sub's file, I need the dates today." Ten minutes into the sandbox and you'll have the dates today. Ten seconds into production and every project on the database may have the sub's Fridays working.
📄 Related pages
- P6 Global vs Project Data — the same argument at object level
- Cleaning an XER Before Import — the sandbox and the import config
- Importing and Exporting XER — every import option and what it overwrites
- Setting Up a P6 Project — the project-level choices
- WBS Structure Design — the structure under the EPS
- Activity Coding Structure — codes vs WBS vs UDFs
- P6 Professional vs EPPM — where these structures are managed in each
✏️ Worked example
A contractor's database in Doha, 28 active projects. A planner on a mixed-use scheme imports a façade subcontractor's XER directly into production with default options. The file carried a global calendar named "Standard 6 Day" — the same name as the company's enterprise calendar — with Friday working and no Eid exceptions.
| Effect | Extent | Time to repair |
|---|---|---|
| Company "Standard 6 Day" calendar overwritten | 19 projects using it | Restore exceptions from SBM records, reschedule each, verify no date change via Schedule Comparison — 3 working days |
| 112 subcontractor resources added to the pool | Global | Delete after confirming no assignments — half a day |
| Global activity code "Zone" created alongside existing "Area" | 1 project | Re-map and delete — 1 hour |
| Monthly submissions for 4 projects delayed | — | Reputational |
The procedure written afterwards: one named database owner; sandbox database on every planner's machine; production import config saved as a template "Prod-Safe" (Keep Existing / Do Not Import, Delete unticked); transmittal note listing global objects in every outgoing XER. Cost of the incident: roughly 5 planner-days. Cost of the procedure: one afternoon.
📖 References
- PMI Practice Standard for Scheduling, 2nd ed.
- AACE International RP 38R-06, Documenting the Schedule Basis
- GAO Schedule Assessment Guide (GAO-16-89G), Best Practice 1
- Oracle Primavera P6 Professional User Guide — Enterprise Project Structure; Organizational Breakdown Structure; Global and Project Data; Import/Export (field labels as in P6 Professional v20; earlier versions differ)
From the field
Notes, corrections and additions from people who've done this on a real job. Everything is checked before it appears here.
Loading notes…
Checked before it appears. No client, project or employer names. Your name is shown; your email never is. Terms.