Program / Project Management | PMO | Training | Mentoring | Blog | News | Free Resources

Breaking The Work Breakdown Structure

Posted on | October 1, 2009 | 21 Comments

The work breakdown structure (WBS) is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables.

The WBS organizes and defines the planned work tasks of the project. How detailed should it be and how many levels should it have? The obvious answer is as detailed and as low as it can be scheduled, estimated, monitored and controlled, or it won’t be effective. You can have the most detailed WBS in the world but if it cannot be managed it will not work. So, depending on the project scope and project team (which include the project manager) it should be “just right”.

How do we get to an effective WBS?

• The project team must define the tasks

Project managers manage projects, the team performs the work and produces the deliverables; they are the ones who really know what needs to be done. Ask the team to define the activities needed to produce each deliverable (top-down approach) and then perform a peer review of the activities definition to ensure they are complete (bottom-up review)

• Rolling wave planning approach

Allows to, progressively, define tasks to be done in the future at a higher level while near term tasks are defined at their lowest level so work can start on them. As future tasks come closer they are redefined to their lowest level

• Stay within project scope

Ensure that deliverables and tasks to produce them are exactly what the project asks for. Producing more and/or better without stakeholders’ approval is nice but counterproductive

A simple example of a good WBS for a house painting project:

• Clean walls (this is a deliverable)

– Rent pressure cleaner (this is an activity/task)

– Pressure clean walls (this is an activity/task)

– Return pressure cleaner (this is an activity/task)

• Paint walls (this is a deliverable)

– Select paint color (this is an activity/task)

– Purchase paint (this is an activity/task)

– Purchase paint tools (this is an activity/task)

– Paint walls (this is an activity/task)

A simple example of a bad WBS for a house painting project:

• Clean walls (this is a deliverable)

– Inspect which walls need cleaning (this is an activity/task)

– Find best price for renting pressure cleaner (this is an activity/task)

– Rent pressure cleaner (this is an activity/task)

– Pressure clean walls (this is an activity/task)

– Return pressure cleaner (this is an activity/task)

• Paint walls (this is a deliverable)

– Find best price for paint (this is an activity/task)

– Look at different paint brands, types, shines and colors (this is an activity/task)

– Select paint brand (this is an activity/task)

– Select paint type (this is an activity/task)

– Select paint shine (this is an activity/task)

– Select paint color (this is an activity/task)

– Purchase paint (this is an activity/task)

– Purchase paint tools (this is an activity/task)

– Paint north side walls (this is an activity/task)

– Paint east side walls (this is an activity/task)

A WBS is not a schedule, and I am sorry if I disappoint some of you with this statement. Schedules are activity based and indicate what to do, when to do it and the order in which they must be done. This information is derived from the WBS. If you focus on the schedule while developing a WBS you will not develop a good WBS.

Once the WBS is built you may use a scheduling tool to produce the schedule. It will automate most manual scheduling tasks such as moving dates up or down based on effort, duration, dependency to other tasks, resources used, etc.

I believe that we have broken apart the work breakdown structure. Don’t you think so…? Well, I do.

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 4.00 out of 5)

Email This Article Email This Article


21 Responses to “Breaking The Work Breakdown Structure”

  1. Ray Almonte, PMP.
    October 1st, 2009 @ 2:20 pm

    Good article. I always stop the WBS at the point that a reasonable estimate can be obtained for each item in the WBS. This may include some high level tasks/activities, but certainly not at a very detailed level. These then become the summary tasks in MS Project, with the detailed tasks below them.
    The WBS is important to make sure you have not missed any deliverables. If it's not there, it won't be delivered.
    The schedule is a different artifact & has more to do with resource allocation, leveling & most importantly, when things will get delivered. It can be integrated with the budget to obtain costs & perform EVA, but that's a topic for another article.

  2. Bernd
    October 1st, 2009 @ 7:02 pm

    What I finds is missing is any discourse on why the example of bad WBS is bad … it's just left hanging without explanation. Perhaps I'm slow but the only difference i can see between the good and the bad is that the bad has more details and includes more broken down tasks. It leaves the question hanging (and it isn't answered explicitly in the preamble or subsequent text) why that is bad …

    The article fails to my mind, to deliver any concrete or practical exploration of what distinguishes good from bad …

  3. Aidan
    October 1st, 2009 @ 7:04 pm

    I agree with Ray, good article. I've always used the WBS as a means to an end. My team and I ask ourselves, what is the deliverable or action required. Everything beyond that is on the Schedule.

  4. chmengr (James)
    October 1st, 2009 @ 7:48 pm

    Sorry Bernd, I agree with Ray and Aidan. The article conveys what is necessary for an effective WBS, and suggests an over-detailed WBS as being ineffective.

    As a firm believer of 'the devil's in the details', the details are just as the author described, the schedule of activities to perform, to then achieve the deliverables of a well defined WBS. 'Keep it Simple Silly' is the best approach. Define what is necessary for the WBS and then schedule the activities to achieve each defined milestone.
    Great job Jorge!

  5. Jorge Dominguez, PMP®
    October 1st, 2009 @ 7:56 pm


    The point of the good vs the bad example is that the bad example is too detailed. If too detailed is manageable for you, then it would be fine, but for most PMs it is not.

    Thank you for your comment.

    Best regards,
    Jorge Dominguez, PMP

  6. Thierry
    October 1st, 2009 @ 8:39 pm


    I think that you have done a good work. You really specify what should and what shouldn't be in a WBS.

    It is a good tool to be used by PMs who are a little insecure with creating the WBS. You are right in saying that the team should build the WBS. A lot of PM have tendance to forget that point.

    Thierry Pagnier PMP

  7. Bernd
    October 1st, 2009 @ 8:52 pm

    My point was not that one is good or bad, nor that the only visible difference is level of detail, it's that the article is on complete with some exploration of that very fact, what is sufficient detail and why, and why is it that for example:

    Inspect which walls need cleaning

    is too much detail.

    I'm not saying it is or isn't. What I'm saying is that for one manager it may be, and for another it may not be, and simply to state that it is by way of a rough example without discussing why, is somewhat lacking to my mind for a robust a useful article.

    My immediate reaction is that if inspecting the wall is a significant job, requiring specific resources and skills (which for arguments sake it may well be), then it's got a very valid entry on the work breakdown structure.

    To my mind, while I can see the difference between a WBS and a schedule, it seems the article misses the opportunity to make clear that the WBS is used at least at my end, primarily for sizing the job, costing it. So criteria for LOD (Level of detail) and scope (content) that we use, are:

    1) Everything we know needs to happen
    2) Down to the size of job that produces our most confident costings.

    To me it seem all to relate to how far we go to generate our most confident picture of the actual project and its cost and likely duration.

    The schedule is the tool that comes next which arrays the jobs in time and can indeed include further task breakdown if it helps managing it personally or as a team.

    So while the article makes the point of an appropriate level of detail, it throws two hand wavy examples at me which don't explore what that means.

    The bad example, does not clearly contravene any of the three bulleted points on an effective WBS. It could have been compiled by the team, top-down and reviewed, bottom-up (point 1), support further rolling wave unfold of detail (bullet point 2) and be within scope (bullet point 3), so the question is left hanging, why is it a simple example of a bad WBS?

    My point is not that it is or isn't, but that the article fails to explore in a useful way for a reader why it's allegedly bad.

    The responses above all seem tome to[ come not from readers who would benefit form such an article, but from project managers who already know what Jorge is trying to say and agree with him, namely that it is possible, easy even, for a WBS to be too detailed, or more detailed than is useful at project outset anyhow.

    Sure. I got that, and don't disagree. The two examples help little however in exploring how to determine what is too much and why. That is all.

  8. Anonymous
    October 1st, 2009 @ 10:17 pm


    Do you also include the time (and cost) of a detailed WBS preparation in your project management costs?

  9. Bernd
    October 1st, 2009 @ 10:39 pm

    Of course!

    But equally clearly it's not part of the final WBS itself, though it can figure in first draft course WBS versions for scoping the project to begin with. Interestingly this touches on precisely the LOD (Level of Detail) issue. It's a real cost, and hence it is counted, in the worst instance retrospectively, and often that's the case (when summing up the project and expenses) but in prudent scenarios it is itself estimated early in the coping process.

  10. GrahamH
    October 2nd, 2009 @ 3:04 am

    Interesting discussion – and one that will go on forever I think. Perhaps there is a difefernce of opinion on the purpose of the WBS: is it used as a means of generating a schedule or is it (also?) used as means of tracking cost.
    To me, the latter is the most relevant pint, with the former as a by-product. What we need to do in the WBS is to identify which elements of the project we need to record time and cost against in order to monitor progress against time, budget and quality – effectively. For this reason, the detail in a schedule is not required in the WBS.


  11. ptermx
    October 2nd, 2009 @ 6:39 am

    I think Jorge's article does a good job of explaining the different functions of WBS and Schedule and how to achieve a good WBS.
    However, I also see Bernd's point which I think turns on the usefulness of the example WBSs. Whether a WBS is 'good' or 'bad' depends on how it was made and how it is used. You can't really tell from just looking at the WBS alone. Jorge's article might have been better with examples illustrating the creation and use of WBSs.

  12. Anonymous
    October 2nd, 2009 @ 7:42 am
  13. Abhijit Pradhan
    October 3rd, 2009 @ 4:19 am

    Overall Jorge has done good job in explaining WBS concept with brief writeup and example which everybody can understand.


  14. bonhamled
    October 3rd, 2009 @ 7:59 am

    it is important to notice that the breakdown level should be fitted to the management needs in order to be useful. More and more it is seen that very complex WBS only leads to a unsatisfactory use for management or simply to give up in favour of another not so developped ones.
    ON the other hand, WBS should be led to "project products", documents mainly that is why PMbok try to avoid the use of task. DOcuments are easy to control and it gives a effective and objective to control afterwards any work package.

    Congratulations for the article it is useful.

  15. Anonymous
    October 4th, 2009 @ 8:27 am

    Neither example really tells me what the project scope is. Yes, one is more "detailed" than the other but they are both constructed in exactly the same way and neither is a product WBS.

    But the point made is good … a schedule is not a WBS. The WBS drives the framework for the schedule, not the other way 'round.

    Just my two bits.

  16. Anonymous
    October 4th, 2009 @ 9:53 am

    To keep up on my last post (taking a break between my "clean basement" project on a Sunday morning) …

    It is not an exercise in semantics …. the "house painting project" can take someone off an entirely different tangent than "painted house project" … in real terms one must differentiate between the statement of work (paint the house) and the delivered product (a painted house)

    Indeed if level one of the WBS is the "painted house" then these kinds of things show up in level 2

    – paint
    – paintable wall
    – painting equipment
    – management of the project
    – "system engineering" of the projet (for example you may want to decide between renting equipment or buying it, subcontracting the cleaning or doing it youorself, etc)

    level 3, 4 + of the WBS takes each element even further, depending on the need for management insight. That can be for many reasons, not the least of which is perceived risk

    once you get into the ACTVITIES needed to get all those elements together at the right time & place & condition to get yourself to that "painted wall" then you have the makings of a schedule

  17. Anonymous
    October 5th, 2009 @ 3:32 am

    You are off base in trying to differentiate between 'deliverable' and 'activity/task'. Note that this documentation is not called a 'deliverable breakdown structure' but a 'work breakdown structure'… so you can see I disagree with the premise of your entire article. The high level descriptions are not deliverables, they are high level activities/tasks that, in order to be accomplished, require multiple sub tasks and activities. So, 'Clean the walls' is an activity' not a deliverable.

    The WBS's purpose is not to define the deliverables of a project (that is the task of the SOW or project charter and subsequent detailed extensions) but to define the work that must be done to provide the deliverables, AND, to define the work at a detailed enough level that the estimates of cost and time for the work can be considered reasonably accurate.

    Your example of a 'bad' WBS is inconsistent within itself. For example, you say that 'Clean walls' is a deliverable but 'Paint east side walls' is an activity/task. What's the difference? Are you saying that cleaning is an deliverable but painting is not? Or are you saying that 'east side' adds to much detail? It can be perfectly valid to distinguish between east wall and north wall, because the sub tasks required for each of these could be enormously different (maybe the north wall is hanging out over a 2000 foot cliff, while the east wall is only 6 feet high).

    Your definition clouds what a WBS is for and how it should be used. The WBS is not a schedule and you do not disappoint me with this statement, but if you do not put down EVERY work activity or task into the WBS your schedule will be worthless. Here's why… and a simple flow.

    a) The deliverable is specified in the SOW.
    b) The WBS specifies the tasks necessary to produce the deliverable.
    c) The resource allocation charts show the skill sets and people with those skills to accomplish the tasks.
    d) The resource estimates the time to complete the task.
    e) The hierarchical task list becomes the schedule (once dependencies are added).

    Separately, the equipment requirements for every work activity is prepared in order to develop costs to conduct the activity outside the personnel costs.

    So, I say things like 'rent pressure cleaner' must be in the WBS. You might just need to run down to the corner store in Milwaukee to pick one up but if I am painting a fire tower accessible only by helicopter, then 'renting' takes on a whole new dimension, which probably includes delivery.

    Summary: I'd rather see a PM produce a WBS with a high level of detail than a WBS that has too many assumptions built into it. Finding the best price for a pressure washer is relevant and takes time, and maybe you need to run the contract by legal before you can actually rent it. Your 'good' WBS is 'bad' because it does not include these tasks. Same for paint selection: Are you just going to let the type of paint be an uncontrolled variable in the project?

    Actually, a 'good' WBS would have the following for high level work activities.

    – Structural assessment (what needs to be done to meet the deliverable)
    – Prep activities (acquire cleaner, sprayer, paint, and personnel)
    – Execution activities (repair, clean, paint)
    -Clean up activities (clean paint off floors, return equipment, etc)

  18. Bernd
    October 5th, 2009 @ 6:34 pm

    Wow, it takes anonymous folk to agree that the article is a little short of useful ;-).

    I agree that a useful WBS should indeed include every job that needs to be done, and then some in our case here. The LOD (level of detail) is open for discussion, that is, how far we break it down. But the main driving factor is in fact what produces the most reliable and confident costings.

    It is often the case that for a task T say we have a reliable estimate, it is a task we have often done, and know how much it will probably cost (or better said we have bounds for that). If we break it down further into t1, t2, t3 etc … it often emerges that the sum of the t costs is less than T cost. Typically because there is work we've overlooked in the breakdown of T.

    Now if T isn't something we can confidently cost, then it falls upon us to break it down into t1, t2, t3, t4 … etc, which are activities we are more confident at costing.

    But this is why I said we will often break down the work into all its components and then some. There may be things we have to do on top of t1, t2, t3, etc …

    There are two ways I will compensate for this unknown. The first is to invite estimation of an integration cost on T. That is, what is the likely difference between the cost of T (a completed task) and the cost of t1+t2+t3+… (all the tasks we know we need to do to complete T)? This I term the cost of integrating T, you could use any term really (this one derives from the IT sector where I'm active).

    That is the first effort. The second is, through the estimation process itself. I am not entirely sure what purpose a WBS serves for you if it is not fundamentally to size the project and estimate the resourcing needs and likely cost and duration … it is in the end a tool for these not just something to generate for the love of it.

    In estimating it I request best case, most likely and worst case estimates from those who will do the work. If I have time I'll run an exercise to gauge their reliability (I ask them for 90% confidence, some deliver 90%, most 80%, some 50% and it's worth checking if there's time how your estimators work). In any case equipped with three point estimates for each task and decent work breakdown numerous PERT and variant methodologies exist for converting these in a consistent manner (given a targeted delivery confidence) to project estimates.

    My original critique of this article is that it makes a few hand wavy points about WBS and presents two examples claiming one is good and one is b ad, with not discourse as to why, and no clear answer why one should be better or the other worse. Leaving the reader to conclude (hesitantly) that one has more detail and that therefore detail is a bad thing.

    This might be a useful message to those whose vice is to provide and present more detail than is useful or the purpose. But it is far from a useful generality.

    Often fine detail is very empowering in the estimation effort. And the WBS exists at various levels of detail (LOD).

    To wit, I use to standard LODs for my presentations. There is a fine grained one used by my estimators and myself, and there is an aggregated one for my stakeholders, which has far less detail and much larger tasks.

    They serve to very different purposes.

  19. Anonymous
    October 31st, 2009 @ 4:07 am

    Hi, most of the points are almost being read in many other articles. However it was fine to revise them on this Blog.

    Just after going through few comments on which explains about processes involved in 'Time Management' Knowledge areas, it reminded me if you could have covered something on WBS Dictionary would have been completed this article on WBS.

  20. Anonymous
    February 24th, 2010 @ 11:52 am

    I happened to run across this older subject from 2009 when cleaning up my system. Let me clarify the position I have received from PMI relative to "work" versus "deliverables". I teach both views in my PMP Prep classes.

    According to the PMBoK (and PMI) the WBS contains only deliverables and stops when work is required to create a deliverable. The purpose of this is so that the recipient(client, customer, manager, etc.) can identify what will be placed in their hands that they have to sign a receipt for certifying that it meets the quality standards, etc. The recipient is responsible to verify that the WBS contains everything they expect from the project.

    After that the team identifies the activities that are subsequently extimated for time, cost and skills required.

    Now let's cover the realities and practicalities of the WBS. The majority of my clients don't follow the PMI guidelines. They include activities in their WBS.

    So – if you want real world the previous comments from others fit right in. If you want the PMI definition think only of deliverables.


    May 30th, 2013 @ 10:24 pm

    Thanks for a marvelous posting! I certainly enjoyed reading it, you could be a
    great author. I will remember to bookmark your blog
    and will often come back someday. I want to encourage continue your great job, have a nice holiday

About, the worldwide leader in program and project management services, blog, resources, and news.

Subscribe to our feed

Follow Expiriance on Twitter



(4) (7) (7) (2) (4) (5) (5) (15) (2) (5) (2) (7) (2) (5) (2) (2) (8) (4) (9) (2) (7) (2) (6) (16) (2) (4) (2) (2) (2) (5) (3) (3) (2)

Random Articles