How to create a Work Breakdown Structure

Posted By Mdap on 6/08/2018 | 0 comments


How to create a Work Breakdown Structure

Posted by on 6/08/2018 |

One of the first tasks performed by the Project Manager is to define the scope of the Project. Delimiting the work to be done to meet the objectives and complete the deliverables of the Project. Let’s learn how to create a Project Work Breakdown Structure or WBS.

What is the Project’s Work Breakdown Structure?

The Project Work Breakdown Structure is a hierarchical decomposition of the Project. It is oriented to the deliverable and related to the work to be executed by the Project Team in order to achieve the objectives and create the required deliverables.

This important tool can lead us to the success of the project. But if the project is not properly broken down and structured, it will lead to failure.

The Work Breakdown Structure is not a list of tasks, it is a differentiated decomposition oriented to the project deliverables. The client will evaluate the work of the Project Manager through the deliverables that are finalized and presented to him.

PMI defines the Work Breakdown Structure in the 6th edition of the PMBOK as follows: “The WBS is 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. The WBS organizes and defines the total scope of the project and represents the work specified in the current approved project scope statement”.

There is no fixed rule, no established design for making a Work Breakdown Structure. But the entire project team needs to be involved in its creation. The work must be divided into work packages (WP) and levels must be set. In other words, the WBS shows both the tasks to be performed and those responsible for those tasks.

Project WBS Basics

These are the basic concepts you need to know in order to understand how to do a Work Breakdown Structure.

What is a Project deliverable: All the tasks of the project aim to achieve a product, service or result; that is, a deliverable. On completion of the tasks we get the deliverables. Then we will deliver them to the client, when he accepts them the project will be completed.

What is the Project’s WBS: The first thing the project manager should understand is that WBS is not a list of project tasks. The project WBS is a hierarchical decomposition of all the tasks to do in order to successfully complete the project.

What is WBS for? The WBS provides a much better understanding of the project. Indeed It allows the project manager and all interested parties to better control the project.

A Project without WBS: Project WBS is essential in Project Management. Otherwise the project will take longer, the risks will be much greater and worse controlled, and they will be more likely to have a negative impact on the project.

The WBS and its influence on the Cost of the Project: The WBS allows the project team to better understand what deliverables we need to make in the project. This is extremely important because the deliverables are the most resource demanding, and the resources entail costs. The cost of the deliverables is a reflection of the cost of the project.

What ISO and PMI say about WBS: They say that the Project Work Breakdown Structure is a hierarchical decomposition, oriented to the project deliverable and related to the work to be done to obtain those deliverables. They believe that it must be executed by the project team to achieve the project objectives and that it is very useful to create the deliverables required by the client.

How deliverables are made: The project team sees, analyzes and knows how the deliverables will be realized. This is done through knowledge of the tasks that are necessary for its execution. This bird’s-eye view of all the tasks required to bring the project to fruition gives the project management security and efficiency.

Divide and conquer: WBS divides the work into small components. The project WBS divides the work needed to make the project deliverables into work packages. It also establishes these works by levels for greater efficiency in their management and execution.

Every descending level: It represents an increasingly detailed definition of project work down to the lowest level. An example of a structure is: work package/task/subtask or project activity.

Customer satisfaction: The Project WBS breaks down the Project into smaller, more manageable pieces. Thus we facilitate the delivery of the project deliverables within the project structure, as agreed with the client.

Tasks and those responsible for them: It also determines responsibilities for these tasks within the project. The WBS indicates who is responsible for each task within the Project. It allows to quickly identify the person responsible for the task in case of any contingency.

The Project’s WBS and its influence on the Project Management Plan: It allows to improve the Project Management Plan making the execution of the Project easier and with less risk. It shows us how one Project deliverable relates to another, its sequence, its cadence, its importance, etc. The WBS of the project is the way, the roadmap to the success of the project.

Productive and Managerial Works: Works that are not productive and will not generate deliverables are managerial works. It is important to keep them in mind because they are necessary to manage and close the project.

The scope of the Project’s WBS

In the Executive Master in Project Management you learn how to make Project WBS attractive and effective to achieve the purpose of the Project.

An attractive WBS is more efficient. We can put color codes by levels, we can put the name of the task, the start date, the end date, the estimated number of days, etc.

Find out what efforts will be required. In the WBS we identify and define all the efforts required to complete the Project through the tasks necessary for its completion.

Find out who is responsible for the tasks. We assign responsibilities in the Project. Let’s remember that each task is associated with its manager, so we create a network of perfectly identified managers.

We establish a project schedule. Tasks require a certain amount of time, a certain sequence and a certain relationship between them. Therefore, the Project’s WBS will show us the time needed for its completion and completion.

Determine a Budget. We get a budget for the project because each task has its own cost. The combination of these costs, together with other costs within the project, will determine the project budget.

WBS is very useful. For all we know, WBS will serve as the basis for:

  • Control of project costs.
  • Know the resources required to successfully complete the project.
  • Establish and monitor the project schedule.
  • To better understand and control the risks of the project.

The WBS is a permanent reference point throughout the project

No one Work Breakdown Structure is better than another: In principle, we will use the one we consider most appropriate and logical based on our experience as Project Managers.

A reference for the project: The most important thing is not to forget that it has to serve as a permanent reference point. On this basis we have to implement it. A well-listed work breakdown structure will avoid confusion in the project team.

Everything that is planned in a Project is to be executed. An EDT should have no more than 5 levels. Keep in mind that it is a work tool, therefore the whole work team must understand it well.

An excessive desire for definition could be detrimental to the project. A 15-level WBS in theory may seem well structured and clarified. In practice, however, it will not be operational and we will not be able to implement it. It makes no sense to make plans that are not operational during the execution phase of the Project.

Make a Project Work Breakdown Structure attractive: Cleanliness and elegance go hand in hand with efficiency at all times. For example, we can put color codes by levels. A WBS done with elegance and affection will be very visual and easy to understand. Thus we can identify the tasks and their relevant information at a glance.

Never forget the dates: Everything in the Project is identifiable and measurable. The start and end dates delimit both the task itself and its temporal relationship with the other tasks of the project.

Other utility values: For example, we can put an estimated number of days of each task into the WBS. In general, we will use everything we consider convenient for its correct reading and interpretation.

Usually a project results in a single product and/or service: But that result can be a complex system with many components. Each component has its own separate scope that is interdependent on the scope of the overall project system. Once again we see the complexity and the reason why Project Management has become a profession.

Experienced project managers: It is very common to set up a library to obtain suitable WBS models of the project. When we have a new project we will pull the Work Breakdown Structure from a similar project that we found suitable.

The Project’s WBS Danger: If it is not correct, if it is not accurate, if the WBS is not realistic, it becomes dangerous. We will consider what is not true and applicable to the project to be true and applicable. The Project WBS should be created with the help of the Project team. If it is not consensual, if it is not realistic, then WBS is useless.

Steps for developing the Project’s WBS

The Project Manager identifies the final product. We must have a clear understanding of the scope of the project. Otherwise it will be impossible to identify the tasks necessary to achieve the product to be delivered.

Define work packages. By identifying the project deliverable, the project manager can define the main work packages. Those work packages that are necessary to achieve the project scope identified and agreed with the stakeholders.

We can structure, for example, in the first instance, 5 work packages: one for management and 4 for technicians. Important, we must consider all the necessary work, all of it.

Break down the packages. The project manager continues to break down the Project work packages to the appropriate level of detail. It is the level that is reasonable and manageable, that is operative and adjusted to the reality of the project.

The experience of the Project Manager. It may happen that as we decompose we need more levels, but we cannot do an indefinite sequence of work packages. The project manager’s experience and knowledge of previous projects plays a key role in this. If you do not have this knowledge, it is highly recommended to consult someone with more experience.

Cost and time. The project manager breaks down the project work packages to the final level of detail. That is we decompose work packages into tasks and these into activities. This brings us to the point of detail where the cost assigned to the package and the schedule assigned are reliable and allow for efficient tracking.

Is that understood? We have decomposed until the decomposition itself has given us the cost and time information we require. That’s where the wise thing to do is to stop.

According to ISO 21500 (Guidance on Project Management), tasks should be subdivided up to a level of detail that identifies sequence, parallelism and precedence relationships.

How PMBOK recommends splitting the Project WBS

Project Managers will subdivide project tasks down to a level of detail that identifies the sequence, parallelism and other relationships of precedence between activities. These activities make up a logical flow of project execution.

Technique, intuition and experience. It’s like salt in food. As we cook a dish we taste the food and it demands, or not, more salt. This is similar, we must stop subdividing when the subdivision we have already provides us with adequate information on the project, on the cost, time, the relationship between tasks, etc..

Criticism of the task in the project. To the extent that a task is critical for the Project, because it is the entry to other tasks or because the continuation of the execution of the Project depends on its exit, this task must be defined in terms of unit of work. We just have to keep in mind that there are tasks that are susceptible to special treatment because of their importance.

Why don’t we go deeper into it? Because if the Project’s Work Breakdown Structure is well done, the criticality of that task will be perfectly reflected in time and responsible. We do not need to do anything extra to a conventional but properly performed WBS.

The Project’s WBS as a communication element

When we carry out the Work Breakdown Structure we must not lose sight of the fact that as a result we must obtain a graphic and very visual representation.

A map of the Project. We must understand WBS as an element of visual communication. It should enable us, as managers and as leaders, to know at a glance where we are in the project.

The project team. With this graphic representation the project team will have a clear idea of who is responsible for each activity and when it starts or ends.

What information the Project’s WBS should contain

The content of Work Breakdown Structure depends on many things. Here we are going to list the content that we consider essential.

The Work Breakdown Structure must contain:

  1. The scope of the Project.
  2. The name of the Project activity.
  3. What we want with that Project assignment.
  4. The start date and end date.
  5. The person responsible for each task of the project.
  6. The budget allocated to each task of the Project.

The budget of the Project. Many project management rules will tell us that we need to include the budget to make a good WBS. Keep in mind that the budget has to be calculated based on the Project’s WBS and not the other way.

Does the budget of the Project have to be inside a WBS? Well, It will depend on the complexity and scope of the project. Some people put it on, some people don’t. Even though we know that the standards (PMI, ISO 21500) indicate it, many do not put it. We think it is not something that gives information to the Project team. But it is important to bear in mind that the WBS must serve as an element of control when we make the value gained.

Application of the 100% rule to the Project’s WBS and control account

PMI establishes that the Work Breakdown Structure includes 100% of the works defined in the Project. The WBS captures all the deliverables, including those necessary for the management of the Project itself.

What is the 100% rule? This rule applies to all levels of the Project WBS. It tells us that the sum of the works of “the inferior” must be equal to 100% of the work represented by their “superior”.

Let us not forget that we are in a hierarchical and disaggregated structure.

Compliance with the 100% rule. The best way to comply with the 100% rule is to define the elements of the Project WBS in terms of results or deliverables. This ensures that the Project WBS is not too prescriptive in its methods. Allowing a certain freedom of initiative and personalization on the part of the participants in the Project.

A WBS control account serves to control the management at a point where the integration between: the scope, the budget, the real cost and the schedule takes place; measuring their joint performance. For specific reasons we place these control points in specific components of the WBS, such as: subcontracts or shared technology elements. Each control account may include one or more work packages, but each work package will only be associated with one control account. Each control account is usually associated with an organizational unit or an external vendor.

What is the optimal level of breakdown of WBS?

Why do I divide the Project’s Work Breakdown Structure? Because it is so much easier to organize the project and understand it in parts than to understand the scope of the Project as a whole. This is part of the divide and conquer techniques used in many other branches of knowledge.

As a general rule. To make the Work Breakdown Structure of the project we start from what is most essential and we structure it by levels. When a project has been decomposed down to an element that has about 40 hours of allocated direct labor, there is no need to decompose further (Michael D. Taylor).

The 40 Hour Rule is based on a 40-hour work week. Because of this, most of the Project WBS diagrams are not symmetrical, with some branches reaching level 3 and others reaching level 6. A WBS is sufficiently broken down when the element represents 4% of the total project, either in time or cost (Gary Heerkens). Within a level, a human can manage between 5 and 10 elements without restrictions of attention or memory. Once this figure is exceeded, it may be necessary to consider the creation of another level within the Project’s WBS.

The number of levels of the Project’s WBS. It will depend on the complexity and scope of the project. But as a general rule, the breakdown should not exceed 6 levels. We should consider the creation of sub-projects if the result is a higher number.

An excessive number of levels in the project’s WBS makes it difficult to monitor and control the project. Each manager should not program more than 2 or 3 levels in detail.

The WBS and its relationship with large and small deliverables:

  • The higher (towards the grandparents) the larger the deliverable. This is called a delivered oriented structure.
  • The small deliverables are usually in the Project WBS Dictionary and the large deliverables are in the boxes.
  • When the Project Manager sees a Project WBS guided by large deliverables, he sees everything that needs to be done in the project.

Good practices in Project Management say: Above the large Project deliverables and below the Project work packages. Later, in another post of the Master in Project Management, we will see how the Project work packages will be broken down by activities in the Project schedule.

The Work Packages are the last level of the Project WBS:

  • This level is to be broken down, but the work activities into which it is broken down are not part of the WBS.
  • Then we will see that the Project’s WBS, the Project’s WBS dictionary and the Project’s scope statement form the baseline of the Project’s scope.
  • This is what is agreed with the client of the project, with the client it is agreed even to the dictionary of the WBS of the Project, but it is not agreed the breaking of the work packages, our client wants results, not knowing how we will get it, that is our job.

How to number the Project Work Breakdown Structure

We usually number the elements of the WBS sequentially to indicate their relative position within the hierarchical structure.

Acronyms: Do NOT number the name of the Project, put an acronym.

  • 1st Level: Project Work Package: (WP1, WP2, …)
  • 2nd Level: Project Task: T.1.1, T.1.2, T.1.3, …
  • 3rd Level: Project activity or sub-task: t.1.1.1.1, t.1.1.2, t.1.1.3, …

Deliverables: Include the Project deliverables in each WP.

Milestones: Include the Project Milestones as checkpoints, one per Project deliverable is not necessary.

The process of Monitoring and Controlling Project Work aims to obtain various reports on the performance of project work that will help us take corrective or preventive action to improve its performance.

The Project’s Work Breakdown Structure dictionary

The WBS Dictionary is a document that accompanies and supports the work breakdown structure and describes the detailed content of each of its components. It includes elements such as: the account code, description of the work, deliverable products, assumptions and restrictions, responsible unit, milestones, etc.

It’s a work authorization. To inform the members of the project team about when they will start their work on the Project. Informs on the milestones of the project schedule and details of the project tasks.

Control mechanism. To control the work and scope of the project. It is useful to know the effort necessary to carry out each work of the Project.

When the client approves: the statement of the scope of work of the Project, the WBS and the WBS Dictionary

Project Managers can start planning:

  1. The Project schedule.
  2. The cost of the Project.
  3. The quality of the Project.
  4. The necessary resources to do the work of the Project.
  5. Project communication.
  6. The risks of the Project.
  7. What will be outsourced from the Project.
  8. How we are going to relate to the actors of the Project.

Based on the excellent article by Roberto Sanz, one of our faculty members.


Do you want to share this entry?

Submit a Comment

Your email address will not be published. Required fields are marked *