Program WBS

A program work breakdown structure (WBS) gives leaders a controlled, hierarchical view of the work needed to deliver the program. It does not reproduce every project task. Instead, it exposes only the project-level detail required to integrate, monitor and govern the program as a whole.

When to use it

• Use a program WBS when the program needs a common structure for scope, planning, reporting and control across multiple projects and non-project work.
• Align project managers and program leaders on where component scope rolls up and who owns each program-level element.
• Adapt the hierarchy to the governance model, benefits architecture and reporting decisions the program must support.

Context

A project WBS decomposes project scope into manageable deliverables and work packages. A program WBS operates at a higher level: it integrates selected levels from component WBSs with program management, transition, benefit-enablement and other cross-component work. Its depth should be sufficient for program decisions without duplicating detailed project control.

What it is

The template captures the core boundary:

Program WBS. An abundance of references address the topic of work breakdown structure (WBS) generation, so we do not discuss this topic here. A salient point, however, is that the program WBS typically includes only one or two levels of each project’s WBS—only enough to enable project tracking, monitoring, and control at the program level. The program WBS is discussed in related articles in this collection.1 in the Standard for Program Management—Third Edition (2013).

A program WBS is therefore a governing decomposition, not a master task list. Its elements should collectively cover the authorised program scope and provide stable points for assigning accountability, aggregating schedule and cost information, managing interfaces and connecting work to intended benefits.