Planning Package
A planning package holds work under a control account whose scope and budget are known but whose detailed activities are not yet defined.
What this package holds
A Planning Package sits under a Control Account and holds work that is not yet decomposed in detail: scope and budget are known, but the specific activities and dates are not. In Rolling Wave Planning terms, it is where the far-wave work lives. When the wave approaches and information arrives, the planning package is decomposed into one or more Work Packages, and only then do schedules and owners attach. If the Work Package is the unit of execution, the planning package is the unit of waiting before execution.
Why it matters
It keeps the budget of undefined work from leaking outside the plan. Drop far-off work from the WBS because its details are unknown, and its budget and size are recorded nowhere — until it reappears suddenly late in the project. The planning package is the structural way of saying "details unknown, but the scope and the money are here." The 100% Rule also demands it: since a parent's scope must equal the sum of its children, even undecomposed work must occupy a slot and a weight for the total to hold.
Common misconceptions
A planning package is not a sloppy Work Package. The two differ in state, not in polish: a Work Package carries dates, an owner, and completion criteria, making it the object of execution and progress measurement; a planning package is not that object yet. If progress percentages are being entered against a planning package, the decomposition moment has been missed. The other mistake is leaving one open-ended: without a planned re-decomposition date it stays undefined until just before execution, and the rushed late split tends to produce estimation errors along with it.
In wbsgantt a planning package can live as a single undecomposed node, split into Work Packages when its time comes; the sibling-weights-sum-to-100 validation keeps the post-split allocation honest.