header photo

How to create a quality work breakdown structure to eat your elephant!

How do you eat an elephant?! 

Long time ago I was talking to a program manager and he was explaining to me the reason that the whole work of a giant refinery turnaround is divided to sub projects. He asked me:

  • “How do you eat an elephant?”

And immediately answered himself:

  • “Of course one bite at a time!”

Later, I learned that this is a famous statement in the project management world when we are talking about Work Breakdown Structure (WBS). Personally I don’t like this joke because I am a big fan of elephants and I don’t like to eat them! But of course, I am also a big fan of project management. I understand the concept behind this joke which is the reason for many project managers and planners to start with designing the Work Breakdown Structure as one of the first steps in approaching a project. Project managers use to split any big work to small manageable pieces so that they can easily manage them towards successful completion. Sounds logical, doesn’t it?

However, this concept is widely known in the project management world but sometimes the basic rules of designing a well-developed Work Breakdown Structure is neglected. That’s the reason that I decided to write this short article on how to write a high quality WBS for your projects. By identifying the core characteristics of a high quality WBS and some side rules that will help you to make your WBS more practicable.

What is a Work Breakdown Structure? [H1]

I guess you agree with me that we cannot talk about the characteristics of something before knowing what exactly it is! Thus, to answer the question about the characteristics of high quality WBS lets first see what is the definition of WBS.

PMBOK (5th Edition) introduces the WBS creation as one of the processes in project scope management and defines it as “a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables”.  

According to PMBOK, the Key benefit of the WBS creation process is providing structured vision of what must be delivered.


Sample WBS: Project decompositions for making a bicycle:

(Source:  PMI practice standard for WBS) 


The 3 core characteristics of a high quality WBS [H1]

Based on the definition of WBS that I mentioned above, three main characteristics for a high quality WBS could be identified:

  1. Completeness (also known as 100% rule of WBS creation) : WBS is a hierarchical decomposition of “the total scope”. Therefore, a well-developed WBS must cover all the works that needs to be done in order to have the project completed. 
  2.  Mutual Exclusivity: ​​​​​As the WBS is a “hierarchical decomposition” of the total scope, the Work Breakdown Structure should be in a way that allows an activity to be exclusively belonged to only one specific WBS element.  This rule could have two practical aspects:
    • WBS elements in same levels must have no overlap
    • Naming of the WBS elements need to be crystal clear and beyond any ambiguity to prevent any confusion.
  3. Deliverable Based: WBS must provide structured vision of “what has to be delivered”. Deliverable as is defined by PMBOK is every unique verifiable product or result that needs to be produced for having the project completed. Again, to comply with this requirement two sub-rules need to be considered
    • ​​These products or results of a project could be the “Main Deliverables”, “Internal Deliverables” or “Technical Deliverables”. Basically, these three levels of deliverables form the highest levels of the WBS.
    • Naming of the WBS elements must be a combination of noun and adjectives not verbs!

3 side rules to keep in mind which will make your WBS more practicable 

These are three main rules of WBS development. But besides these three core characteristics, there are another three items that need to be considered to have the WBS useable:

  1. Collaboration is key WBS development must be done with collaboration of the people who are going to use it! People who are doing the work with inputs from subject matter experts are the best people with full understanding of the project to participate in WBS development in order to ensure the quality of the final outcome.  
  2. Sufficient level of details: WBS is a tool for scope management and a communicating tool between the stakeholders. The level of detailing should be in a way that eases both these usages. To make it more specific, the level of decomposition should be in a way that:
    • Make it easy to control and track the project constraints (time, cost, scope, etc.) in the WBS level with a reasonable effort.
    • The intent of WBS elements is understandable for the project stakeholders and ensures clarity in communications.
    • Enables accountability assignment to the WBS elements so that the responsible party for providing the information and manging the sub-activities is clear for the stakeholders.
  3. Logical organization

A WBS needs to be logically organized to fulfil project management oversight requirement:  We should not forget that WBS is a project management tool! This is important to bear in mind because then at the end of the day, the WBS should be handy for the PM to have full oversight on the project status in different aspects. For example, for monitoring and reporting purposes, the structure of the WBS should be in a way that the progress in WBS levels gives meaningful indication about the status of the project.

Here I must bring up a practice from my own experience that may not be fully in-line with PMI practice standard for WBS development. Though, I think it is very important to have a logically organized WBS. PMI practice standard for WBS suggests that in WBS decomposition, timing and sequencing should not be considered.  Although I agree that this is the task we expect from project schedules and not the WBS, but we should not neglect the fact that the vast majority of the PMs in real world prefer to see the schedule formed based on the WBS. Therefore, in my opinion and practice, the structure of WBS needs to be in a way that eases the horizontal and vertical tractability of the schedule anyway; of course as long as it is not conflicting with the other expectations from WBS as project scope management tool. Sometimes it is a very challenging task to come up with such a WBS but still I believe it is crucial.


The above items outline the main characteristics of an effective, usable work breakdown structure. If you are in project management position or you are responsible for project planning and you need to develop a WBS, or if anyhow you are asked to evaluate the quality of the developed WBS, this list could be your starting point. To study more about this, I would suggest you refer to the Project Management Body of Knowledge (PMBOK 5th edition) and also the PMI practice standard for work breakdown structure (2nd edition). Also, please do not hesitate to leave your questions or comments under this post.

Good luck with your elephants!





Go Back