Ask most experienced project managers and they will vouch for the benefits of using a work breakdown structure. Like many other powerful tools that create a strong impact, the best thing about a work breakdown structure is its simplicity. In this article, we take a look at what a work breakdown structure is, how it benefits projects despite their size, how to create a work breakdown structure, and best practices that can help you leverage it to its maximum potential.

What is a Work Breakdown Structure?

A work breakdown structure (WBS) is a visually rich, hierarchical representation of project scope and deliverables. To arrive at a work breakdown structure, project managers split the vast scope of a project into smaller outcomes, which are measurable and easier to understand.

In a work breakdown structure, a high-level project deliverable is divided into work packages or units. At its final level, a work package is too small to dissect more. As per the 8/80 rule, the duration of a work package is recommended to be between 8 hours/day and 80 hours/unit. Usually, a work package is assigned to a single resource or team; if multiple resources own the work, it’s most likely that it can be split into further units.

All work packages together need to cumulatively add up to the project goal; in other words, the sum of all child elements in the hierarchy, in terms of duration and costs, need to be equal to its parent element—this is referred to as the 100% rule. This ensures that no part of the project objectives will be missed out in a work breakdown structure.

What is the Purpose of a Work Breakdown Structure?

A work breakdown structure is often the first deliverable in a project. It’s where most project managers begin.

As the information needed to create a WBS has to be collated from multiple teams, it’s a useful exercise for everyone, including the project manager, to understand the big picture. The graphical representation gives clarity on what’s required to get the project done. A WBS also helps to assign accountability as well as get teams to sign-off and commit to the project, in terms of resources, time, and costs.

For project managers, the WBS is an effective planning tool for estimation and implementation. The data from a WBS feeds into other project collateral such as:

• Risk management plan: Dependencies between different deliverables help determine the high-risk units and critical path.
• Resource breakdown structure: Resource assignments against work units help estimate resource requirements and plan capacities.
• Project schedule: Schedule is usually the second deliverable after WBS. Project managers tend to use the WBS as a base for defining specific tasks and assigning deadlines to them.
• Status reports: WBS also functions as a tracker, as the template enables marking the progress of outcomes.

Different Formats of a Work Breakdown Structure

The advantage of a work breakdown structure lies in its visual representation of complex project details. With a quick glance of a WBS, it’s easy to interpret the project scope, outcomes, and dependencies.

A work breakdown structure can be presented in different formats, most common among them being flowcharts and spreadsheets. In some cases, they can be written as a text-based outline as well. There is no one-size-fits-all approach here, as different formats work well for different projects.

Let us look at the pros and cons of each format:

Flowcharts

(source: creately.com)

Flowcharts are great for depicting workflows that are sequential and without too many interdependencies or decision points. While it’s theoretically possible to demonstrate dependencies and decision points in a flowchart, too many of those can make the flowchart unwieldy and difficult to understand—For complex and non-linear projects, it’s best to use a different format.

Flowcharts can take different forms and show breakdowns from different perspectives:

• Phase-based: In this approach, a project can be broken down into sequential phases. For example the project “Ecommerce Website” can be broken down into the phases Planning, Requirements, Design, Development, Testing, and Deployment. Each of these phases can further be divided into smaller chunks of work.
• Deliverable-based: Here, the flowchart structure is based on the deliverables. For example, a project such as “Migration to Cloud” can be broken down into two high-level deliverables—cloud environment readiness and on-premise data migration readiness—that can in turn be split into smaller units.
• Responsibility-based: In this method, the project is divided based on team functions and responsibilities. For instance, Business users, Development team, QA team, and Project management team could be some of the high-level units, and this is further split based on the responsibilities of each of these teams.

Spreadsheets

(source: qimacros.com)

Most complex projects use spreadsheets to explain their scope. Spreadsheets have more space and ability to accommodate details, data, highlight dependencies, etc. It may not be easy to gather all the information at a single glance from a spreadsheet with 1000s of entries, but no information will be left out in this format. Cost, due dates, task dependencies, resource dependencies can all be included in a spreadsheet easily.

In this case, too, work can be broken down based on phases, deliverables, or responsibilities.

Outlines

(source: pmi.org)

Outlines are usually text-based and have a hierarchical list of to-dos or tasks. Outlines are uncommon in large-scale projects, but can be useful for smaller, more basic projects such as maintenance upgrades, quick installations, etc., where the primary focus is to get a sense of tasks involved and report status for transparency.

What is Included in a Work Breakdown Structure?

Regardless of the format you use for the work breakdown structure, you need to understand how to go about building it, what its components are, what to include and what not to, and a few general guidelines and rules to follow.

Let us look into a few must-have attributes that need to be included.

1. Levels that follow a clear hierarchy

A work breakdown structure starts with a project, which is split into high-level deliverables and then into work packages. The cascading levels inside a work breakdown structure need to be logical, unambiguous, and seamless. Each work package should be an independent piece of work that can be clearly defined and estimated.

For example, let’s say you want to renovate your house. This project “Home Renovation” can be broken down into Carpentry, Painting, Plumbing, Electrical, Design, and Civil work. The work packages inside Painting could be Exterior and Interior. Interior can again be categorized based on the rooms—Living, Kitchen, etc. Each room can be split into Walls and Ceiling.

2. Deliverables or products, not actions items

Each work package in a WBS is a “deliverable” and not an “action.” It could also be a product or an artifact such as a design document. Hence, you need to use nouns instead of verbs, while defining work packages.

For beginners, this could take time to get used to. For example, rather than define a work package as “Write unit test cases for login module,” you can call it “Login module test cases.” It might appear that there is no difference between the two, but in reality, there is: a deliverable can be accomplished by any set of actions, which might change as the project progresses, but the deliverable remains fixed.

In the “Home Renovation” example, the work package “Kitchen Painting” is a deliverable. Underneath that you may plan to have tasks such as buy paint, patch holes with joint compound, apply primer, paint the walls, etc. These actions may change based on your use case, but the deliverable “Kitchen Painting” remains the same.

3. Deliverables for every step of the project

Most work breakdown structures focus on the core deliverables of a project. But project managers also need to include deliverables for every component of the project, even the ones tied to things like project management and approval cycles, as these have the potential to impact the overall project plan.

Examples include documents creation, administrative activities, DevOps infrastructure setup, and budget sign-off.

It’s also important to ensure that there is no overlap between deliverables. Each deliverable needs to be distinct and mutually exclusive from others. Otherwise, this could result in double counting or missed items. For instance, in the “Home Renovation” project, if wardrobes need to be painted, you need to make a calculated decision on whether to include that deliverable under “Painting” or “Carpentry.”

4. Breakdown of hours per deliverable, in percentages

At the lowest level, you need to define the time taken for each deliverable in hours. Due to the 100% rule, when you complete defining the entire work breakdown structure, all the work packages will roll up to its higher level, and you will have visibility into the time taken to complete each deliverable and its percentage in the overall project duration.

This attribute is mostly used in complex projects, which are broken down into minute details. Hence this is a natural fit for the spreadsheet format but it can be included in flowchart formats as well by mentioning the hours in brackets next to each outcome.

5. Breakdown of cost per deliverable

Similar to the earlier attribute, you can assign a cost to each work package, which then helps you calculate the total project cost. In comparison to timelines though, this may be a more difficult one to compute at the level of each deliverable.

For example, since you use your infrastructure as a common resource to complete several deliverables, apportioning that cost for a single deliverable such as “Unit Test Cases” is challenging.

This is usually done in spreadsheets and for complex projects.

6. Breakdown of timeline per deliverable

In comparison to the breakdown of hours that focuses on the duration taken for each work package, this attribute shows the actual timeline or the date when it’s expected to be complete. This is a great way to integrate the actual project schedule with work breakdown structure.

Many projects may choose to keep project schedules and WBS separate, but for projects that require a high level of transparencies (for example, government, capital, or regulatory risk projects), this can be really useful to bring the when and what together.

How a Project’s Complexity Affects WBS

The level of detailing of each of these attributes in a WBS can significantly vary based on the complexity of the project. Simpler projects are structured as outlines or flowcharts, but complex projects are shown as spreadsheets. Complex projects also have a detailed breakdown of costs and timelines, while smaller projects may just have a hierarchical list of deliverables.

The number of levels, too, tend to vary. Usually, most projects have three levels, but long-term capital-intensive projects may have more levels—up to five or six. Hence, the work breakdown structure of a construction project that is expected to run in many phases over several years will vary from a short-term house renovation project.

Best Practices of a Work Breakdown Structure

Now that we have discussed how to create a work breakdown structure and what elements to include in it, let’s look at a few best practices to follow. We recommend you to keep this easy-to-digest list of tips handy before creating a work breakdown structure.

1. It’s all about the nouns.

Every work package in a WBS should be a noun, not a verb. A WBS should focus on deliverables and outcomes, and not look like a list of to-dos.

2. Keep deliverables mutually exclusive.

Every work package needs to be a discrete component with no overlap between deliverables. While there may be dependencies (for example, deliverable 2 can start only after deliverable 1 is complete), the scope of each deliverable should be independent.

3. Remember the 100% rule.

The sum of any detail (cost, hours, etc.) in a child element of the WBS needs to add up to 100% of its parent element.

4. Find the right format and balance of details.

It’s essential to understand the complexity and scope of your project, and determine the number of levels and attributes to include. By figuring out how deep you want to go into the project, you can also finalize which format fits that desired level of detail.

5. Map WBS to other structures.

WBS is just a starting point for project planning. It’s not a replacement for other collateral such as risk matrix, resource breakdown structure, project schedule, and change management plan.
But WBS is critical because it consolidates data in one place and gives a clear insight into the project scope. Its layout and details, therefore, should be used as input for other collateral.

Work Breakdown Structure and Enterprise Project Performance

The best way to map the work breakdown structure with other project artifacts is to work with an integrated platform that unifies all aspects of a project. This eliminates the need to manually translate WBS data into other structures. The manual approach is not only cumbersome, but also becomes inaccurate as complexity increases.

EcoSys is an enterprise project performance software platform designed to bring key processes across the full project lifecycle, from Project Portfolio Management to Project Controls, into one central hub. As a result, work breakdown structures play a core role within the EcoSys software: maintain WBS templates for different project types, use WBS to build estimates and time phased budgets, and track progress across each line item to roll up to determine percent complete and inform earned value management and forecasts.

In all, increasing standardization of your project processes (e.g. map WBS to Cost Breakdown Structures to integrate with financial systems) while supporting project-specific flexibility (e.g. standard organizational structures to level 3 with levels 4 and 5 flexible for project needs), allows organizations with EcoSys to improve transparency to stakeholders, increase predictability, and expedite decision making.

Learn more about EcoSys and how it delivers Enterprise Projects Performance.