Purpose
The Work Breakdown Structure (WBS) breaks down all the work to be done on the project into manageable pieces that can be estimated for time and cost. The WBS should represent 100% of the work defined by the project scope and captures ALL deliverables, internal, external, and interim, including project management. The WBS does not depict time or order of execution.
Templates
Work Breakdown Structure
Guidelines
Overview
Successful projects start with a good quality project schedule. The project manager must account for all the phases, milestones and tasks, so the project can reach a successful conclusion. In planning a project, it is normal to find oneself momentarily overwhelmed and confused, when one begins to grasp the details and scope of even a modest size project. This results from one person trying to understand the details of work that will be performed by many people over a period of time. The way to get beyond being overwhelmed and confused is to break the project into pieces, and then organize the pieces in a logical way using a Work Breakdown Structure (WBS).
A WBS is the hierarchical decomposition of a project into smaller components, organizing the project team’s work into manageable sections. Creating a WBS chart illustrates the relationships between the various components and the project as a whole. The work breakdown structure becomes input into the development of scheduled activities when creating the project schedule and project plan. A WBS is one of the most critical components of a successful project because it forces the project team to carefully consider all the pieces of a project.
Levels
When creating a WBS, the key objectives are defined at the top of the chart and are then broken into progressively smaller pieces. When completed, a well-structured WBS resembles a tree structure or flowchart, in which all components are logically connected, redundancy is avoided and no critical elements are left out.
Software development work breakdown structures are typically organized by process groups (initiating, planning, executing, closing, monitor and control) and should be further broken down by the system development life cycle (requirements, design, develop, test, release), for each deliverable. A typical software development WBS will be decomposed to 5 levels for some elements. For large, multi-phased projects, the WBS can be organized by process groups within each phase of the project.
An alternate method is to organize the WBS by major deliverables as the 2nd level of decomposition.
Work Packages
The elements at the lowest level of the WBS diagram, referred to as work packages, are small enough to be understood and carried out. Work packages are not as detailed as project tasks and may include several scheduled activities.
Decomposition may not be possible for a deliverable that will be accomplished far into the future. In this case the Project Manager will need to identify at a high level a placeholder and then wait until the deliverable is agreed on, so the WBS can be developed.
Creating a Work Breakdown Structure
- Assemble your team.You will need the people on the team who will be doing the work to be there and be actively involved in the creation of the WBS.
- Identify the major project deliverables from the Project Charter.Reference additional information from any Scope and Requirements documents that may exist.
- Identify a structure to use for the WBS. (Tree, Outline, Tabular)
- Start to decompose the deliverables down
- Use a whiteboard or use blank WBS Dictionary cards to collect all the decomposed work elements. (These will later become input into your project schedule.)
- Assign WBS numbers to all the WBS Dictionary Cards completed so that they reference the parent
- Once complete go back and check that all deliverables have been accounted for.
- Ensure that the following have been considered:
- Documentation, review and approval tasks associated with deliverables.
- Training and testing for implementation.
- Any IT Security or PPO related deliverables.
- Procurement activities.
- Compile and document the WBS information using the structure you selected in step 3.
Guidelines
- The WBS should represent 100% of the work defined by the project scope.
- The WBS should not include any work that falls outside the actual scope of the project.
- The WBS should capture all deliverables in terms of the work to be completed, including the management of the project itself.
- The sum of work at the “child” level must equal 100% of the work at the “parent” level.
- The WBS should focus on the project deliverables, not actions; what needs to be done, not how or when.
- The WBS does not depict time or order of execution.
- The work package level is the point at which cost and schedule for the work can be reliably estimated.
- Generally, a work package should contain between 8 and 80 hours of work.
- The level and detail of work packages may vary depending on the size and complexity of the project.
- Stopping the decomposition process at too high of a level will make the WBS meaningless.
Format I –Tree Structure
The Tree Structure view is the most popular format for the WBS. While using a Tree Structure view provides the clearest visual representation of a WBS, it can be more complex to create and update. MS Visio or other specialized tools are recommended.
Note this example is only to three levels.
Format II – Outline View
The Outline view shown below is the easiest WBS to build and maintain when using the Microsoft Word auto numbering feature.
- Widget Management System
-
- Evaluation & Recommendations
- Develop Project Charter
- Submit Project Charter
- Project Sponsor Reviews Project Charter
- Project Charter Signed/Approved
-
- Create Preliminary Scope Statement
- Determine Project Team
- Project Team Kickoff Meeting
- Develop Project Plan
- Submit Project Plan
- Project Plan Approval
-
- Project Kickoff Meeting
- Verify & Validate User Requirements
- Design System
- Procure Hardware/Software
- Install Development System
- Testing Phase
- Install Live System
- User Training
- Go Live
-
- Project Management
- Project Status Meetings
- Risk Management
- Update Project Management Plan
-
- Audit Procurement
- Document Lessons Learned
- Update Files/Records
- Gain Formal Acceptance
- Archive Files/Documents
Format III – Tabular View
The Tabular view is a nicely organized table view of the WBS. Both MS Excel and Word can be used.
Level 1
|
Level 2
|
Level 3
|
1 Widget Management System
|
1.1 Initiation
|
1.1.1 Evaluation & Recommendations
1.1.2 Develop Project Charter
1.1.3 Deliverable: Submit Project Charter
1.1.4 Project Sponsor Reviews Project Charter
1.1.5 Project Charter Signed/Approved
|
1.2 Planning
|
1.2.1 Create Preliminary Scope Statement
1.2.2 Determine Project Team
1.2.3 Project Team Kickoff Meeting
1.2.4 Develop Project Plan
1.2.5 Submit Project Plan
1.2.6 Milestone: Project Plan Approval
|
1.3 Execution
|
1.3.1 Project Kickoff Meeting
1.3.2 Verify & Validate User Requirements
1.3.3 Design System
1.3.4 Procure Hardware/Software
1.3.5 Install Development System
1.3.6 Testing Phase
1.3.7 Install Live System
1.3.8 User Training
1.3.9 Go Live
|
1.4 Control
|
1.4.1 Project Management
1.4.2 Project Status Meetings
1.4.3 Risk Management
1.4.4 Update Project Management Plan
|
1.5 Closeout
|
1.5.1 Audit Procurement
1.5.2 Document Lessons Learned
1.5.3 Update Files/Records
1.5.4 Gain Formal Acceptance
1.5.5 Archive Files/Documents
|