Multiple WBS vs Grouping

Multiple WBS vs Grouping

by | 2 Oct, 2026 | Blog

What is the difference between having multiple Work Breakdown Structures (WBS) and having multiple ways to group activities?
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:
A WBS is a grouping structure, but not every grouping structure is a WBS.

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

One of my programs contained multiple projects, while delivery was organised through releases. Each release included deliverables from several different projects.

• 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

Grouping answers:

“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

Risk Dumping

Risk Dumping

by | 28 Sep, 2026 | Blog

Project management guidelines list many risk response strategies: avoid, mitigate, transfer, accept and escalate but they overlook perhaps the most popular strategy of all: risk dumping.

Risk dumping: the practice of adding a risk to the risk register, assigning it to someone else, and then behaving as though responsibility for the risk has disappeared.

Throughout my career, across many projects, programs and portfolios, I have observed the same behaviour repeatedly. A project manager identifies a risk, adds it to the risk register and informs senior management. Then something strange happens.

The project manager begins treating the risk as a collective responsibility. Because management has been informed, they believe their job is done.

The risk is documented.
The risk is visible.
The risk may even be discussed every risk review meeting, but nobody is actively managing it.

Documenting and communicating a risk are important parts of risk management, but awareness does not replace ownership. Escalating a risk does not automatically transfer responsibility for mitigating it.

A risk register is a management tool, not a responsibility-dumping ground.

A risk is not managed because it appears in a report. It is managed only when someone takes ownership, implements agreed actions and monitors whether those actions are actually reducing the exposure.

If the risk remains unchanged while the register is regularly updated, you are not managing risk. You are managing risk information.

How common is risk dumping in your organisation?

Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma

Monte Carlo Analysis Challenges: Predicting Project Cancellation

Monte Carlo Analysis Challenges: Predicting Project Cancellation

by | 9 Sep, 2026 | Blog

Statistically, we know that some projects will never be delivered. Projects are cancelled for a variety of reasons.

Other projects go through multiple reincarnations and deliver after several attempts. Decisions to stop a project, redefine its scope, or change the delivery strategy are common realities of project delivery.

Project analysis methods should be able to predict such possibilities. However, none of the commonly applied methods today can reliably estimate the probability of project cancellation.

There are two primary reasons for this: mathematical and psychological.

The Mathematical Challenge

A strong candidate for predicting project cancellation is Monte Carlo Simulation (MCS).

However, this would require a fundamental shift in how MCS is typically applied.
MCS generates thousands of possible project outcomes. In theory, a properly designed simulation model considers all possible outcomes, not just the outcomes that lead to project completion. In practice, this is rarely the case.

If project cancellation is a possible outcome, the simulation model should explicitly include a “project cancelled” scenario. This would allow analysts to estimate the probability of cancellation alongside the probability distribution of delivery dates, costs, and benefits for projects that are successfully completed.

Without modelling cancellation as a valid outcome, the simulation can’t predict it, regardless of how sophisticated the analysis may appear.

The Psychological Challenge

The second challenge is the quality of the simulation model itself.

Project teams, sponsors, and organisations are often reluctant to acknowledge the possibility of project cancellation. As a result, forecasting models are designed to answer the question:

“When will the project finish?”

rather than the more fundamental question:

“Will the project finish at all?”

Many projects are cancelled because of risks that are known but never formally documented or analysed. This is not necessarily because project teams fail to recognise them, but because they are too complex, politically sensitive, or difficult to address.

I refer to these as “elephants in the room”— systemic issues that create a significant probability of project failure. If such risks are excluded from the simulation model, the analysis will systematically ignore some of the most important project outcomes.

This creates an optimism bias that removes critical failure scenarios from the analysis before the simulation even begins.

Conclusion

To use Monte Carlo Simulation effectively for project forecasting, we must move beyond estimating delivery dates and costs. Simulation models should explicitly represent cancellation and major scope changes as legitimate outcomes.

At the same time, organisations must be willing to acknowledge systemic risks and understand how they impact project outcomes.

Only then can Monte Carlo Simulation can provide a realistic view of project uncertainty, including the possibility that the project may never be delivered at all.

Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma

Probabilistic Critical Path

Probabilistic Critical Path

by | 7 Aug, 2026 | Blog

Project management theory tells us that there is always a sequence of activities that ultimately determines the project duration. However, practice tells us something equally important: that sequence can’t be reliably predicted in advance.

Experience clearly demonstrates that the probability of the project’s Resource Critical Path changing during the project lifecycle is almost certain. This is not necessarily a result of poor planning. It happens because the actual delivery sequence that drives the completion date depends on factors that can’t be fully known in advance: resource availability and calendars, supply volatility, productivity, materialised risks, and uncontrolled aleatory uncertainties.

Instead of focusing on identifying and managing one supposedly most important path, the delivery team should focus on a cluster of activities that are likely to drive the project completion date.

Importantly, activities within this cluster may not form a single logically linked sequence.

Such a cluster can be identified through Probabilistic Critical Path analysis.

To calculate it, the project needs a dynamic delivery model that integrates project possibilities, uncertainties, dependencies, resource and supply limitations, and other real-world constraints. Advanced scheduling methods can then be combined with repeated random sampling to calculate how frequently each activity becomes delivery-critical across the range of possible project scenarios.

The result is not one deterministic critical path, but a probabilistic view of the activities and clusters most likely to influence the project completion date.

Advanced project delivery systems, like Spider Project, can calculate Probabilistic Critical Path already but project managers and planners need to learn how to develop a reliable simulation model.

Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma

Corporate Game: The Planning Pantomime

Corporate Game: The Planning Pantomime

by | 4 Aug, 2026 | Blog

Where the plan is fiction, and the updates are performance art.

Concept:

“The Planning Pantomime” is a satirical take on corporate project management where schedules are regularly updated, polished, and presented but not used to drive real action. Schedule used as props in a carefully choreographed performance. The game thrives on form over function and celebrates the illusion of control.

Key Roles:

1. The Master Planner: Crafts convincing Gantt charts perfectly aligned with nothing in particular.
2. The Project Manager: Delivers confident updates, artfully dodging difficult questions with jargon, optimism, and a polished tone.
3. The Sponsor: Smiles and nods through presentations. As long as the charts look good, they won’t ask for inconvenient evidence of progress.
4. Reporting Analyst: Knows the report is fiction but plays along. Updates the dashboard five minutes before the meeting with whatever numbers “look right.”
5. The Risk Manager: Expert in identifying risks either painfully obvious or utterly abstract. Uses phrases like “We’re monitoring it closely” and tools like Heat Maps and Monte Carlo simulations, preferably without interpretation.
6. The PMO: Enforces process compliance while gently ignoring whether the process produces value.
7. The Auditor: Occasionally appears to ensure the right forms are filled out, not whether they reflect reality.

Objectives:

Maintain the illusion of success for as long as possible. Avoid triggering real scrutiny, budget reallocation, or timeline corrections.

Rules of Play:

  • Schedules must be submitted in the official tool monthly.
  • Submit schedule updates on time, regardless of what’s actually happening. Timeliness equals trustworthiness.
  • Always show progress. Add a milestone, shift a date, or rename a task – anything to imply motion.
  • If real events deviate from the plan, quietly revise the schedule to reflect the new reality without drawing attention to the shift.
  • Regularly run easy-to-pass recognised schedule health checks that look complex but ask little. Display the results proudly in executive reports.
  • Use project control methods that produce already known comforting stories. Present misleading schedule progress metrics in a state-of-art dashboard.
  • Create small, solvable problems to stay relevant. Then proudly present the solution preferably to a problem you quietly caused weeks ago.
  • Use sophisticated, officially recognised enterprise-grade project management system. The more complex and harder to navigate, the better. Mastering obscure menus and buried functions earns respect. When questioned, produce a 100-page Gantt chart pdf report and say, “It’s all in the system.”
  • If someone tries to make a real decision using the schedule, distract them with a colourful burndown chart or animated dashboard.

Winning Conditions:

Project dashboard stays green until next black swan event identified.

  • The original baseline is unrecognisable but still referred to as the official version.
  • Corrective action meetings are never scheduled or always deferred.
  • No one notices if team stop updating schedule months ago.
  • You heroically solve problems that should not even exist and get praised for it.
  • Final reports celebrate “strong governance and disciplined planning,” regardless of the chaos beneath.

Master Level:

  • Stage a crisis just early enough to appear visionary.
  • Let a small issue grow quietly. Time discovery for maximum drama, minimal blame.
  • Then roll out a highly structured recovery plan featuring a re-baselined schedule titled the “Optimised Recovery Plan”.
  • Add a new “Focus Area” workstream to maximise additional cost.
  • Schedule a “Lessons Learned” session, then quietly postponed it to the post-delivery stage
  • Present the recovery as a case study at the next project control conference. Accept awards. Repeat if necessary.

Any resemblance to actual methods, systems, people or projects is purely coincidental.

Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma