Project Management

Please login or join to subscribe to this thread

Does a WBS include tasks?

linkedin twitter facebook   Estimating   Work Breakdown Structures (WBS)  
avatar
Benjamin Sumi San Diego, Ca, United States
I am currently pursuing my degree in Project Management and I have hit a bit of a snag here learning about Work Breakdown Structures. So much to the point where I figured I'd ask all of you for your opinion.

When it comes to the visual "tree" or a WBS in general, what should it include? Tasks and deliverables? Just deliverables and work packages?

The required reading for my class contradicted itself.

Rouse, M. from http://searchsoftwarequality.techtarget.co...kdown-structure said that the critical work elements (tasks) are expounded upon to illustrate their relationship to the project.

Then though, Icasas, P. from: http://explore.easyprojects.net/blog/2013/...-structure-wbs/ Says that the WBS "...contains deliverables, not tasks."

What seemed at first to be an easy enough concept has now gotten a bit confusing as these are not the only two references that are contradicting in regards to a WBS. Some say to include EVERY detail, others say don't include too much detail.

I guess what I really want to know is, can the term "task" have multiple meanings/definitions in regards to a WBS? Should tasks be included in a WBS? And what is considered too much detail vice too little?
Sort By:
avatar
Mario Trentim CEO| PMO Global Alliance Sao Jose Dos Campos, Sao Paulo, Brazil
Benjamin, I guess there is some confusion and different interpretations here. I don't know if there is consensus in the literature, but a WBS defines scope. It is a hierarchical decomposition of scope into deliverables and work packages.

You may check the Practice Standard for WBS (http://marketplace.pmi.org/Pages/ProductDe...ct=00100084701)

However, because software tools combine WBS and schedule, take MS-Project and WBS Pro for example, sometimes you see a WBS with tasks. But tasks are part of the schedule, there is a process for that, named "define activities", which is part of the project time management knowledge area (PMBOK Guide, 5th ed).

Anyway, the level of detail on a WBS depends on a variety of factors. You don't want very small work packages because that would overwhelm you in planning and controlling. On the other hand, you don't want very large work packages that people cannot estimate well (maybe people even don't know how to execute that large chunk of work).

There is a heuristics, the 8h - 80h rule. But it is not applicable to all projects neither to all work packages.
avatar
Praveen Malik Independent Consultant| Independent Consultant New Delhi, India
In the strict sense WBS is composed of deliverables and sub-deliverables. It is beneficial to decompose WBS as deliverables. However, it is not uncommon to see WBS comprising of tasks. For more details you can read the following two articles

5 Differences Between Work Package And Activity - http://www.pmbypm.com/what-is-the-differen...e-and-activity/

7 reasons to create WBS - http://www.pmbypm.com/7-reasons-to-create-wbs/
avatar
Benjamin Sumi San Diego, Ca, United States
Mario and Praveen,

I apologize, I usually reply sooner. Thank you both for your replies! The articles you both provided as well as your inputs have definitely helped me get a better grasp on how far the work should be decomposed in a WBS and what details should be included.

Sincerely,

Ben Sumi

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Of course I'm ambitious. What's wrong with that? Otherwise you sleep all day."

- Ringo Starr

ADVERTISEMENT

Sponsors