Work Breakdown Structure (WBS): What is it and Why is it Fundamental for Every Project?

Have you ever had a situation in your projects where, as you are in the execution phase, you realise that you forgot one of the deliverables? You had your planning done but this one somehow is not considered and eventually your project is negatively impacted. Although this issue has several aspects, the most important underlying reason is not to have a concise Work Breakdown Structure (WBS).

A WBS is an essential project management tool to define and organise the total scope of the project by using a hierarchical tree structure. Each level defines a set of planned outcomes that collectively and exclusively represent 100% of the project scope. Each subsequent level of each node, also represents the 100% of the scope of their parent node.  It eventually allows you to break down complex projects into more manageable parts to be able to plan, execute and control. Basically, the work is decomposed into smaller pieces called work packages. A WBS is not an exhaustive list of work. It is instead a comprehensive classification of project scope.

The WBS is the foundation of the project. This means almost everything occurs in planning after the creation of the WBS. The project costs and time are estimated in the work package or the activity level. Risks are identified by the work package. Resource allocation is also done in the work package level.

To be able to harvest the maximum benefits from a WBS, you should not treat it as just a project deliverable that you use in the planning and then forget about it. It is much more valuable than that. First of all, it is a very important communication tool. It helps the new team members to see their roles and how do they fit in the project. It helps the PM to control scope creep (to see if the scope is increasing or varying from what was planned) by reminding everyone about the work to be done. When there is a change request, it helps you to judge whether the change is within the project scope, if so what the impact of the change on the scope is.  

How to Create a WBS?

It is quite ok that two different PMs come up with a different WBS for the same project providing that a set of rules are followed:

o   The entire project is included in the WBS, all internal external, interim deliverables for the work to be completed needs to be included.

o   The WBS is created with the help of the team

o   Each level represents a decomposition of the higher-level item and also contains 100% of the work that needs to be done for that deliverable

o   The WBS only includes the deliverables that are required for the project.

o   If anything is not mentioned in the WBS, then the deliverable is not a part of the project

o   A WBS is defined in terms of outcomes, results or services that can be predicted accurately not actions.

How Far Down?

A natural level of granularity is reached for a WBS when it is no longer possible to define planned outcomes but the only remaining details are set of actions. This means the deliverable can be realistically and confidently estimated, it can be completed without interruption and it can be completed quickly. This package may be also outsourced or contracted out.

There are several rules (suggestions) for the decomposition of the work like 40-hour rule or 4% rule but in essence the granulation level for each work package also has dependency on the complexity of the project. For small projects this granularity could be between 4-40 hours but it may go as much as 300 hours of work for complex and large-scale projects.

40-hour rule is where generally the project deliverables are decomposed down to where it can be completed by a 40 hours effort. This is based on a 40-hour work week.  4% rule suggests that each decomposition should be down to around 4% or the entire project (could be cost based or time based).

Another important point to note is that most WBS are not symmetrical. That means some legs are longer than the others. Understandably, some of the deliverables require more granularity than the others.

WBS as a Stakeholder Management Tool!

From the beginning of the project to the very end a WBS is a very effective tool for stakeholder management. It helps the team and the project manager in multiple ways. To list a few;

o   It gets the team buy-in. All understand what needs to be done and where their contribution will be in the project.

o   Helps creating acceptance criteria for each deliverable

o   Provides proof for each resource, time or cost.

o   Provides basis for each planning activity: scope, time, cost, resource risk etc.

o   Helps prevent changes

o   Facilitates communication and cooperation between the team members and among the other stakeholders.

What is WBS Dictionary?

WBS Dictionary is maybe one of the most overlooked and undervalued items among most project managers. When we build a WBS usually work packages are identified with short 2-3 word descriptions (i.e. “x equipment purchased”). This gives too much room for interpretation to the team member and possibility for scoop creep. To prevent such possible misinterpretations a WBS Dictionary needs to be employed.

At minimum, the dictionary should contain a thorough description of the work. It describes the element deliverables and scope that will comprise the element resources and the cost. If there are important and unique aspects of the element these should be mentioned. Any technical details/ definition documents can also be added to the dictionary.

On the other side, it may contain as many information as deliverable description, work need to be done, responsible person, acceptance criteria, assumptions and constraints, quality metrics, technical source document, risks, resources assigned, duration, schedule milestones, cost, due date, interdependencies, and approval of the project manager. This would make it a living document with revision control.

Key Take Aways:

• Independent of the size of the project, each project must have a WBS.

• A WBS is a great control mechanism for the scoop creep and change control activities as well as a key tool for stakeholder management. It helps the new team members to understand the extend of the project and see their contribution to the project.

• WBS is not used only in the planning phase but should be revisited through the project.

• A WBS dictionary is essential for each project to prevent, misinterpretations and the work slipping through the cracks.

Need help with your project planning or want to learn more? Reach out: info@pmformedtech.com