A Work Breakdown Structure (WBS) is a decomposition of all the work necessary to complete a project. A WBS is arranged in a hierarchy and constructed to allow for clear and logical groupings, either by activities or deliverables. The WBS should represent the work identified in the approved Project Scope Statement and serves as an early foundation for effective schedule development and cost estimating. Project managers typically will develop a WBS as a precursor to a detailed project schedule. The WBS should be accompanied by a WBS Dictionary, which lists and defines WBS elements.
The goals of developing a WBS and WBS Dictionary are 1) for the project team to proactively and logically plan out the project to completion, 2) to collect the information about work that needs to be done for a project, and 3) to organize activities into manageable components that will achieve project objectives. The WBS and WBS Dictionary are not the schedule, but rather the building blocks to it. The progression of WBS and WBS Dictionary development is as follows:
The WBS and WBS Dictionary should not be static documents. WBS construction is subject to project management progressive elaboration, and as new information becomes known, the WBS should be revised to reflect that information. A Project Team that has substantial changes to its WBS should reference the project’s Change Management Plan for guidance on management of changes to project scope.
In a WBS, every level item has a unique assigned number so that work can be identified and tracked over time. A WBS may have varying numbers of decomposition levels, but there is a general scheme for how to number each level so that tasks are uniquely numbered and correctly summarized. Below is the general convention for how tasks are decomposed:
• Level 1 – Designated by 1.0. This level is the top level of the WBS and is usually the project name. All other levels are subordinate to this level.
• Level 2 – Designated by 1.X (e.g., 1.1, 1.2). This level is the summary level.
• Level 3 – Designated by 1.X.X (e.g., 1.1.1, 1.1.2). This third level comprises the subcomponents to each level 2 summary element. This effort continues down until progressively subordinate levels are assigned for all work required for the entire project.
If tasks are properly subordinated, most project scheduling tools will automatically number tasks using the above convention.
WBS CONSTRUCTION METHODS
Although there are different methods of decomposing project work and creating a WBS, the most straightforward and effective way is to use some form of visual display of the deliverables, phases, or activities. Ideally, all Project Team members will convene and brainstorm all work required to complete project deliverables successfully. Involvement of all team members in this process increases the likelihood that the resulting WBS will be comprehensive. Typically, team members start by identifying all project deliverables or milestones and then decompose them one at a time into a detailed and sequential list of the detailed activities required to complete the deliverable or milestone. One way of visually conducting this process is by using post-it notes to represent each deliverable and sub-activity.
• Deliverable-oriented WBS
• Process-centered WBS
A deliverable-oriented WBS is built around the project’s desired outcomes or deliverables. This type of WBS would likely include the following characteristics:
• Level 2 items are the names of all vendor project deliverables that are expected to be required as part of a contract. Level 2 should also include any agency deliverables tasks.
• Level 3 items are key activities required to produce the Level 2 deliverables.
• Additional levels are used depending upon the magnitude of the deliverables and the level of detail required to reliably estimate cost and schedule.
• In the deliverable-oriented WBS, all deliverables are identified, and all work is included.
Statewide projects procured as Firm-Fixed-Price contracts are well suited to the deliverable-oriented approach. Organized this way, project managers and agency management can review interim progress against deliverables and easily determine the percentage of the work that is complete. Sometimes, a deliverable-oriented WBS and its associated schedule can be confusing to read because their items are not organized sequentially at the highest level. They are, however, very useful in demonstrating progress against contracted deliverables.
A process-centered WBS is similar to a deliverable-oriented WBS except that it is organized, at the highest level, by phases or steps in a process rather than by deliverables. The benefit of using a process-centered WBS is that it encourages the inclusion of process-required deliverables, such as System Development Life Cycle (SDLC) deliverables. Regardless of the type of WBS employed, project teams should ensure that all contractual and SDLC deliverables are accounted for in the WBS. A process-centered WBS typically includes the following:
• Level 2 activities are phases or schedule checkpoints/milestones. These activities could be SDLC phases such as Initiation, Planning, etc.
• Level 3 activities are those activities required to complete Level 2 phases or milestones. Multiple tasks are included for any work that needs to be done in multiple phases.
• Additional levels are used depending on the duration of the phase or schedule and the level of detail required to reliably estimate cost and schedule.
• In the process-centered WBS, all deliverables are identified, and all work is included. This comprehensiveness will reduce the risk of “off balance sheet” work tasks, which might have unexpected impacts on the project schedule.
HOW MANY LEVELS?
Two industry-standard methods exist for determining how many levels a WBS should have:
• Traditionally, the Project Management Body of Knowledge advocates a predetermined seven-level model, which has the advantage of clear labels and definitions of each level (e.g., program, project, task, subtask, work product, and level of effort); the disadvantage to this model is that it requires a level of detail that may be unnecessary. Models/methods with predetermined levels and level definitions make clear what information needs to be included and where, but they lack flexibility.
• The more contemporary approach is to let the project characteristics dictate the number of levels used in the judgment of the Project Manager. It is a good practice to identify the number of levels to be used so that a project maintains consistency when building the WBS. The number of levels must be sufficient to allow the Project Manager to reliably estimate schedule and cost and effectively monitor and control work packages.
HOW MUCH DETAIL?
The WBS should be sufficiently detailed to allow the Project Manager to reliably estimate schedule and cost. One point of view is that the lowest level of project detail should be no more than 40 total hours of work and should be assignable to only one person. This level of detail allows the Project Manager to easily assess what project work is complete, who is responsible for executing what work, and what tasks are at variance with the baseline plan. Another good measure is the “8 – 80” rule, which recommends that the lowest level of work should be no less than 8 hours and no more than 80 hours. Level of detail for work packets should be documented in the WBS Dictionary or the Project Management Plan.
SAMPLE WBS DICTIONARY
As the Project Manager and Team discuss and define the WBS and address how many levels and how much detail should go into the WBS, the Project Team should create a WBS Dictionary to capture task characteristic information, including task names, work products, level of effort, resources, dependencies, and others. The WBS Dictionary should be consistent with the WBS. The information captured in the WBS Dictionary will help the Project Manager to later develop the detailed baseline schedule.
The key to a good WBS and WBS Dictionary is the engagement of project team members to comprehensively identify and discuss activities for the project. A Project Manager must ensure that all the work that needs to be accomplished for the project is contained within the WBS Dictionary and is understood by team members. All work should have clearly defined duration, resources, dependencies, and level of effort. A Project Manager should elicit feedback from all team members to ensure that the WBS and WBS Dictionary are valid and comprehensive prior to developing the detailed schedule.