Complex Resource assignments modelling

Complex Resource assignments modelling

by | 9 Feb, 2026 | Blog

Critical Path Method (CPM) can be built without complex resource modelling: planners typically develop a logic-based schedule first and assign resources afterwards.

In practice, though, this sequence often breaks down because resources are not just inputs to activities – they frequently govern activity durations. Duration is shaped by crew size, productivity rates, learning curves, and calendars, so the relationship between resource quantity and duration is rarely linear. On top of that, resource supply can be constrained, shared across projects, and volatile over time.

As a result, a purely logic-driven CPM schedule may be mathematically “correct” yet operationally unrealistic. To produce a schedule that reflects feasible execution and can be calculated reliably, complex resource assignment modelling must be applied, not treated as a post-processing step.

Think of the next scenario: 
Two resources are assigned to an activity, but only one is available. Should the scheduling system start the activity as soon as the first resource becomes available, or wait until the second one is available?

There is no single correct answer, as both scenarios are valid in real projects, depending on the nature of the work.

Consider two simple cases:

Moving chairs: the activity can start with one resource and finish without the second. It may take longer, but it is still feasible.

Moving desks: the activity cannot start unless both resources are available. One person alone cannot begin the work.

Other common examples include:

  • An activity that requires an excavator, where more than one excavator can be used if available.
  • System integration testing, where some test cases require two testers, while others can be executed by one.

For a project delivery model to be reliable, both scenarios must be explicitly supported. This means that planners (and the scheduling systems they use) must be able to define assignment logic, not rely on assumptions.

At a minimum, the model must allow definition of:

  • Teams– activities that require all assigned resources to be available before starting.
  • Multi-resource assignments– resources that operate together as a unit (e.g., a car and a driver).
  • Minimum required quantity– the minimum number of resources needed to commence the activity.
  • Maximum assignment quantity– the maximum number of resources that can be applied productively.
  • Minimum workload threshold– to prevent inefficient switching of resources across multiple concurrent tasks.

An activity may have one or more assigned teams, and each team may include one or multiple resources. This structure enables the consistent modelling of complex yet realistic assignment scenarios.

Example

Scenario 1

Scenario 2

The following scenarios are identical except for one critical difference:

Tasks 2 and 4 can both be performed by two resources. Task 2 requires both resources to start. Task 4 can technologically start with one resource and continue with one or two.

Tasks 1 and 3 require Resource A, creating a temporary resource shortage for Tasks 2 and 4.

  • In Scenario 1, Task 2 is delayed until Resource A becomes available.
  • In Scenario 2, Task 4 starts immediately and Resource A joins the task when available.

This complexity can be modelled in delivery-oriented systems such as Spider Project, which support complex resource-driven data modelling.

Expectation vs reality

A LinkedIn survey shows that most practitioners (59%) expect scheduling tools to handle both scenarios correctly. In reality, popular systems such as Primavera P6, OPC, and MS Project do not support this capability.

More concerning is that many planners using these tools struggle to explain what actually happens when assigned resources are unavailable. This highlights the continued dominance of CPM thinking and a lack of experience in resource-driven delivery modelling.

Planners who understand and model assignment complexity produce project models that delivery teams trust and actually use.

Alex Lyaschenko

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

Project Risk Management: Success–Failure Spectrum

Project Risk Management: Success–Failure Spectrum

by | 22 Jan, 2026 | Blog

The maturity of project risk management spans a broad spectrum of practices, from value-creating decision support to actively harmful pseudo-analysis. To describe this spectrum meaningfully, we must define the best, natural, and worst states, along with the intermediate stages between them.

Best

The project develops a quantitative risk simulation model that reflects real delivery conditions, considering all existing constraints, possibilities and resource volatility. This model needs to be:

  • Fully integrated with schedule, cost, resources and benefits
  • Built on realistic assumptions and credible data
  • Actively used to evaluate options, trade-offs, and decisions

In this state, risk management function is used as a decision-support system, not a reporting obligation.

 

Better

The project applies qualitative risk analysis, where risks are:

  • Assessed individually
  • Prioritised using structured professional judgement
  • Managed through defined mitigation and monitoring actions

This approach improves risk awareness but offers limited predictive capability.

 

Baseline (Natural State)

Risk management is primarily intuition-driven:

  • Risks are not formally documented
  • No meaningful qualitative or quantitative analysis is performed
  • Decisions rely largely on experience and gut feeling

This is the most common and “natural” state across projects.

 

Worse

Misapplied qualitative, scoring, or pseudo-quantitative methods are introduced:

  • To demonstrate compliance rather than generate insight
  • Using arbitrary scales, weak assumptions, or invalid models
  • Producing outputs that are largely ignored by decision-makers

At this stage, risk management becomes ceremonial. It is worse than intuition-driven, as projects spend energy performing no value-added risk management rituals.

 

Worst

Management actively uses the outputs of misapplied risk analysis to make decisions:

  • False precision creates unwarranted confidence
  • Poor models override professional judgement
  • Decisions become systematically biased by misleading data

At this point, risk management causes more harm than having no risk management at all.

 

Reference to Monte Carlo Simulation

Misapplied Monte Carlo Simulation belongs to the Worse and Worst categories.

  • If QRA is performed periodically but its results are ignored, the outcome is wasted effort and cost, with limited direct harm.
  • If flawed results are used to drive decisions, the impact is often actively damaging project outcomes.

Unfortunately, misapplied Monte Carlo Simulation is common. Two typical pathways lead projects into the Worst state:

  1. Forced QRA
    The project team is required, contractually or externally, to perform QRA, while management doesn’t realise that the reports may be formally compliant but practically misleading.
  2. Premature escalation from “Better”
    Projects that reach the Better level attempt to progress by introducing quantitative simulations. While they recognise the value of integrated analysis, they underestimate the effort, skill set, and technological capability required. As a result, maturity collapses from Better directly to Worst.  In this case, projects regress from meaningful qualitative analysis to misleading pseudo-rigour, creating an illusion of sophistication without insight. The outcome is a dramatic drop in risk-management maturity.

 

Inspired by Douglas W. Hubbard

Alex Lyaschenko

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

Monte Carlo Simulation Challenges: Resource Levelling

Monte Carlo Simulation Challenges: Resource Levelling

by | 25 Mar, 2025 | Blog

The foundation of the Monte Carlo Simulation method is a project delivery model that generates possible project realities based on existing uncertainties.

For the model to be reliable, it must accurately reflect all existing constraints, including technological dependencies, resource availability limitations, and project policies. However, many projects either fail to develop such a model or do not recognise its necessity.

While there is a common recognition that base models must be of high quality, consultants often overlook the fact that these models also need to achieve a sufficient level of maturity.

A common issue is that base simulation models often ignore resource constraints or resource levelling is performed manually before running the simulation. However, during the simulation, activity durations change, which alters resource demand profiles and creates resource overload gaps. In reality, some gaps can only be resolved by introducing additional resource dependencies.
Furthermore, supply uncertainties can also affect task sequencing and lead to project delays.

When demand and supply uncertainties are ignored, risk simulation tools generate tens of thousands of non-feasible schedules, producing misleading probabilistic outcomes that appear convincing.

To address this challenge, resource levelling must be performed dynamically during the simulation—not beforehand!

Resource Levelling Algorithms

Simply adding an automatic resource levelling feature to a risk simulation tool is not enough. Unlike the Critical Path Method (CPM), resource levelling lacks a standardised algorithm that can be universally implemented across different systems. Each system uses unique heuristics, leading to inconsistent results.

When scheduling and risk simulation tools apply different resource levelling methods, the calculated probabilities in the risk tool may not match real-world outcomes.

 

To overcome this issue, Monte Carlo Simulation must be fully integrated into the project delivery system, ensuring that both scheduling and risk analysis are based on a consistent approach.

Example

Let’s review a scheduling fragment to demonstrate the challenge.

A project has two streams: A->B and C->D, and will be completed when both streams are completed. The project has activity uncertainties and resource uncertainties:

Activity uncertainties

The duration of each activity is estimated as a range. Let’s consider 2-point estimations to keep it simple.

Resource uncertainty

Activities A and C require the same skill, so two resources are needed to perform them in parallel. However, whether the second resource will be available is unclear.

For this project to be feasible, project resources must be levelled.
Schedule analysis shows that:

If resources are unlimited, the project duration very between 12d and 14d.

If the skill ‘Resource 1’ is limited:

• An optimal solution is to start from activity C;
• Project duration varies between 12d and 16d.

If the Monte Carlo Simulation is performed, ignoring the resource supply uncertainty the result will be misleading.
Also, if levelling is performed but an algorithm in the applied Monte Carlo Simulation tool prioritises Activity A, the project duration varies between 15d and 19d. In this case, the Monte Carlo Simulation result also be misleading. The shape of the calculated probability curve doesn’t play a significant role anymore, as the range is wrong. 

Detailed schedule analysis is performed in the ‘Project Resource Levelling and Risk Analysis’ post.

Read more: https://saluteenterprises.com.au/project-resource-levelling-and-risk-analysis

Summary

Monte Carlo Simulation is a powerful risk analysis method, but it requires the development of a mature dynamic delivery model that generates realistic possibilities based on all existing uncertainties. If the development of such a model is not possible, the method produces unreliable results.

Resource levelling must be performed dynamically during the simulation. Not before.

Monte Carlo Simulation must be fully integrated into the project delivery system, ensuring that scheduling and risk analysis are based on a consistent resource levelling approach. Standalone Monte Carlo Simulation tools can’t produce reliable results if a project has limited resources.

Alex Lyaschenko

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

Monte Carlo Simulation Challenges. Simulating the true source of uncertainty

Monte Carlo Simulation Challenges. Simulating the true source of uncertainty

by | 9 May, 2023 | Blog

Usually, duration and cost uncertainties are used as a base for the Monte Carlo Simulation (MCS). However, the duration and cost uncertainties are the results of other types of uncertainties.

Simulating the source and result of uncertainties may lead to different estimates. Sometimes substantially different. Most risk simulation tools do not work with the source data and only simulate duration and cost uncertainties.

Uncertainty Types

Any project has Primary, Secondary and Project Level Uncertainties.

Uncertainty is a situation where multiple alternatives result in a specific outcome, but the probability of the outcome is not certain.

Ref: Risk vs Uncertainty
https://saluteenterprises.com.au/risk-vs-uncertainty

Many factors may impact the duration of the activity.

Ref: Critical path method challenge: Activity duration estimation
https://saluteenterprises.com.au/critical-path-method-challenge-activity-duration-estimation

Duration and cost of any activity are secondary uncertainties that are the result of the true primary uncertainties. The primary uncertainties include Volume of Work, Resource Productivity Rate and Cost, Skills Quantity, Resource & Activity Calendars, Material Quantity and Cost, etc.

Does it matter?

Is it important for the MCS analysis? Why, after the probabilities to meet project objectives (time & cost) are calculated, we can’t analyse the sources?

Such analysis must be done BEFORE the simulation as the result of the MCS depends on what is simulated: primary or secondary uncertainties.

Let’s consider two simple projects consisting of a single activity:

Project 1
• The volume of work for this activity is 800 units
• Activity duration depends on the assigned resource’s productivity, with the optimistic estimate of 1.25 u/h, the most likely estimate being 1 u/h, and the pessimistic estimate being 0.8 u/p.
• The workday is 8 hours
• Uncertainty Type: Resource Productivity (-20%, +25%)

Project 2
• The volume of work for this activity is 800 units
• Activity duration depends on the volume of work, with the optimistic estimate of 640 units, the most likely estimate being 800 units, and the pessimistic estimate being 1,000 units.
• The workday is 8 hours
• Uncertainty Type: Volume of Work (-20%, +25%)

Both projects have the same duration uncertainty: 80 /100 /125 days, and the uncertainty range: -20% / +25%. If the duration uncertainty is used as the base for MCS, the probability of delivering the project in 100 days will be the same for both projects. If the true uncertainties are used instead, the duration uncertain the result will be different.

Let’s review three scenarios simulating secondary uncertainty (duration) and primary uncertainties (Resource productivity and Volume of work).

Scenario 1: Duration uncertainty

If the work is represented by a single activity with three estimations (80d, 100d, 125d) and the activity duration is used as the base of uncertainty, as the result of MCS would be as following:
• 100d = 43%
• P75 = 108d
• P90 = 114d
• Distribution: Triangular
• Number of iterations: 50,000

Scenario 2: Resource productivity uncertainty

If the work is represented by a single activity with three estimations (80d, 100d, 125d) and the resource productivity (0.8, 1, 1.25) is used as the basis of uncertainty, the result of MCS would be as follows:

• 100d = 55%
• P75 = 106d
• P90 = 112d
• Distribution: Triangular
• Number of iterations: 50,000

Scenario 3: Volume of work uncertainty

If the work is represented by a single activity with three estimations (80d, 100d, 125d) and the volume of work (640, 800, 1000) is used as the basis of uncertainty, the result of MCS would be as follows:

• 100d = 44%
• P75 = 108d
• P90 = 115d
• Distribution: Triangular
• Number of iterations: 50,000

Activity Duration Formula

Why is the result of Scenario 2 different from Scenarios 1 and 3?
As mentioned, activity duration depends on many parameters. These parameters impact the probability of completion in different ways. It is impossible (at least for now) to create a complete formula that shows how all primary uncertainties impact activity duration as some parameters (resource quantity uncertainty, etc.) also depend on other activities. Still, the simplified formula that only includes reviewed scenarios is:

As we can see above, it does matter if the Primary uncertainty is the Numerator or Dominator, as it impacts the distribution curve!

In the first case (scenario 2) the probability of achieving the Most Likely duration is >50%, and in the second case (scenario 3), it is <50%.

Complex uncertainties

We reviewed a simple example with the uncertainty of one parameter to explain the challenge. It is clear that just for one activity without specialised risk simulation software that supports the simulation of primary uncertainties, it is very hard to understand how primary uncertainties impact activity duration uncertainty.
The real-life relationship is more complex as:

Activity may have more than one source of uncertainty.

What would the Optimistic & Pessimistic duration and the distribution curve be if an activity has uncertainties in many primary parameters? Is it impossible to understand it accurately?

It is very hard, and there is a good chance that even experienced estimators make costly mistakes when they provide 3-point estimations.

Do demonstrate it before you read the result guess:
If the activity has both (Volume of work and Productivity) uncertainties,
– What would be the probability to complete the activity in 100 days?
– What would be the optimistic & pessimistic durations?

Scenario 4: Volume of Work and Productivity uncertainties

There is 47% chance to complete this activity in 100 days.
The most likely duration is 96 days and the Optimistic – Pessimistic range is: -32% , +52% (!).
Have you noticed that the curve is starting to get a “fat tale”? Take note, I will go back to the “fat tale” anomaly in future posts.
This was a simple example, as all required information was given  (even preliminary calculations!). Do you have this right? Probably not.

It is much easier to provide reliable 3-point estimations for primary uncertainties and calculate duration uncertainties than estimate duration uncertainty correctly.

We have simulated only one activity. Projects have thousands of them. How does this challenge impact project-level uncertainties? This is not an easy question that requires separate deep analysis. However, practically we can see that:

Simulating the result of uncertainty rather than its source, the level of accuracy is substantial to say that the result is misleading, not just inaccurate.

Let’s review one more scenario to demonstrate that.

Scenario 5: Duration uncertainty in detailed schedule

Assume the scheduler for this project decided that each activity has to be no longer than ten days and converted the schedule to 10 linked activities. Visually nothing is changed. The project has the same duration and uncertianties. Has this impact the probablity? 

If the work is represented by ten 10-day activities with three estimations (8d, 10d, 12.5d) and the activity duration is used as the basis of uncertainty, the result of MCS would be as follows:
• 100d = 28% (!)
• P75 = 104d
• P90 = 105d
• Distribution: Triangular
• Number of iterations: 50,000

 

It does not look logical. 

Probability distribution should not depend on how the work is presented in the project schedule!

The project duration uncertainty depends on uncertainties of activities. However, as they are linked in a sequence, uncertainties compensate each, and simulation shows that only 105 days are required to achieve 90% probability.
The durations of all ten activities are strongly correlated, but this correlation is different. If a resource with low productivity is available for the assignments, it will impact all ten activities similarly. If the source of uncertainty (resource productivity) is simulated instead of the result (activity duration), this problem would not exist.

Scenario 6: Productivity uncertainty in a detailed schedule

If the work is represented by ten 10day activities and the resource productivity (0.8, 1, 1.25) is used as the basis of uncertainty, the result of MCS would be as following:

• 100d = 55%
• P75 =106d
• P90 = 112d
• Distribution: Triangular
• Number of iterations: 50,000

We received the same result as it was in scenario 2 when the simulation was based on resource productivity, but the work was represented by one 100d activity!

– I used the triangular distribution to make it possible for others to verify the analysis. If PERT or Long-Normal distributions are used instead the difference in the results will be even bigger.
– This challenge alone has a significant effect, but when correlated with other discussed in previous (and future) posts issues, it has accumulated effect and the results of MCS are likely to be misleading. 

Summary

  • Activity duration and cost uncertainties are the results of other types of uncertainties. They called secondary and primary uncertainties.
  • The primary uncertainties impact activity duration and probability of completion activity in planned duration. However, without Project Management software that supports the simulation of primary uncertainties, it is not easy to understand the relationship between primary and secondary uncertainties.
  • An activity may have more than one source of uncertainty. The correlation between them is complex. In some cases, primary uncertainties may compensate for each other and in other situations, the impact may be accumulated.
  • On the activity level simulating the source and result of activity uncertainties may lead to different estimates. Sometimes substantially different and even experienced estimators are likely to make mistakes in providing 3-point estimations. It is much easier to provide reliable 3-point estimations for primary uncertainties.
  • Projects have thousands of primary uncertainties. If simulating the result of uncertainty rather than its source, the deviation from the correct result will be substantial to say that it is misleading, not just inaccurate.
  • Most project management Monte Carlo solution tools don’t work with primary uncertainties, and the results produced based on these tools are unreliable.

Alex Lyaschenko

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

Monte Carlo Simulation challenges. Level of details challenge.

Monte Carlo Simulation challenges. Level of details challenge.

by | 7 Feb, 2023 | Blog

As discussed in the previous posts, applying the Monte Carlo Simulation (MCS) CORRECTLY for a large project may take many hours. As a workaround, some risk consultants recommend running simulations based on a high-level schedule, known as a control schedule and a ‘Level 3’ schedule.

The results of MCS performed based on the detailed schedule and high-level schedule are likely to be different, sometimes significantly different! There are a few reasons for that. In this post, we review one of them: the missing level of complexity.

Work packages are the smallest unit of work that a project can be broken down into when creating your Work Breakdown Structure.

In this post, the term ‘Work package’ (WP) represents ‘A group of activities’. It could be the smallest unit of work or a group of units.

When WP in a high-level schedule is represented by a single activity (or a few activities), the schedule misses a level of complexity of each WP. Without this information, the result of the simulation could be dramatically different.

Let’s review a simple example: A project has two WPs. Each of them has five 10-day activities, but in 1st WP all activities are consecutive, and in 2nd WP, all activities are concurrent.

If we decide to create a high-level schedule, we could simplify it to two linked ‘50 days’ and ‘10 days’ activities. The overall duration of both schedules and the logic between WPs will be the same.

Let’s assume each activity in our project has +/-2 days of uncertainty, which is +/-20%.

Detailed schedule with uncertainties:

High-Level schedule with uncertainties:

Now, we can calculate the probability of delivering this project in 60 days (the deterministic Most Likely scenario) and use both schedules as the base for the simulation. 

We are going to use a triangular distribution. As explained in the previous posts, the Beta / PERT distributions often better represent real-life probability, but they are unique to each risk analysis tool. I want to be sure that this experiment can be replicated with other risk analysis tools.

Also, due to the randomised nature of the Monte Carlo Simulation method, the result of any new simulation is always different. The more iterations performed, the less volatile results will be. I set the Spider Project to 50,000 iterations to minimise the volatility.

Project Probability Distribution

The performed simulation based on the High-Level schedule gives us the following probability distribution:

The performed simulation based on the Detail schedule gives us a different result:

There is 49.8% probability that this project could be completed in 60 days if the High-level schedule was used for this analysis and 29.2% probability if it was performed based on the Detail schedule.

However, project activities in both cases are going to be executed the same way, and the probability  should be the same. To understand such an anomaly, we need to go to the next level and analyse the probability of each WP separately.

1st WP probability distribution

The probability distribution of the first WP based on High-Level schedule:

The probability distribution of the first WP based on Detailed schedule:

Uncertainties in a sequence with ‘Finish-to-Start’ dependencies compensate for each other, so the result of the First WP simulation is roughly the same, regardless of the applied schedule. It is around 50%.

2nd WP probability distribution

As the second WP has only concurrent activities, the probability distribution curves are dramatically different.

Based on the Detailed schedule it is only ~3% chance that ALL activities could be completed in 10 days. If any activity is late (>10 days), the WP will be late.

In the High-level schedule, this level of complexity is lost, and the probability complete the WP in 10 days is 50%.

Probability distribution of the second WP based on the High-level schedule:  

Probability distribution of the second WP based on the Detailed schedule

There is a big difference between 3% and 50%! Depending on which result is presented to project decision-makers, it may lead to different actions.

Level of complexity

The analysed example above may look extraordinary. Not all projects have five linked concurrent activities. However, if we analyse any schedule, we are likely to find that there are days with more than five planned activities. All these activities are logically linked via direct or indirect logic. If these activities have large Total Floats, the effect of uncertainties should be immaterial. However, if they are on a project critical path or near a critical path, the effect will likely be noticeable.

Without Quantitative Risk Analysis (QRA), it may not be possible to understand the effect of uncertainties on project delivery dates.

Logic in real-life schedules is much more complex. WPs have other than ‘Finish-to-Start’ types of dependencies, technical and resource constraints, activity and resource calendars, lags and leads. These factors impact the level of complexity of each WP.

Also, logic between WPs is more complex than just a ‘Finish-to-Start’ dependency between the last activity in one WP and the first activity in another WP. On top of this, there could be more than one dependency between WPs, and these dependencies could be somewhere inside each WP, not between the end and start points:

Example of complex logic between WPs

The volatility of Critical Path

Another challenge is to demonstrate a Critical Path in a high-level schedule. A WP may or may not be on a critical path. If it is, it doesn’t mean that all activities in the WP are critical. The critical activities in the WP could be somewhere inside of WP. There also could be many critical fragments.

A scheduler may summarise critical and not critical activities in a high-level schedule. Unfortunately, there is no guarantee that the critical path is going to be stable during the life of the project. The volatility of the critical path means that a high-level schedule has to be constantly redeveloped.

Detailed Schedule

The described challenge is relevant to detailed schedules, not just to Control schedules.

There are no commonly accepted rules that define the correct level of detail for each schedule. While there are some recommendations, practically the level of detail depends on portfolio standards, the experience of the master schedule, the capacity of the scheduling team, applied schedule and risk analysis tools, and some other factors.

Two schedules developed for the same project by two different project teams are unlikely to be identical. The difference may look immaterial but may have a significant impact to the results of Monte Carlo Simulation.

Schedule duration paradox

The probability of delivering this project based on the ‘Most Likely’ durations is only 29%. This example demonstrates ‘Schedule duration paradox’:

Schedule based on the most likely activity durations doesn’t have the most likely duration

This is one of the factors why projects are late. When project SMEs provide the ‘Most Likely’ estimations for each schedule activity, and a scheduler uses them to develop a deterministic (Critical Path Method) schedule, project stakeholders often assume that such a schedule has ‘most likely’ delivery dates. Calculated dates are used as project commitments. However, due to the complexity of logic and parallel streams, the probability of meeting these commitments is likely to be less than 50%. Sometimes significantly less.

Monte Carlo Simulation is one of the Quantitative Risk Analysis (QRA) methods that help to calculate achievable dates, but it has to be applied correctly. A high-level schedule doesn’t have the same level of complexity as it is in a detailed schedule. It impacts the project probabilities calculated based on the Monte Carlo Simulation method. The difference could be sufficient to drive the project in the wrong direction.

There are many other important MCS challenges. I will continue “unwrapping” them one by one in my future posts.

Alex Lyaschenko

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