- Introduction
- Organizing for Success
- Work Breakdown Structure
- WBS Numbering
- Scope Control and Change Control
- Consultants' Tips
This chapter is from the book
This chapter is from the book
This chapter is from the book
Work Breakdown Structure
After you have clarity on the goal, boundaries, and constraints for your project, it is time to begin the process of identifying all of the work by decomposing the goal into manageable pieces. Of all the projects that fail, most are due to a failure to identify all of the changes to scope or to manage these changes. The PMBOK Guide recommends the use of the Work Breakdown Structure (WBS) as the best practice for identifying and managing packages of work in a project schedule. The identification and management of these packages of work are critical to understanding and maintaining project scope.
This section covers key principles of building and using a WBS with a focus on creation of the WBS for accurate and effective management of Microsoft Project schedules. It is important that your schedule is an accurate reflection of the work required to reach a successful conclusion of your project. Using a WBS will help you reach that goal by ensuring you cover 100% of the scope of your project without adding activities that are not related. This book does not attempt to cover all of the details; there are much more thorough reference materials for that, as identified at the beginning of this chapter.
Work Breakdown Structure (WBS) Concepts
You can create a WBS using Project, but it is often more useful to create the first iteration on a whiteboard because it will change multiple times before you are ready to finalize it. The iterative process typically begins with a top-down decomposition of deliverables through successive levels of detail until you reach a level where the work can be planned and controlled. This level is called a work package. All levels of decomposition from Level 1 (the project) through the lowest level (work package) are noun-based and focus on the deliverable, not how the deliverable is achieved. Many levels may be required, depending on the complexity of the project, and not all branches of the WBS will require the same number of sublevels of breakdown. The lowest-level WBS element (the work package) will eventually contain the set of activities or tasks that need to be performed to accomplish the achievement identified by the work package. A work package should be able to be assigned to one work group or an individual for performance. If that cannot be done, it may not be broken out as far as it should be.
The example in Figure 4.3 shows the levels of decomposition that are used in a WBS to break a project into the appropriate work packages.
)
Figure 4.3 Work is decomposed to the lowest level needed for effective management and tracking (work package).
Decomposition of work into appropriate work packages and the associated activities for those packages can be reflected in Microsoft Project as well. The lowest level of the WBS—the work package—will be represented by a summary task. You should keep together all activities within that work package and link them with a starting and an ending milestone.
Figure 4.4 shows an example of a task activity list in Project that is derived from the WBS example in Figure 4.3.
)
Figure 4.4 Work packages within Project should have a starting and an ending milestone.
There are a few rules regarding building a WBS that you should keep in mind when developing a schedule in Project:
- Number of levels— The number of levels in a WBS will vary with the complexity of the project. Some elements may have more levels of detail than others. Elements are described with nouns and adjectives.
-
Level 2 elements— This level includes project management and at least one other element, depending on the type of deliverables to be produced by the project: product, service, or result. There may also be additional elements at Level 2 and below that support neighboring elements (cross-cutting elements) or represent the next step in a process. See Figure 4.5 for an example.
Figure 4.5 Level 2 elements include Management and at least one other element based on the type of deliverables that the project will produce.
- Level 3 and below (work package elements)— Decomposition continues as needed until the work package, the lowest element of a WBS, is reached. It must be at a level of decomposition sufficient to be controlled and performed by one individual or one organizational entity. A work package is broken into activities and tasks that are described with a verb (see Figure 4.5).
- WBS dictionary— Each element of a WBS may be described in more detail in a WBS dictionary. Additional information about the element, including budget, cost, and earned value data may also be included there.
- 100% rule— Each lower level of decomposition must represent all of the work of the higher-level element; conversely, all higher-level scope must be reflected in one of the lower-level elements. This is called the 100% rule, which ensures that all of the scope has been captured and that nothing extraneous is included.
)
As you can see from these examples, the WBS can be created in Microsoft Project or as a whiteboard exercise prior to opening a schedule. The Practice Standard for Work Breakdown Structures, Second Edition (PMI, 2006) recommends that the team be involved in the creation of the WBS. The focus for this process should be on the outputs to be produced so that the team uses nouns to describe what will be produced and can identify all of the cross-cutting elements that are required.
WBS and Scheduling
Regardless of the methods that are chosen to create the schedule, the process will be iterative. Some groups will choose to begin the process using top-down decomposition. Others may choose to identify all of the work they can using brain-storming techniques and then organize the work into logical packages. Either method is effective as a starting point. Multiple iterations of each method will be used before the team will be satisfied that all the work has been identified. It is important to remember that certain types of work, such as integration of elements, are often only recognized from the bottom-up view. Examples of this include assembly of components in a manufacturing project or quality testing in a software project.
The iterative nature of building a WBS, and subsequently a schedule, requires a great deal of realignment and reordering of elements. When developing and maintaining the WBS structure, it is important that you remember the 100% rule mentioned previously. You should maintain work packages as units and move them as units within the schedule rather than moving individual tasks below the work package. After you have identified the work packages, you can rearrange them, but you should have the same set of lowest-level work packages regardless of the realignment. Use the 100% rule to validate the process and always focus on the outputs of the packages rather than the resources required to do the work.
Figures 4.6 and 4.7 show examples of how work packages can exist in different locations in the project schedule. In this case, the work package called "Cabinets" exists under the Level 2 task "Surfaces" in Figure 4.6, and under the Level 2 task "Storage" in Figure 4.7. Remember, a work package is defined as the lowest level of the WBS; the tasks (activities to be performed) are broken out below the work package level.
)
Figure 4.6 Work packages can be aligned in different ways; use the 100% rule to verify the scope.
)
Figure 4.7 The "Cabinets" work package has been moved. If "Storage" existed as a Level 2 component in your WBS, this may be a more appropriate place for the "Cabinets" work package.
Avoid the tendency to define the work according to the groups that may be performing the work during initial decomposition because this will limit your thinking and make it easier to violate the 100% rule. Instead, focus on the work to be delivered and then assign it to a group as appropriate.
After the team is satisfied that all work has been captured and decomposed to the appropriate level, the WBS work packages are set to be the basis for adding precedence and resources and creating a schedule. The work packages should have starting and ending milestones to aid with work flow and to ensure that the focus remains on the production of deliverables. Refer to Figure 4.4 for examples of these milestones.
Use of Templates
Most organizations repeatedly deliver similar projects. Templates can be extremely useful for capturing the best practices developed into repeatable standards and reporting, giving new projects a jumpstart to success. The top two levels of the WBS can often be used consistently across an organization. The project management elements can be standardized, as can many other cross-cutting elements. Standard templates will minimize the amount of startup work required to determine process use for each project and will also improve the organization's ability to control scope on the elements that are consistent across projects.