Hi there, my co-author and mentor Bruce Taylor and I were talking about the importance of using a WBS on your projects where and I told him a lot of PMs do not use it. He could not believe it. See, Bruce has been developing WBS Structures for his projects for years and was actually really proud of the work we put in to write it for our book. In our latest book Project Management Communication Tools, Bruce wrote the whole tool, and can’t believe people don’t use it. So, I asked Bruce if it was ok for us to share the tool here. He said sure. Here you go, comes right out of our book.
What is the WBS?
The work breakdown structure (WBS) ensures that the project includes and identifies all of the work items needed to complete the project successfully, without adding any unnecessary work elements. The WBS breaks down the work into manageable work packages. You use the WBS to define the total project scope. It can include the description, cost, time, risks, quality, resources, and scope for each activity (work package). Within each work package, the WBS helps customers and team members identify the project deliverables.
The WBS communicates all of the work on the project. It is a single repository that displays all of the information for every project deliverable. Having a single source saves time and effort from searching for project information, which potentially saves cost. The top level of a WBS shows the organization of work elements into larger categories of work deliverables. Every element in the WBS has a parent and child relationship that is easily identifiable.
Figure 7.2 — Project Level and Top Level of a WBS shows the top level (the project) and the major level (the phases). This is the first stage in developing and communicating a WBS. A “project management” element of the WBS should always appear on the left of the major project elements (Phase 1 in this example). In this project management element, project managers add their specific project management work items. The separate project management element ensures that you not only get credit for your project management activities, but running the project is included in the project’s scope. Many project managers do not understand this and therefore don’t create this separate element in their projects. That’s a mistake, and a quick way of not getting the right exposure for all the work you do on a project. By having the project management element on its own, your project management deliverables can also be separated from the main project deliverables, which is valuable. The timeframe for producing project management deliverables can be outside the project timing so you don’t end up pushing out the overall project finish date. For example, the time it takes to produce the project schedule does not have to push out the project finish date.
Figure 7.2 — Project Level and Top Level of a WBS
The WBS is helpful to all project team members. It graphically displays all of the project work items in a single chart. Each team member and stakeholder can refer to the WBS to understand what the project will deliver. It is also valuable to team members to help them understand what their work items are for the project.
The WBS provides details about each project activity, which may not be documented anywhere else in the project documentation. By developing a WBS dictionary, you and your team members identify work activities that belong to any part (category) of the project. The WBS dictionary contains all of the information about a work package (task). You communicate the WBS to the stakeholders and project team throughout the project life cycle. You will work continually to ensure that project activities complete on time and on budget. When project change requests occur, the new work items (tasks) become additions to the WBS.
The WBS should be a large part of defining, executing, and managing project changes.The WBS is the foundation for every project, regardless of size.
The following list identifies some of the benefits for using a WBS on your project. The WBS does the following:
- Identifies all project work
- Includes a project breakdown into specific work packages
- Includes a mechanism to roll-up items to a parent level
- Helps identify all project deliverables
- Supports activity estimates in time and cost
When developing a WBS, consider the following points:
- It is a systematic breakdown of the project objectives in a hierarchical format
- The project level is the project objective and the deliverable assigned to it
- The next level defines the major segments of the planned objective and deliverables
- Upper and mid-levels define a decomposition of the major segments into components
- Lower levels define the integration work to create each lower-level product
- By definition, the lowest level is the work package
- Each WBS element should represent a single tangible deliverable
- Each element should represent an aggregation of all subordinate WBS elements listed immediately below it
- Each subordinate WBS element must belong to only one single parent WBS element
- The deliverables should be logically decomposed to the level that represents how they will be produced
- Deliverables must be unique and distinct from their peers, and decomposed to the level of detail needed to plan and manage the work to obtain or create them
- Define deliverables clearly to eliminate duplication of effort within WBS elements, across organizations, or between individuals responsible for completing the work
- Deliverables should be limited in size and definition for effective control, but not so small as to make cost of control excessive, and not so large as to make them unmanageable or the risk unacceptable
The work package
A work package represents a work activity (task). Combining all of the work packages defines all of the work on the project. Only defined work falls in a work package. The work package description should always include a verb and a noun (for example, create the drawing, erect the steel, design module 6, and so on). Each work package communicates a deliverable to the project. A work package is the bottom level of the WBS.
A WBS dictionary is the document that defines and describes all of the work performed in each WBS element. The following list describes WBS dictionary characteristics:
- Sufficiently describes the project work, but does not need to be lengthy
- Includes forms or templates are helpful to all project stakeholders
- Uses formats at different WBS levels
- Contains enough description in each WBS element to produce a comprehensive statement of work
- Addresses all of the work that is scheduled to be performed
- Defines the entire project’s scope
Usually, the project team works on a single project only. They may work on more than one project at different times. Each single project defines the project at the top level of the WBS. The next level down (major level) identifies the type of breakout the project will have. The major level starts the main categories of a project. Below this level, the subcategories start, and then are broken down into more detail. For example, the major level could be broken down by location, resources, phase, system, subcontractor, or by module. The bottom level is the work package.
WBS functional levels
When you develop a WBS, there are many levels of summary and detail elements. Below the top level, you can have many varying levels under each one of the elements. You could have four levels under one element and seven levels under another element. There are four distinct levels of a WBS. The top level is the project level. The next level is the major level, which defines all of the major areas of the project, such as project management, phase, and module. All levels below the major level, except the work package level, are considered mid-level and are parents of the level below them. The bottom level is the work package level that lists project deliverables. The level definitions are as follows:
- Project level: Charter and project scope
- Major level: Project management, components, assemblies, subprojects, or phases
- Mid-level: Subassemblies
- Bottom level: Work package (tasks or activities)
WBS in a project management office environment
When you work in a Project Management Office (PMO) environment, you work with multiple projects. A PMO oversees managing the company’s or organization’s projects. The PMO group is responsible for the coordination, support, and policies of the company’s projects. In most PMOs, the reporting is the summary of the projects at the program level. WBS’s in a PMO environment roll up to the summary level for reporting to senior management.
Figure 7.3 — Example of a Program WBS with Three Projects at the Top Level shows a sample of a PMO’s WBS with the program at the project/program level and projects at the top level. Below the top (project) level in this example are various phases.
Figure 7.3 — Example of a Program WBS with Three Projects at the Top Level
In the early stage of a project, it may be feasible to develop only a two- or three-level WBS. This is because the project details may not be available and there is not enough information to go any deeper. As the project planning process advances into the project definition phase, work details become clearer. The subdivisions of the WBS elements are developed at lower levels. These final sub elements, the lowest level of work packages, are the detailed descriptions of the work performed on the project. The product of this decomposition process is the completed WBS.
Figure 7.4 — Example of a WBS Integrated with the Planning Process shows an example where the WBS integrates into the scope planning process. It is important to note that scope definition development and the WBS development occur at the same time. As you learn more about the scope, you can apply that information to the WBS. The WBS will then help develop the scope. They work hand in hand.
Figure 7.4 — Example of a WBS Integrated with the Planning Process
Figure 7.5 — Example of Work Packages in the Logic Network Diagramshows a sample of a WBS and the work packages that create the activities for a logic network diagram tool. Note the logic network diagram uses only the work packages, the bottom level of the WBS. The project schedule uses only the work packages to decide the start and finish dates for each activity that creates the project schedule. For example: Work Package “Design B1” in the WBS becomes activity “Design B1” in the logic network diagram.
Figure 7.5 — Example of Work Packages in the Logic Network Diagram
As you create the scope of your project, more detail is developed. These details become available to the WBS, and then are broken down to lower levels. In turn, the WBS supports developing the scope detail. If a team member starts creating or identifying work that is not in scope, it is important to remove those activities from the project. There should be no work included in a project that is not in the scope of work. If you do that extra work, you are adding value to the project that was not called for, and you are doing it for free. The owner will love it and you will not be happy because it takes unplanned time and budget away from the project.
Planning to use a WBS
Make sure the project team and stakeholders participate in WBS planning because the WBS is all encompassing in identifying and defining all of the project work. If possible, include the functional managers in the planning sessions too. Plan a short training class for those who have never used a WBS.
One best practice when working with the WBS is to set up some rules. These rules can include the maximum time (duration) or maximum cost a work package will incur, such as the work package duration lasting no more than one reporting cycle. Another rule could be that the cost is no more than a fixed amount and has a maximum amount of labor hours assigned to it.
Another best practice, as noted earlier, is to make sure that one of the elements on the second level is project management. This branch defines all of the project deliverables assigned to you.
Reporting from a WBS
The WBS is an important communication tool because, at one time or another, everyone who is working on the project will need information from the WBS because it describes all of the project work. Therefore, the WBS must be in an area where everyone can access it. WBS charts can become quite large, especially horizontally. Because of this, you often will dedicate an entire wall to display the WBS information.
Another way to report the WBS is through the WBS dictionary. The WBS dictionary is stored near the WBS chart and is accessible within the document control system. The dictionary includes more details to supplement the WBS. These two tools support one another.
A WBS is one of the most important tools, if not the most important tool, on the project.
Figure 7.5 — Example of WBS with Four Levels represents a four-level WBS chart. This is a typical WBS where the top levels represent team leaders and the mid-levels represent senior staff representatives. The bottom level, in this example, shows the actual workers in each subarea of the project. Remember, the mid-levels can be many levels deep. The WBS identifies the level and the position that need reporting. For example, team leaders report from their top-level position, so there will be three reports. If a detail report is required, the team members at the mid-level (or possibly the bottom level) will produce the report. You will report (weekly status reports, budget report, performance report, and so on) from the project levels.
Figure 7.5 — Example of WBS with Four Levels
Because the WBS is on a wall displayed in the project office, it is updated only when the project work changes, which will become less frequent as the project matures. Change orders will most likely change the WBS because they add work, which adds work packages. You update the WBS on demand, only when it is not part of a regular periodic reporting cycle.
What did you think? Do you want to rush out and start creating them on your project? You should, they give you a complete view of all the scope on your projects. One of the key tools I have used for years that you really do have to try is WBS Schedule Pro. It is found here at www.criticaltools.com and really will be the best investments you will make in your life around project management tools.
So the real question is whether or not a WBS is a project manager’s best friend and my answer is 100% yes! I could not manage a project without it!
Thanks for reading!
Bill Dow, PMP