The Work Breakdown Structure (WBS) is the engine room of a project. Once the Project Delivery Strategy is decided, the WBS is the structure on which subsequent elements are created. A comprehensive WBS ensures that nothing is forgotten in terms of scope, schedule or cost. A project without a WBS is like a car without a chassis. It'll fall apart as soon as you drive it out of the showroom.
Element Purpose
The WBS is a hierarchical structure that breaks the "work" of the project into manageable chunks. A comprehensive WBS increases the likelihood that critical items are not missed.
Hierarchical Levels in the WBS
Now, there is no "right" WBS. The key is ensuring you have a standard set of levels which act as a checklist when developing your current project. Create a template and refine it as you learn from one project to the next. The first half-dozen projects may deliver variable results but the next half dozen will deliver strongly.
The following ideas will give you a strong starting point.
Level 1 in the WBS is the Project. Let's not negotiate about this one. It just makes sense.
Level 2 is typically the Project Phase. If your organisation doesn't use Project Phases then you might opt to drop this one…though I strongly urge you to use it. Well-used project phases strongly increase the likelihood of project success…but that is a topic for another day. As a minimum I'd suggest phases of Pre-Feasibility, Select, Feasibility, Execution/Implementation.
Level 3 must be tailored to the type of project. For this level, choose categories that describe the full range of project tasks.
For engineering construction projects I like to use:
For a software project you might use:
For an organisational change project it could be:
Level 4 in the structure is where the action occurs. It is the "Work Package" level. Brainstorm this level with your stakeholders to ensure you capture all of their needs.
At this level I refer to Engineering Work Packages as Design Packages. In the purchasing area we have Purchasing packages. Construction Packages is a natural title for work done to erect or implement the project (see example graphic below). System Testing Packages and Training Packages makes the objective clear for software projects. Whilst the assigned titles are not mandatory, they need to quickly convey their purpose to your team and other stakeholders.
Scale the WBS to the size and complexity of the project at hand. For larger projects, add more levels. For smaller projects, remove levels.
“A well‑structured WBS turns complexity into clarity.”
Having understood the hierarchical nature of the WBS let's now consider how the WBS interacts with the remaining Project Delivery Elements.
Element Alignment
"WBS → Scope → Schedule → Cost estimate"
Align the scope with the WBS.
Align the schedule with the scope.
Align the cost estimate with the schedule.
This ensures nothing is forgotten.
The next three blogs in the series investigate each of these elements in more detail. My recommendation is to make level 5 of the WBS the scope. Take your work package and flesh it out in detail.
Then transfer the level 5 scope into a Gantt chart and give each scope item a start and finish date (or a start date and a duration). Setup dependencies between tasks and display your critical path. If the project is more complex you may wish to include the level 6 scope detail in the Gantt chart. If it is less complex then just include the level 4 work packages.
To create the Cost Estimate, transfer the level 4 work packages into your estimating software (e.g. Excel). For early project phases, where the estimate is calculated "bottom up", transfer the level 6 scope detail into your estimate. Work packages with tendered prices only need transferring at the work package level.
Crucially, whilst the Cost Estimate can start immediately after the scope is developed, it cannot be completed until the schedule is completed. The Schedule defines both project duration and time-dependent costs such as team labour. Thus time-dependent costs can't be finalised in the Cost Estimate until the Schedule is sufficiently drafted.
Note the arrows in the graphic below. The arrows from the WBS to the Scope, Schedule and Cost Estimate elements indicate that these elements can be commenced as soon as the WBS is finalised. The arrows from the Scope of Work to the Schedule and then to the Cost Estimate indicate that the Cost Estimate is the last element to be completed (because of the time-dependent costs).
When you mess with this order, you risk omitting or underestimating critical costs.
So how do you generate the WBS?
WBS Development
There are many different ways to develop a WBS. My favourite method is Mind Mapping. It allows me to create a basic structure and then brainstorm the detail with my team and key stakeholders. Do this as a team in a workshop environment. It's amazing how one person's ideas trigger a thought in someone else.
It's also worth adding a branch to your WBS for "Exclusions". Record all ideas that were raised and rejected on the "Exclusions" branch. This will make it easier to write your Scope and Project Execution Plan documents.
Impact on or by Element
Given that the WBS drives the scope, schedule and cost estimate the typical impact occurs as follows. A change is made to the scope. This forces a change to the WBS. Once the WBS changes it is imperative to review and update the schedule and cost estimate.
Similarly, if the installation work is discovered to require a plant shutdown then this may affect the work packages requiring a modification to the WBS and a subsequent review of the scope of work and cost estimate (particularly if project duration has changed).
In a software project, a change to user requirements has massive ramifications to numerous elements in the WBS and consequent flow on impacts to schedule and cost.
None of the 6 core Project Delivery Elements are independent. They all impact one another and the glue that binds them inextricably together is the WBS. Start it early and add to it as ideas surface in meetings, reviews and corridor discussions.
What's Next?
I recognise this is not an exhaustive article but I hope it has given you a practical initial insight into establishing the Work Breakdown Structure and the reason it is so pivotal to a project's success. The WBS isn’t just academic theory — it’s the single source of truth that keeps every project element aligned and accountable. It is the engine room of the project and drives project success.
In the next blog we ask: "How much detail is too much detail in the scope of work?" Precision or Pragmatism?
#ProjectManagement #WBS #WorkBreakdownStructure #PMO #ProjectPlanning #ScopeManagement #ScheduleDevelopment #CostEstimating #EngineeringProjects #SoftwareProjects #ChangeManagement #MindMapping #ProjectDelivery #ProjectControls
Comments ()