WBS Rename False Positives in Schedule Comparison

Two Ways to Identify the “Same” WBS Node

Every WBS node in a P6 export carries an internal database ID and a human-assigned name, tracked in separate fields. The internal ID is what P6 itself uses to link activities to their WBS node behind the scenes -- but that same internal ID can differ between two exports of what a human reviewer would call “the same” schedule, for reasons that have nothing to do with the schedule’s actual content (a re-import, a project copy, certain administrative operations). The node’s name and its position in the WBS hierarchy are what people actually recognize it by.

Worked Example: One Rename, One False Positive

A 30-activity residential tower project has a WBS node named “Level 3 – East Wing,” holding 6 activities. Between two schedule updates, the scheduler renames it to “Level 3 – East Tower” to match a naming convention adopted for the rest of the building -- no activities move, no dates change, no relationships change.

A comparison that matches WBS nodes by internal ID sees two unrelated IDs and reports the old one deleted (taking all 6 of its activities down with it in the report) and the new one added as if it were an entirely new section of the project -- a section that supposedly went from nonexistent to fully staffed with 6 activities in a single update. That’s not just noisy, it actively obscures whatever real changes did or didn’t happen to those 6 activities, since they now show up nested under a “new” WBS node instead of being comparable to their prior selves at all.

Frequently Asked Questions

Why would a scheduler rename a WBS node mid-project?

Usually harmless cleanup -- correcting a typo, standardizing naming across similar phases, or clarifying an ambiguous label once the work it covers became clearer. It doesn't usually reflect any change to the underlying scope or activities at all.

Isn't matching by internal ID more reliable than matching by name?

It sounds that way, but it's actually the opposite for WBS nodes specifically -- the internal ID is exactly the value that's most likely to shift for reasons having nothing to do with the schedule's real content (a re-import, a project copy), while the WBS node's own name and its position in the hierarchy are what a human reviewer actually identifies it by.

Does this affect activities too, or just WBS nodes?

The same underlying issue -- internal database identifiers being unstable across exports -- affects activities as well, which is exactly why activity comparison needs to key off the human-readable Activity ID (task_code), not the internal task_id, for the same reason WBS comparison needs to key off name and hierarchy position rather than the internal wbs_id.