In Project Management, a Work Breakdown Structure (commonly referred to as WBS) is a tool intended to communicate and organize the project scope.

It is produced through decomposition, by subdividing the major deliverables and tasks into smaller, more manageable components recursively, until the lowest level tasks are granular enough for the intended purposes.

A WBS could be created to provide a common vision on the division of responsibilities or effort sizing, as well as to state that items not listed in the WBS are outside of the scope of a project.

Each item in the WBS is usually assigned a unique ID, which are collectively known as code of accounts. The lowest level items are known as work packages. The work element descriptions together form a WBS dictionary.

A WBS can be presented both as a diagram, or as a simple list (see below), and is useful and common at the planning (and later) stages of a project.

An example (somewhat artificial* and high-level) of a WBS for a generic waterfalled software project, presented in a list format:
1. FooBar v1.00
1.1 Project Management
1.1.1 Planning
1.1.2 Meetings
1.1.3 Reports
1.2 Product Requirements
1.2.1 Software Requirements Usage Scenarious UML Use Cases
1.2.2 Documentation Requirements
1.3 Software Design
1.3.1 System Architecture
1.3.2 Software Architecture
1.3.3 Database Design
1.3.4 User Interface Design
1.3.5 Object Oriented Design UML Class Diagrams UML Activity Diagrams
1.4 Construction
1.4.1 Software
1.4.2 Documentation
1.5 Testing
1.5.1 System Testing
1.5.2 Acceptance Testing
1.6 Deployment
1.6.1 Installation
1.6.2 Handover to maintenance

* I'm sure there's stuff to nit-pick, but it should be sufficient for illustration. /Msg me and I'll gladly correct it.

The Work Breakdown Structure (WBS) can be the basis for determining a development project's cost and schedule because it defines both the entire scope of the project and it provides detail at a sufficiently decomposed level to assign cost and time estimates. The cost and time estimates are assigned to appropriately sized components. The component-level estimates can be summed at each level until an aggregate estimate for the entire project is totaled at the top most level. This can only be accomplished if the WBS is both (a) comprehensive in defining the scope of the project and (b) sufficiently decomposed within that scope to components of manageable size.

The WBS is a work product of the scope definition phase of the project planning process. It is a diagram of the work to be performed in the project. The WBS defines the work that is inside the scope of the project and no work not stated in the WBS is to be performed as part of the project. The WBS describes the scope of the project in smaller, more manageable components to facilitate cost, time, and resource estimates.1

The WBS is a hierarchical diagram with several levels. (See the example of the numbered outline in the write-up by juu in this node.) Each subordinate level defines in greater detail the elements of the work to be performed. The number of levels in the decomposition will vary by project. In order to determine a sufficient level of decomposition, one software engineering textbook, Effective Project Management, provides six criteria. The lowest level of decomposition of the WBS is sufficient if each component at that level has the following characteristics:

  1. Measurable Status
    The component's progress toward completion can be measured in an objective manner.
  2. Bounded
    The component must have a clearly defined starting and ending event.
  3. Deliverable
    There must be some output to the component when it is completed.
  4. Cost & Time Determinable
    The component must be decomposed to a level that a cost and time estimate can be made with reasonable accuracy.
  5. Limited Duration
    The component must be able to be completed with in a reasonable period of time. The book suggests no more than two calendar weeks.
  6. Activity Independence
    After the component is started, it can be completed independent of other components or additional inputs until the activity is finished.
By meeting these criteria, the WBS becomes a tool for estimating the cost and schedule of the entire project. Determining cost and schedule are accomplished in the following manner:

Estimating Cost:

The key criteria of the six that provide confidence to the project manager's estimates of cost are items (2) Bounded, (5) Limited Duration, and (6) Activity Independence. Bounded and Limited Duration show the component has an explicit beginning and ending and can be performed in a limited time. The project manager can estimate the cost of the suggested 2-week duration because the component is sufficiently small.

Activity Independence provides justification for the project manager to aggregate the cost and time estimates of each component and sum these aggregates up the hierarchy of the WBS diagram. The components are independent of one another at each level. Therefore, there is no overlap between them in their activity or deliverable. So the project manager may aggregate with confidence there is no double counting of cost or time estimates.

Estimating Schedule:

The same three criteria and reasoning just stated for the cost estimate apply also to the schedule estimating process. Item (2) Bounded provides the key criteria for the schedule estimate. Each component is defined with a specific start and end event. Therefore, each component can be laid out sequentially in a precedence diagram with its sibling components. Criterion (5) Limited Duration directly provides the project manager with a length of time for the component to be completed. Thus a schedule can be determined from the sequential ordering of components and their individual time duration.

Again, the project manager may have confidence in this portion of the planning process because of item (6) Activity Independence. Each component is mutually exclusive of its neighbors and so there should be no overlap - no double counting - in the estimated schedule.


The WBS can be the basis for determining a development project's cost and schedule. If properly created, it is both inclusive of all the necessary work to be performed by the project and it sufficiently decomposes the project scope to small-enough components that reasonable cost and time estimates may be assigned. The costs may be aggregated back up the hierarchy to determine an entire project cost. The lowest level components may be laid out in a precedence diagram to provide an estimate of the project schedule.


  1. Project Management Institute, page 52


  • Project Management Institute, A Guide to the Project Management Body of Knowledge, Newton Square, PA: Project Management Institute, 1996.
  • Wysocki, Robert, Effective Project Management 3rd ed., Indianapolis, IN: Wiley Publishing, 2003.

Log in or register to write something here or to contact authors.