WBS Element Missing From Project Structure

Project controller or planner reports that a work package they created, or one they were entering time and cost against last week, has 'disappeared' from the project structure. They open the project in the builder and the node is gone, or it appears in one report but not another, or costs posted to it show up in Controlling but the element itself cannot be found when they try to display it directly. Sometimes the complaint is narrower: 'the WBS element is there for me but my colleague on the same project cannot see it', which usually points away from a data problem and toward authorization or a personal display variant. Occasionally the report is that the element was there yesterday and is gone today, which raises suspicion of an accidental deletion during a structure change.

Start with the master record, not the tree display. Use SE16N on table PRPS filtered by project definition and element identifier to confirm the element physically exists and check its deletion flag and status fields directly; this settles in one step whether the problem is data or display. If it exists there, open the project in CJ03 or CJ20N without any personal filter applied and check whether the system status or user status excludes it from the active view. Compare what a second user with broader authorization sees for the same project, to rule out an authorization restriction. Run the structure overview report (CN41 or equivalent) with the date restriction removed or widened to rule out a period filter. Finally check the project definition on the element (PROJ) to confirm it is filed under the project the user actually expects.

Pull the WBS element master record from PRPS by project definition and element identifier and check the deletion flag and status fields directly against the database, bypassing any display filter. Cross-check the same identifier in the project definition table PROJ to confirm it is filed under the expected project. If the element carries cost, a Controlling line item report against the WBS element as the object will show postings even when the structure display hides the node, which proves the element is real and simply obscured.

If the deletion flag is set in error, reverse it in the project builder against the specific element; this is a data change on that one record, no transport needed. If a display or selection variant is filtering by status or date, correct the variant or widen the selection; this is a personal or shared reporting setting, not a configuration transport, unless the exclusion is baked into a standard delivered variant that many users share, in which case it belongs to whoever owns reporting variants centrally. If the root cause is authorization, the fix is a role or authorization object change through the security team, which does need a transport through the usual role change path, not a quick data fix. If the element was created under the wrong project, it has to be deleted from the wrong project and recreated (or reassigned, where the structure allows it) under the correct one; reassignment across project definitions is a structural change and should go through the project's change control, not an ad hoc correction. If a mass action caused the loss, restoring from the last consistent backup of the affected records, coordinated with Basis, is usually faster and safer than trying to manually recreate cost-bearing elements.

The reflex fix is to recreate the WBS element from scratch under the same number or a new one. This creates a second element with none of the original's cost postings, settlement rules, budget assignment, or network relationships, and it does not solve the actual problem: if the original element is still sitting there with a deletion flag or hidden by a status filter, the project now has two elements doing the same job, one visible and empty, one invisible and carrying the real history. Reconciling that afterward is far more work than checking the master record first.

First checked by the project controller or PS key user who noticed the gap, since they know whether the element was ever actually used. Confirmed and fixed by the PS configuration owner if it turns out to be a status profile or variant issue, or by security if authorization is the cause. The handover note should state the element's identifier, project definition, the deletion flag and status values found in PRPS, and whether any cost or budget was already posted against it before the fix is applied.