WBS, EPS & Types
WBS vs How the Job
A WBS is not an activity.
Two tables
P6 keeps the outline and the work in different tables entirely. PROJWBS holds the WBS nodes themselves — wbs_id, wbs_short_name (WBS Code), wbs_name, parent_wbs_id, proj_node_flag (the project itself is a WBS node), and seq_num. TASK holds the activities, and TASK.wbs_id is the foreign key pointing back to the owning WBS row, labeled by Oracle simply as WBS.
A WBS row is not an activity. Gantt summaries of WBS are rolled-up PROJWBS, not extra TASKs. Do not invent a TASK per WBS, and do not roll dates as if the WBS were an activity.
WBS Summary is still a TASK
Activity type can be WBS Summary. That is a TASK that rolls up a WBS. It is still a TASK, distinct from the PROJWBS node. How the job is built — durations, relationships, resources — lives on the activities, not on the outline.
A WBS is not a relationship and not an activity type. task_type is the activity type (task-dependent, resource-dependent, LOE, milestone, WBS-summary activity).
What lives on a WBS node
A WBS element carries its own General-tab fields, separate from anything on an activity: WBS Code and WBS Name, a Status, a Responsible Manager (the WBS element's own OBS assignment), and Anticipated Start / Anticipated Finish. Anticipated dates are manually entered, used only during project planning, and are not touched by scheduling — they only stand in as Start/Finish for a WBS when no activities have been added to it yet. Once activities exist under that WBS, its Start and Finish are the rolled-up earliest-start and latest-finish of those activities, and the Anticipated dates go unused.
Status is one of four values: Planned, Active, Inactive, or What-If. A WBS element with a parent inherits that parent's status.
Each WBS row can also carry one value from the organization's single WBS Category (PROJWBS.phase_id, default name Project Phase) — a single enterprise-wide tag used to organize, filter, and report WBS information across every project. It is not an activity code and not OBS; renaming the category does not change the values already assigned.
WBS milestones — a second, separate percent complete
A WBS milestone (XER: WBSSTEP) is a weighted checkpoint on a WBS element, not an activity and not a TASK milestone. Each one gets a weight (step_wt) and a completed flag. They can be used instead of activities to calculate earned value: when the WBS's earned-value technique is set to WBS Milestones Percent Complete, marking a milestone complete uses its weight to compute the WBS's performance percent complete — independent of how many activities underneath are actually finished.
Oracle's own example makes the gap concrete: ten activities under a WBS, five of them finished, but only one of four equal-weight WBS milestones marked complete — performance percent complete reports 25%, even though half the activities are done. Weighted differently (say weights of 9, 1, 1, and 1, with only the 9-point milestone complete), the formula — actual weight of completed milestones over total possible weight — reports 75%. Same activities, wildly different reported percent complete, purely from which WBS milestones got checked off. WBSSTEP has no date, relationship, or activity-linking column; it is a checklist with weights, not a schedule object.
Microsoft Project
Project has no separate WBS table and no LOE or WBS Summary activity type. Hierarchy is built by outline indent: an indented task becomes a subtask of the row above it, which becomes a summary task. A summary task's start and finish are normally determined by its subtasks — that is Project's nearest equivalent to a scheduled P6 WBS rollup, but it is still not a PROJWBS row and still not a P6 WBS Summary activity.
Manually scheduled summary tasks break that equivalence: Project will never change the dates of a manually scheduled task, so a manual summary's typed duration does not necessarily change when its subtasks change, and a red bar marks a child that falls outside the summary's envelope. Conversion usually turns PROJWBS into auto-scheduled summary tasks; a manual summary whose dates do not span its children has no live P6 analog. Same outline idea. Not the same object. Do not round-trip as if they were identical.
What it is not
A WBS node is not an activity, not a relationship, and not a percent-complete type. Do not compute Earned Schedule, float, or a look-ahead by treating a PROJWBS row as a TASK. A WBS Summary activity is still a TASK. A WBS milestone is a weighted checklist on the node, not a start or finish milestone on the network. See Activity Types and Milestones.
Must not
- Treat a WBS node as an activity.
- Compute Earned Schedule, float, or look-ahead by treating a PROJWBS row as a TASK.
- Invent a TASK for every WBS so the outline “has bars.”
- Treat WBS milestone weights as activity Physical % Complete, or WBSSTEP as TASKPROC (activity steps) — similar names, different objects.
- Treat Anticipated Start/Finish as live dates once activities exist under a WBS.
- Assume Microsoft Project stores WBS the same way P6 does, or that a manually scheduled MSP summary has a live P6 equivalent.