Multiple WBS vs Grouping
This is one of the challenging topics we discuss in our Planning & Scheduling masterclasses because, on the surface, the two approaches can look very similar.
In both cases, the underlying activities and logic remain unchanged, and both methods provide alternative perspectives analyse project delivery models but there is an important distinction:
Multiple Work Breakdown Structure
A WBS is not simply a summarised view of project activities. It is part of the project delivery model. Each WBS element can exist as its own project object, with metadata that can be stored, controlled, calculated and analysed.
Depending on the system, this may include:
• Unique ID
• Responsible manager
• Planned or anticipated start and finish dates
• Category
• Priority
• Weighting
• Access rights
• Budgets and costs
• Progress
• Probabilities
• Level of risk
• Assigned resources
• Activity counts and other calculated metrics
Some of this information is calculated from activities and lower-level WBS elements. Other data points are entered directly against the WBS element.
For example:
• Responsibility may be assigned directly to a WBS element.
• Progress and forecast information can be compared between reporting periods or what-if scenarios.
• A project may need to calculate the probability of completing a particular WBS element by a target date or within a target cost.
• A WBS element may effectively represent a sub-project with its own resources, controls and management approach.
Grouping works differently.
Grouping
When grouping is applied, the software reorganises the same activities according to selected classification criteria and may calculate summary information for each resulting group but the group itself is generally not a persistent project object with its own stored metadata.
It exists because a set of activities currently satisfies particular grouping rules. Change the grouping criteria and the previous structure, together with its summarised information, disappears.
The key distinction is:
WBS metadata is stored and controlled. Grouping is a temporary analytical view of the current model.
Scheduling
Another important difference is that WBS-level information influence project calculations. Depending on the system, WBS metadata can affect activity dates, durations, earned value calculations, progress calculations, access rules and other model outputs.
Grouping normally does not.
Interface
A WBS also gives us a uniquely identifiable object that can be tracked between different versions of a model or even between different systems.
Each WBS can serve as a basis for trend analysis. If a project needs to understand how a particular part of the work has changed across multiple updates or scenarios, the same WBS element can be compared directly between relevant versions.
With grouping, the required structure usually needs to be recreated consistently in each version before any comparison can be performed. Even then, the analysis may be more difficult because many scheduling systems support comparison and trend analysis at the WBS level, but not for alternative groupings.
For example, in Primavera P6 a project may create a sophisticated grouping structure using activity codes and use it as the primary way to organise and analyse the schedule. However, P6’s in-system comparison functions are fundamentally WBS-based. A grouping created from activity codes is a view of the activities, not an equivalent analytical structure.
Project management systems provide direct comparison of WBS data between project versions, while equivalent comparison of temporary groups created from activity codes is not available.
WBS can also provide a structural interface between different project management systems. Scheduling, Financial, BIM, Risk, and Benefits management systems can map information to the established WBS structure. Information can therefore be exchanged and analysed through the same structural framework.
A temporary grouping is much less suitable for this purpose.
A practical example
• Project Managers needed to manage and analyse activities belonging to their projects.
• Release Managers needed to control activities associated with their releases.
• Test Manager needed to analyse testing workload, progress and cost, even though testing activities were spread across different projects, phases and releases.
• The same applied to Change Management and other functional leaders.
Each manager needed to see and manage the same program data through a different structural perspective. The original program structure was project-focused. That worked well for Project Managers, but it made control from other management perspectives very inconvenient. It became so limiting that the Program Manager considered restructuring the entire program. That would have solved some problems but created others. Instead, we created alternative WB structures.
The activities, logic and underlying delivery model remained the same, but different managers could now analyse and control the program using the structure most relevant to their responsibilities.
Multiple WBS in Spider Project
Multiple WBS is one of key methods in SDPM. Spider Project provided with demo project that include multiple WBSs.
The primary WBS is based on investment & delivery structure.
Alternative WBS is based on project processes.
As we can see, we may plan and control project cost from different perspectives and, for example, run cost risk analysis for any element in any structure.
Summary
“How do I want to view these activities right now?”
A WBS answers a much broader question:
“How do I want this part of the project be managed, controlled, measured and integrated within the project model?”
Both are valuable but they are not interchangeable. Grouping is primarily a reporting view. WBS is part of the project management model.
Alex Lyaschenko
PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma
