Project Management

Use these five tips when building your WBS

Using these techniques will save you time and rework on your next WBS.

A Work Breakdown Structure (WBS) is the best way to understand the detailed work of the project when you have to build a schedule from scratch. It's used to break the project down into the major phases, deliverables, and work components that will be built by the project. These work components can then be broken down into the activities that are required to build them. The WBS is not the same as the final schedule (which requires sequencing, resources, estimated effort, estimated duration, etc.)

Use the following five tips when building your work breakdown structure.

Create a WBS dictionary for large projects

Normally you wouldn't need a WBS dictionary, but if your WBS has hundreds (or thousands) of detailed activities, there may just be too much to keep track of by hand. In this case, it might make sense to place all of the important information in a WBS dictionary. The dictionary helps keep track of all of the summary and detailed activities, including a short description, the WBS numeric identifier (1.1, 1.1.1, 1.1.2, etc.) and the estimated effort. If you enter your WBS dictionary into a specialized tool, the tool can also help to keep track of changes to the WBS as well.

Use the summary activities as milestones

Your WBS should contain both detail and summary activities. (A summary activity is one that is broken down further. A detailed activity is one that is not broken down further.) Although a schedule usually includes only detailed activities, it makes sense to include the summary activities as milestones (markers signifying that a deliverable or set of deliverables is complete). A summary activity can be used as a milestone since it would indicate that all of the underlying detailed work has been completed.

Break activities into two or more detailed activities.

I've seen teams that break one activity in the WBS into only one activity at the next level. In my opinion, this doesn't make sense because then the detailed activity represents the same work as the prior summary activity. This doesn't buy you anything.

Make the final detailed activities action oriented

The detailed activities on your WBS (the ones that are not broken down further) are ultimately moved to your schedule. For that reason, it's easier if the detailed activities in your WBS are action oriented – just as activities in your schedule would be. For example instead of describing a detailed WBS activity as ""meeting," you should state it as "schedule a weekly meeting." Instead of having a WBS detailed activity for "Testing Plan," you should state it instead as "Create Testing Plan." In this way, the detailed activities can be moved to the schedule with a minimum of wording changes.

Don't place requirements on the WBS

If you place a deliverable on your WBS, you can break this deliverable down into the activities that are required to create it. You don't break a deliverable down into the requirements that describe it. Requirements do not belong on a WBS. Only deliverables and activities belong on the WBS.

Using these techniques will save you time and rework on your next WBS.

17 comments
joshnankivel
joshnankivel

Deliverables must be clearly defined, and a good practice is to specify in the dictionary what they do NOT include as well. The graphic should be short and sweet for visualization. The dictionary is necessary for people to have a common understanding of what "done" looks like for each deliverable. Josh Nankivel WBS Coach Instructor http://WBSCoach.com

ds
ds

Present the result in a good tool: www.wbs-tool.net.

sujith.kv
sujith.kv

It would be more usefull by giving a sample WBS dictionary for reference.

donblack747
donblack747

It is true that building a WBS Dictionary for a large number of tasks/WBS Elements can be quite a chore. What is important is to use a methodology that comes with a template that you can use to start your projects. Once you have done that, all the methodology content is already there for the tasks. Now you can modify this to create your project specific WBS Dictionary. The beauty of doing it this way is that you can reuse these for your next project. One such product that I like is Project Catalyst from 6D Tech Inc. www.6dtech.com The down side is that it is available only for Microsoft Project users. Hope this helps. Don.

herrmanso
herrmanso

Hi, I agree with 50% because: The mos frequent error with clients is the WBS-Network MIX. -ResumenActivities = Macro ACtivities as the WBS?s end : OK! -Activities = Deposit of Products/contracts are outside of the WBS. -One is the estructure (WBS), one the work (Act.) Especially with a Client with another/different WBS. Cut without destroy, mix without confusing! Regards! NelsonHM

hhall1001
hhall1001

Example WBS Dictionary 01 Requirements and Concptual Design 02 System Design and Development and Unit Testing 02.01 Database 02.02 Framework, Login, and Menu Structure 02.03 Data Entry User Interface 02.04 Reports 02.05 Utility Classes, special algorithms 02.06 Specify, procure, build and test servers 03 Integrated System Tests 05 On-line Help, User Manuals, Training Materials Development 07 Deploy,Test,Train 07.01 On-site system installation and testing 07.02 Training -A WBS is primarily a tool for organizing and managing the work on a project. That is its reason for being. -A WBS groups tasks by areas and sub-areas of work. Areas can be project phases, system modules, or anything that makes sense for organizing and managing a particular kind of project. Hope this helps, Cheers

osocram
osocram

There are 3 types of WBS: for products (WBS), for process (PWS)and organizational (OBS), a WBS is NOT for organizing and managing the work in a project, is for organizing and managing the products, or the process or the responsabilities for the people in a project.

galleman
galleman

hhall1001 suggests that the WBS contain system modules,, project phases or anything that makes sense for organizing a project. The use of Phases is probably not a good approach, since the WBS "should" and in most large project management systems "must" only contain "product deliverables." The inclusion of phases creates a disconnect between to description of "done." The WBS is a "product oriented" breakdown of the work. The schedule is where the "phases" would be defined.

Fairbs
Fairbs

I usually use a big roll of paper w/ stickies to capture the WBS. Working with the actual resources for the project is always helpful. I try to first have the group identify the high level deliverables at the top and then continue to divide the work into smaller and smaller tasks. I don't think there's general consensus around how far you break the work down. I've seen recommendations of no tasks should be greater than 40 hours of work or the tasks should be broken down to the level where they make sense for the particular resource (so an old pro wouldn't have to break the tasks down as much). As a PM, I facilitate the meeting and make sure easy to miss tasks or less desirable tasks aren't 'missed' (for example, transition plans to turn over to support or user documentation). The process of creating the WBS can also be iterative. I don't like to meet for more than an hour or two at a time. Additional meetings can be used to identify dependencies and to assign resources / time estimates to tasks. I usually create the schedule with MS Project. The results from the WBS creation meeting(s) are put into Project. The levels in the WBS can also provide great rollups for reporting to various levels of management. For example, your highest level could be at the overall project level. Project X is 48% complete. At the next level, you could see how much of each deliverable or phase or however it seems the best way to set up a particular project. This level oould be valuable to Team Leads or Functional Managers. At lower levels, the interest could be in percentage of an individuals tasks complete. So with that said, here's MY answer to your specific questions... WBS - Never makes it into an electronic format, but can be useful throughout the life of the project (don't throw away). Project Sched - MS Project w/ most data derived from WBS meetings. I think the schedule should show task level work (real work packages). A good book that is very practical on this subject can be found here... http://www.powells.com/s?author=Jeff%20Crow

william.yang
william.yang

WBS is all about the project activities/tasks that will be carried out to produce the project intermediate and final results. Usually we call these results as deliverables. So we'd better link the project activities and project delierables together to ensure all the project activities defined in the WBS are useful and value-added. That's also the way to combining and synergizing the process management and product management.

anna
anna

What formats do you recommend for the WBS v. the project schedule? Are these kept as 2 distincly different docs? Sometimes they seem to contradict each other, since the purpose of the 2 docs is so different. The developers I work with sometimes get frustrated when they don't see the work they're doing accurately represented on the project schedule. Any ideas?

PM_Chick
PM_Chick

Yes! They are deliverable-oriented, not schedule-oriented. The deliverable-oriented part provides the information necessary (via WBS) to plan and manage the project schedules, costs, resources, and changes.

PM_Chick
PM_Chick

Although the WBS is related to the schedule once the work package is defined and handed off for scheduling, in the WBS creation portion of a project it is NOT schedule- oriented. This is clear across the board in most PM forums. Thanks for your discussion!

herrmanso
herrmanso

Hi! The Schedule in the WBS is due to roll-up. The WBS element don?t act over the activities, is viceversa!. I can use 100 WBS with the same network (P3's activity codes)SAP-PS has two Schedule: 1 for Activities and another for the WBS. The first use the CPM algorithm, the second use the Roll up. Two techniques, two bodies. Good hunt NelsonHM

mhorlandi
mhorlandi

I agree totally with you. Schwalbe states in her book "Information technology Project Management", a WBS is a deliverable-oriented grouping of the work involved in a project that defines the total scope of the project. And this provides the basis for planning and managing project schedules, costs, resources and changes. Cheers,

hhall1001
hhall1001

It may be that we have a syntactical difference in the meaning of project phase. In my example WBS, 01. 02. 03. and 07 could be regarded as phases. I did not invent the concept of phases being in the WBS. Here is a quote from the PMI Practice Standard for Work Breakdown Structures (paragraph 2.2.1): "The upper levels of the WBS typically reflect the major deliverable work areas of the project or phases in the project life cycle." Galleman you confuse me with this comment: "The schedule is where the "phases" would be defined." It sounds like you are separating WBS from schedule. I believe that most organizations and the literature would agree with the following: A WBS structure is a hierarchical roll-up of project deliverables. Each descending level provides a finer level of detail. The lowest level is the work-package level. All tasks in a project schedule roll-up to a work-package. Since a WBS is a rollup of project tasks, I do not understand the comment. Another point, which may have been missed in this discussion, is that the WBS becomes part of the project management information system. Schedule progress is reported at different WBS levels to different levels of management. Cheers

kmurray
kmurray

Thanks for the excellent description. I like that you have described the WBS as "product oriented". If you can remember just that phrase before you write down a task, your WBS will be a lot more useful. Using phase names only sets yourself up for failure, because if you don't meet your deadline for the end of that phase, people start asking why. A "phase" is better described as one or two major activities with specific deliverables. Instead of calling one of your tasks your phase name "Requirements", you should be looking at the activities in that phase. For instance, "Interviewing users" and "Prepare Requirements document". It is much easier to explain to stakeholders where your delay occured (say, in a specific task under "Interviewing Users"), than it is to explain why you didn't meet the phase deadline for "Requirements".