It is hard to imagine larger projects without it: the work breakdown structure (WBS). It is a powerful tool for setting up even complex projects in a clear and structured way.
In this article, we answer many key questions regarding the work breakdown structure which people keep bringing to our attention. These are the topics to which you can look forward:
- Work breakdown structure definition
- What are the origins of the WBS?
- Work breakdown structure – Template and software example
- Work breakdown structure – Advantages and disadvantages
- WBS as a tool for whom?
- Key principles for the WBS
- Options for structuring the WBS
- Approach to creating a work breakdown structure
- Creating a work breakdown structure – Step by step
- Work breakdown structure and agile projects – Are they compatible?
- Conclusion – Work breakdown structure
Let us get started.
Work Breakdown Structure Definition
The work breakdown structure (WBS) is a proven method for communicating with stakeholders. It helps divide the project into sub-elements that are easier to plan and creates a shared understanding of the project in the project team. The WBS expresses WHAT will be done in the project (but not when or how long it will take – that is the purpose of the project plan).
Usually, the work breakdown structure encompasses the complete presentation of a project on only one page if possible – at least in aggregated form. It shows all sub-projects, (higher-level) work packages and often also all tasks. Thus, it is clear from the beginning what needs to be done or rather delivered.
A WBS can also contain information regarding cost, efforts, responsibilities and additional information in textual or numeric form. Here, numerical values are often aggregated across the different levels.
Our tip: Set up the levels of large WBSs in a way that allows you to show and hide them. This makes it possible to tailor the overview to the respective communication. Thus, you provide orientation as well as an overview – and that is what matters.
What Are the Origins of the WBS?
Historically, the work breakdown structure originates in the US military. It was intended for the construction of planes and weapon systems.
In the 1980s, the Project Management Institute (PMI®) adopted the term and created a general standard for creating a WBS in project management: the “Practice Standard for Work Breakdown Structures” (free download for PMI members, otherwise available in bookstores).
To learn about WBS in Planisware check out our Planisware Enterprise Tutorial.
Work Breakdown Structure – Template and Software Example
A work breakdown structure is particularly easy to understand when presented in graphical form. If you often have similar projects, you should save a work breakdown structure template in a central location. It may also make sense to standardize only the first two or three levels. This ensures comparability. Within a predefined structure, you have the option to go on to plan individually with work packages and activities.
For instance, your PMO can provide work breakdown structure templates for the PPM tool you use as templates for your company. Thus, there are tools that interact with tools such as Microsoft Project, for example WBS-Chart PRO.
An alternative are many work breakdown structure templates in Excel, Word or PowerPoint available for download on the Internet. Since these programs are not real project management tools, creating a work breakdown structure with them is less convenient than with project management software.
It is also possible to structure topics in sub-branches with mind maps.
You do not have to use a numerical code, but it can be useful in larger projects to improve the overview and the communication.
No matter what work breakdown structure software you use: used right, this “plan of plans” will give you as a project manager a clearer overview of various aspects of your project.
Work Breakdown Structure – Advantages and Disadvantages
The work breakdown structure is both an important planning tool and the basis for project communication with relevant stakeholders – internal as well as external. A multi-page bar chart, even when it is well-structured, is never as good for discussing content as a graphical work breakdown structure.
A few other advantages you will have from a work breakdown structure are:
- Better overview of larger projects
- Comparability of plans for several projects
- Greater reliability for more complete plans
- Assistance for project managers, for example through templates
- Easier reporting both for the overall project and for the current activities
- Improved planning of dependencies
- Simplification of handover situations
- Easier resource management
- Better allocation of areas of responsibility
- Better budget planning and cost control
- Coding can simplify orientation in the project (see figure above), modern software solutions can assign the code automatically according to the structure (see figure below).
There are no actual disadvantages of a WBS. (Possibly only that the creation takes time ;-), but the advantages outweigh this several times.)
WBS as a Tool for Whom?
In smaller projects, at least graphical work breakdown structures are less frequent. In this case, they would often be administrative overkill. Still, every project needs to be structured neatly – irrespective of the presentation.
The WBS is also a key component of program management.
As a project manager of larger or more complex projects, however, you will often lose track fairly quickly without a graphical work breakdown structure. And that even though you are meant to have everything in view, especially in this role. In general, a WBS can be used to advantage for projects in all industries.
Our tip: Consider basing your planning on a WBS as soon as your project’s bar chart takes up more than two screen pages.
Key Principles for the WBS
Several key principles for work breakdown structures have been from their inception until the present day:
- Fragmentation as a tool
Breaking down content of the project into smaller units is an indispensable technique in WBS creation. Thus, it makes sense to acquaint yourself with this method (see also specific approaches further below). - Singularity
No WBS element may appear a second time with the same intention. - The 100% Rule
A WBS should reflect the project structure as fully as possible and not just parts of it. - Separation of work packages and activities
Work packages are the lowest level of a WBS (see graphic above). Activities in the project, i.e., actual work items, are assigned to work packages but are not themselves part of the WBS.
Our tip: Create your WBS as a team. This makes it much easier to actually think of all the tasks that need to be done. In addition, this carries the advantage of involving the team in planning at an early stage which will strengthen the identification with the project.
What Options for Structuring the WBS Are There?
Both practical application and specifications by DIN standards result in the following customary structuring options:
1) Phase-Oriented Work Breakdown Structure
A phase-oriented work breakdown structure is a very common structure type. It structures the project according to the project phases (see first graphic named “Phase-oriented work breakdown structure”).
Since as a project manager you also have to keep an eye on scheduling, this structure type is often recommended. It allows you to bridge across all deliverables and thus come across the key planning points between stakeholders.
2) Function-Oriented Work Breakdown Structure
A function-oriented work breakdown structure is appropriate where teams from different functional areas take on different aspects of the project and assist each other. A disadvantage is that it is harder to identify dependencies because all teams have their own branch.
3) Object-Oriented Work Breakdown Structure
An object-oriented work breakdown structure is used when the structure is concerned with the individual components of a product to be combined. For example, this could be a building or a plane. Such a structure is conceivable also for websites:
The last two examples only work if the timing of the project work is less relevant. To begin with, the focus is on the content overview. In the course of the later detailed planning of activities, the timing aspect and dependencies become crucial, however.
Depending on the industry, different structures can be appropriate.
Our tip: It is important for you as a project manager to pick a form of the work breakdown structure that will provide you with a good basis for planning. If the structuring priorities of your stakeholders differ from your own, you can give them more consideration in reports. The WBS’s main purpose is to make your work easier.
Interested in reporting? Learn about the Project Status Report.
4) Structuring Combinations in the Work Breakdown Structure
You can also combine different structuring approaches. Only make sure you avoid breaks in logic.
The fact that the sub-elements in the example above represent repetitions is not contrary to the singularity rule: At first, the design tasks for these aspects are meant, later the development tasks and other ones.
Approach to Creating a Work Breakdown Structure
Once the structuring approach is defined, you will need to decide on a breakdown method.
There are the following techniques:
1) Top-Down Approach
In this case, you begin by defining the upper levels of the structure and slowly work your way down to the detailed planning. The individual work packages are the last logical step.
This approach makes sense if you are already familiar with the aspects of the project and may be able to draw on experience.
2) Bottom-Up Approach
Here, you work your way up from the work packages. In this process, the task is to find out exactly which relationships can be established between which aspects.
This approach is suitable for (agile) projects in which “the path emerges while walking” – i.e., innovation is required and permitted.
3) Yo-Yo Approach
This is where you “jump” back and forth between top-down and bottom-up: for example, by creating a rough structure and formulating the work packages, you consider the necessary intermediate steps to connect them.
Creating a Work Breakdown Structure – Step by Step
How do you best approach creating a work breakdown structure? Where should you start? Below, the individual steps are listed:
Step 1: List the areas of responsibility in the project. This works best with brainstorming or by surveying stakeholders.
Step 2: Structure the tasks depending on the chosen structure type either top-down, bottom-up or jumping (“yo-yo”) as described in the previous chapter.
Step 3: Group into work packages, following a consistent logic.
Step 4: Assign responsibilities (not resources) to work packages.
Step 5: If scheduling is to be considered in the WBS (which it does not have to be, see above), you can now add key data for this.
Step 6: Finalize the overall plan.
For the entries in the individual levels, you can choose from the following categories among others:
1) Higher-Level Work Packages / Summary Tasks
Work packages are not always distinguished clearly from Summary Tasks. Strictly speaking, work packages are always thematically related, unlike Summary Tasks.
Summary Tasks on the other hand can also be the grouping of several tasks that take place at the same time. This distinction can be helpful in the planning discussion, but it has no bearing on the presentation. Since activities are grouped into phases or objects here, they should be formulated as nouns in conjunction with verbs. So for example “CREATE SPECIFICATION”.
You should not assign resources at this point, only responsibilities.
2) Milestones
Milestones mark important achievements in the project. They are often associated with handovers and deadlines. Graphically, they are often depicted as a diamond and always have a duration of 0.
For milestones, it is best to use nouns in conjunction with participles (“SPECIFICATION CREATED”).
In this case, you should not assign resources directly to them either, but you should assign responsibilities.
Learn more about TPG’s free Milestone Trend Analysis tool.
3) Tasks / Activities
These are individual work tasks as nouns combined with verbs (“CREATE SPECIFICATION”). In this case you can assign resources and add details, for example with the aid of fields provided for this purpose. This is the level on which the completion message occurs which can also be presented graphically.
Please note that the structural elements of a level must be completely different from each other in terms of content. Therefore, the level of detail at a particular level is very important and should remain the same throughout.
For the presentation of work breakdown structures, the tree structure (like in the graphics above) has established itself. But the text form is also possible. In any case, it should be as comprehensible as possible.
Our tip: Save the first and second levels of your work breakdown structure as a basis for later comparisons. As a rule, not too much will change in them during the course of the project – as opposed to the lower levels and especially the activity level.
Work Breakdown Structure and Agile Projects – Are They Compatible?
Naturally, projects meant to be implemented with agile methods do not pursue clearly specified goals. Thus, it can be difficult to create a WBS or the latter would presumably have to be changed more often.
Hence, a work breakdown structure is rather uncommon in agile teams. These tend to focus strongly on results-oriented product development. They also prefer to engage with product planning rather than project planning.
In agile projects, the Product Backlog remains a list of requirements to be fulfilled. Usually, its structure has nothing to do with a WBS. However, it can also be structured of course.
The lowest planning level are individual iterations backlogs. This is where teams plan actual tasks, similar to the activity list in traditional project management. However, they are self-organized in this respect and do not receive instructions from project management.
Agile software development methods such as Feature-Driven Development were looking for solutions to link traditional long-term planning with agile flexibility some time ago.
This gave rise to the idea of feature-driven software planning. The breakdown is made with increasing levels of detail:
- Feature
- Version
- Epic (as a thematic grouping of different User Stories)
- User Story (lightweight requirements from the user’s perspective)
- Task (actual tasks, especially at technical level)
Depending on the industry and type of project, similar structures are possible. Many agile teams may try to get by without one, if possible, as they find it too rigid and planning-based. However, more complex project environments require meaningful structures. In most cases, these will be called WBS but are product-specific structures.
Our tip: You will not benefit from bending the project to make it fit into a particular structure. After all, the tool should serve your project and not the other way round.
However, it is always worth thinking of a sound structure. A project structure, which is as lean as possible, can also be appropriate as a rough planning basis for agile projects.
Conclusion – Work Breakdown Structure
In this article, you have learned what a work breakdown structure is: it states WHAT will be done in the project. It is a proven method for communicating with the stakeholders and creates a common understanding of the project within the project team.
In addition, you have found out what advantages it offers and how to create it. You have become familiar with the types and levels of structuring and know that planning software can support you in the process.
Our final tips:
Get to know the individually adaptable “PPM Paradise” – the optimal environment for your enterprise-wide project, program, portfolio and resource management (PPM). Download the free eBook “The PPM Paradise” now (just click, no form).
And sign up for our bi-weekly blog newsletter with information on more practical articles, eBooks, etc. to improve your project management maturity level.
Any questions? Please leave us a comment to which we will reply shortly – we promise.
About the author:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM expert is a trainer for project management with a particular focus on agile practices and Scrum seminars. Furthermore, she has experience as a software trainer (JIRA, Confluence) and consultant. In addition to teaching frameworks and theory, she is experienced in the use of agile games and practical exercises to reinforce the knowledge gained.Read more about Antje Lehmann-Benz on Linkedin.
