|Toggle All | Print Page|
The Work Breakdown Structure (WBS) organizes and defines 100% of the scope of project work to be accomplished and displays it in a way that relates work elements to each other and to the project's goals. The Project Management Institute's (PMI) A Guide to the Project Management Body of Knowledge (PMBOK) defines a WBS as a deliverable-oriented hierarchical decomposition of the work to be executed by the project team.
A WBS is not a project schedule. The WBS defines the “what” of a project and the project schedule defines the “when” and “who” of a project. A WBS uses nouns and adjectives to define work, not verbs; it contains no dependencies, durations, activities, or resource assignments. A project schedule uses verbs and nouns to define scheduled activities, outlines task dependencies, and resource assignments.
A WBS provides an efficient format for defining project work and for planning and tracking a project's progress. The WBS organizes the necessary work by decomposing it into smaller, manageable pieces that can be scheduled, cost-estimated, monitored, and controlled. Each level descending from the top of the WBS hierarchy represents an increasingly detailed definition of the project work to be accomplished.
The PMBOK defines decomposition as a planning technique that subdivides the project scope and project deliverables into smaller, more manageable components, until the project work associated with accomplishing the project scope and providing the deliverables is defined in sufficient detail to support executing, monitoring, and controlling the work. The lowest level of the WBS is known as the work package level.
- Identifying project deliverables
- Identifying work related to project deliverables
- Building a high-level WBS based on the above information
- Decomposing the high-level WBS into work packages
The resulting WBS can take a number of forms, one of which is:
- Major project deliverables and/or subprojects as the first level of the WBS
- Phases of the project life cycle as the first level of the WBS with the project deliverables inserted at the second level
- Combination of phases and project deliverables within each branch of the WBS
A WBS can be decomposed to any level of detail. However, three levels are usually adequate unless the work item at that level is still considered to be high-cost and/or high-risk. Then it may be necessary to further decompose the work of that specific item into additional, more manageable work packages. The WBS should be structured, at its lowest level, into elements that can be:
When developing a WBS, consider the relationship between WBS elements, project goals, and federal regulations and policies. For example, defining a WBS to the third level may be adequate for the project team to deliver on project goals. However, further decomposition may be necessary to meet federal regulations and/or policies regarding items such as:
- CPIC requirements
- Project Management
- Project Risk
- Enterprise Architecture (EA)
- Human Resource Analysis
- Performance Management
- Financial Management
- System Development Life Cycle (SDLC) Management
Developing the Work Breakdown Structure
The WBS is usually drafted jointly by the Project Manager, the project team, and the stakeholders. The process of developing a WBS is primarily concerned with defining outcomes or deliverables rather than the capture of action-oriented details, that may bloat the scope of the project with too much detail.
Depending on the size and complexity of the project and its WBS, the project manager may elect to develop a WBS Dictionary. The WBS Dictionary is a document that describes each component in the WBS; its content will vary depending on the complexity of the project. It is usually developed to the second level of the WBS and includes a brief definition of the scope or statement of work, defined deliverables, associated activities, milestones, and other information. It may include performance measurement criteria, statement of work paragraph number, contract line item, start and end dates, resource requirements, cost estimates, quality requirements, technical content, contact information, revision history, etc.
The length of and time invested in developing the WBS should be balanced with the size and complexity of the project. Large, more complex projects justify a significant effort in developing a comprehensive WBS.
Both the WBS and WBS Dictionary are living documents; any changes are best reflected in the documents throughout the life of the project.
- Product Elements – Do not include elements which are not product-related. The WBS addresses product requirements, not product functions or cost.
- Acronyms – Use actual system names and not nomenclature or acronyms to avoid confusion.
- Updates – As the project environment changes, updates in the form of project change requests should be reflected in the WBS and/or the WBS Dictionary.
- Reviews – Review the completed WBS and WBS Dictionary with the customer and project team before creating a schedule.
- Collaborate – The WBS and WBS Dictionary are developed by the Project Manager with collaboration with the project team, and the stakeholders.
- Define the scope of the project on the first level of the WBS
- Outline project management deliverables at level two of the WBS
- Decompose project deliverables into work packages, to a level that can be scheduled, cost estimated, monitored, and controlled
- Decompose project work packages into scheduled activities that can be used to build a schedule, estimate work effort, and assign resources
- Apply the WBS to schedule development and resource assignment
- Apply the WBS to, as needed, change control, risk, budget, cost, and communication management, etc.