Work Package

A work package is the fundamental unit of project control. It sits at the base of the WBS hierarchy, below deliverables and sub-deliverables, and represents a discrete piece of scope that can be assigned to a single organisation or team, scheduled with defined start and finish dates, budgeted with a specific cost, and tracked for progress. Work packages roll up into control accounts (for EVM purposes) and control accounts roll up into the overall programme. The discipline of decomposing all project scope into work packages — and ensuring that every pound of budget and every activity in the schedule traces to a specific work package — is the foundation of integrated project controls.

The definition of what makes a good work package is practically important. A well-defined work package has a clear and unambiguous scope statement (documented in the WBS dictionary), a single responsible organisation or individual, a duration short enough to track progress meaningfully (the AACE guidance suggests 80-hour or two-week activities as a rough upper bound for detail activities), a defined deliverable or completion criterion, and a budget that can be earned against objective milestones. Work packages that are too large are hard to track; work packages that are too small create administrative overhead without proportionate visibility benefit.

A common mistake on major programmes is conflating work packages with purchase orders or contracts. A work package is a scope element; a contract is the commercial mechanism through which that scope is procured. A single contract may cover multiple work packages; a single work package may be split across multiple contracts. Maintaining the distinction is important for cost reporting: if cost is tracked only at contract level, it is impossible to see how individual scope elements are performing. The WBS should drive the cost structure, with contracts mapped to it — not the other way around.