work breakdown structure (WBS) is a tool used to graphically display the deliverables of the project in a hierarchical fashion. It organizes the work of the project into logical groupings similar to a milestone chart but displays the information in a tree form or an outline form.
work breakdown structure (WBS)
A deliverables-oriented hierarchy that defines all the work of the project. Each succeeding level has more detail than the level above it.
Note:Only the work of the project is included in the WBS. If the work is not included in the WBS, it's not part of the project.
Only the work of the project is included in the WBS. This may seem obvious, but if the work isn't shown in the WBS, it's outside the scope of the project and should be noted as such. This is an important distinction to make. Many projects suffer from scope creep, whereby the project seems to grow and grow the further you get into it. You no sooner have a list of deliverables and begin working on completing them when more deliverables are "discovered" and the deliverables you previously defined are modified or altered. Thus the scope of the project grows to a point where the original project estimates are no longer valid because the new requirements have added additional tasks to the project.
A phenomenon where the scope of the project changes over time because of lack of agreement on the original scope statement, not sticking to the original scope statement, or not having a scope statement.
If you've done a good job writing your scope statement and then depict that work accurately in the WBS, you'll go a long way toward eliminating scope creep on the project. This also implies that you've kept the project team and stakeholders focused on the original scope statement and have not allowed changes that would alter the scope.
Organizing the WBS Levels
A WBS is similar to a company organization chart or a family tree. It can also be shown in outline form, which we'll get to shortly. It starts out with the big picture, and each successive level gets more and more detailed. Like an org chart, it's a hierarchically oriented view that shows which tasks "report" to which dependencies. There is no set number of levels in a WBS, but I'd recommend not going more than five or six levels deep because the WBS will get bogged down in too much detail. If you're working on a large project you will have sub-project managers working with you who will be responsible for developing their own WBS from the project level WBS. We'll cover this in more detail at the end of this section.
Whether you choose the tree form or the outline form, the levels and organization of the WBS remain the same. The highest level of the WBS, level one, is the project level. The next level holds the deliverables or major milestones of the project. The succeeding levels are further breakdowns of the deliverables that may include tasks or groupings of tasks. Does this sound familiar? The deliverables are defined in the scope statement, and you defined the tasks in the task identification process. Now it's a matter of plugging them into the WBS. Keep in mind that for small projects you could skip the task identification process and perform it at the same time you're defining the WBS. Until you're experienced at this, though, you should break down the tasks first and then plug them into the WBS.
Remember when defining your WBS levels that deliverables are typically described as nouns or as past-tense events such as "PCs set up," "Brochures mailed," etc. Tasks, which are developed from the deliverables, are usually described as action words: create, develop, establish, and so on.
Level one shows the project name. This is always the first level in any WBS. Level two for this WBS shows some of the deliverables or milestones for this project.
Level three in this WBS shows a grouping of tasks, sometimes called summary tasks. For example, "Obtain PCs" is a summary task under the "PCs set up" deliverable found at level two. The "Obtain PCs" summary task at level three has tasks under it that must be completed in order to consider the "Obtain PCs" summary task complete. In order to complete the deliverable called "PCs set up," the two level-three summary tasks shown on the WBS, "Obtain PCs" and "Set up PCs," must have all of their tasks completed. The same is true for the other deliverables.
The idea is to start the WBS with the project and then continue to break down the deliverables into smaller, more manageable units in each subsequent level. These levels could include milestones, a grouping of tasks, or individual tasks. The idea is to keep adding levels to the WBS until you've broken the work out to the point where responsibility for each unit of work can be assigned to a specific person or to a team. This is also the level that allows you to easily determine estimates and the skills needed to complete these tasks.
A work package is the lowest level of a WBS. This is the level where assignments, estimates, and resources are easily determined. It doesn't matter whether the WBS has three levels or five levels; the lowest level in either case is considered the work package level.
The lowest level in a WBS. Resource assignments and time and cost estimates are established at this level.
In the WBS shown earlier, level four is the work package level. In that example, the individual tasks like Sign lease agreement and Arrange delivery are the work packages and are assigned to individuals or teams to complete. If we broke off the WBS at level three—in other words, if we didn't include level-four tasks—then level three would be the work package level.
Note:The lowest level in any WBS is called a work package. Work packages can be sub-projects, milestones, deliverables, or tasks, depending on how the WBS is structured.
Work packages may include individual tasks, milestones, or subprojects within the project. If you're working on a very large project, the project should be broken down into smaller subprojects rather than individual deliverables. Level one still remains the overall project, level two becomes subprojects within the project, and level three may also be subprojects within the subprojects, or this level might start the breakout of deliverables. In this case, level three is the work package level. Here is an example WBS with projects and subprojects.
In a structure like this, subproject managers may be assigned to the level-two subprojects. All subproject managers report to a single project manager who has responsibility for the overall project. Level-two subproject managers (also called assistant project managers) assign the level-three subprojects to teams or individual project assistants. At this point, the project assistants create their own WBS for the level-three subproject they've been assigned. For large projects, you can see that this could get rather complicated. However, the effort is well worth it in the end since you have a logical, graphical depiction of the project breakdowns in one place.
Once the WBS has been reviewed and approved by the project manager and project sponsor, it's a good idea to tape up a copy of it in the project team meeting room. And don't forget, a copy of the WBS should be filed in your project note-book for future reference.
You may have noticed numbers next to each of the WBS elements. These identifiers, or WBS codes, allow you to uniquely identify each element of the WBS. They're used to track the cost of the work, or the cost of each element in the WBS. They also serve as reference numbers to other planning information. As you begin assigning tasks and defining resource needs and such, you'll want to document some of this information (the act of documenting will become contagious over time), and the codes provide you a handy way to tie the information back to the WBS. For example, you might want to note that WBS item was assigned to the IT department. Maybe there are several costs involved with this summary task that you need to break out. That information can be recorded in the WBS reference document or WBS dictionary. The dictionary is created as a simple Word document or spreadsheet document that lists each WBS reference number down the left side with comments regarding that WBS element to the right. This document should be filed in the same section of your project notebook as the WBS.
Your budget officer will need these numbers as well to track the cost of the project. Depending on the WBS you've constructed, level-two and level-one elements are simply a roll-up of the costs from all the levels beneath them. These codes come in handy when using the outline view for the WBS. We'll look at that next.
There's one more version of the WBS you can use if you don't like the tree form. The outline form works well for small projects or projects that have multiple levels with lots of tasks.
This list shows a snapshot of the same information we saw in the first WBS graphic but in outline form. The WBS identifiers are especially important in an outline form because they help you easily determine which task goes with which deliverable.
When we do a fabulous job of documenting the deliverables in the scope statement and identifying your tasks, the WBS almost can't miss. If the scope statement is inadequate or the deliverables and task identification were poorly developed, the WBS will also be poorly developed. This will cost you in the end in the form of rework. Rework means that you have to go back and redo things you've already done or add tasks that you missed. And remember way back fromtopic, "Building the Foundation," that time equals money, so if you're involved in rework or you're adding new tasks to the WBS after it's been approved, project costs are going to escalate. Take the time to construct your WBS correctly and review it several times with the project team.
Tip:Don't be alarmed if you uncover new deliverables as a result of creating the WBS. Updates to the scope statement may occur two or three times throughout the Planning process.
Don't forget that as you create the WBS, changes to the scope statement may result. That's to be expected at this point in the project, so when the WBS is completed, go back through your scope statement to make sure all the deliverables are reflected there. If not, follow the procedures outlined in the scope management plan and update the scope statement to reflect the additions. (Don't forget to get sign-off on the changes.)
Project Management Related Tutorials
|Business Analyst Tutorial||Strategic Planning for Project Management Tutorial|
|Software Development Lifecycle (SDLC) Tutorial|
Project Management Related Interview Questions
|Business Analyst Interview Questions||Strategic Planning for Project Management Interview Questions|
|Network Monitoring Interview Questions||Software Development Lifecycle (SDLC) Interview Questions|
|Business process outsourcing (BPO) Interview Questions||Project Manager Interview Questions|
|PMP Interview Questions|
Project Management Tutorial
Building The Foundation
Developing Project Management Skills
Initiating The Project
Defining The Project Goals
Breaking Down The Project Activities
Planning And Acquiring Resources
Developing The Project Plan
Executing The Project
Controlling The Project Outcome
Closing The Books
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.