A project without a work breakdown structure is like building a house without a construction plan. Sooner or later, gaps, misunderstandings and unnecessary extra work will crop up. This is where the work breakdown structure (WBS) comes in. It creates visibility, brings order to complex projects and lays the foundations for successful project planning.
Whether you are planning, managing or coordinating a project – a well-conceived work breakdown structure, helps you keep track of everything. It breaks even extensive large-scale projects down into manageable work packages and ensures that everyone involved shares the same understanding of the project.
In this article, you will learn what makes a good WBS, what benefits it offers and how to create one step by step. You will also get to know the key types of structure, tried-and-tested methods and practical tips that will help you set up your WBS efficiently and use it successfully in day-to-day project work.
These are the topics to which you can look forward:
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 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.
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).
Reading tip: Project Management in the Construction Industry
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 WBS 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.
As an alternative, you can find 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 overview and communication.
No matter what WBS 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.
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 WBS are:
There are no actual disadvantages of a WBS. (Possibly only that the creation takes time ;-), but the advantages outweigh this several times.)
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 lose track fairly quickly without a graphical work breakdown structure. This is inconvenient, since 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.
Several key principles for work breakdown structures have been from their inception until the present day:
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.
Both practical application and specifications by DIN standards result in the following customary structuring options:
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.
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.
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 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.
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: the sub-elements on the left refer to the design tasks for these aspects, those on the right refer to the development tasks; other ones can follow in the third column.
Once the structuring approach is defined, you will need to decide on a breakdown method.
There are the following techniques:
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.
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.
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.
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:
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”.
At this point, you should not assign resources, only responsibilities.
Milestones mark important achievements in the project. They are often associated with handovers and deadlines. Graphically, they are often depicted as diamonds 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.
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.
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 will not resemble a WBS structure. However, it can also be structured of course.
The lowest planning level is 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:
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.
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.
Do you have any questions? We look forward to hearing from you via the contact form or another channel.
Our final tip: Sign up for our bi-weekly blog newsletter with information on more practical articles, eBooks, etc. to improve your project management maturity level.