> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dash360.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How the Dash360 Monte Carlo Works

> A complete reference for the Dash360 cost and schedule Monte Carlo: every variable that feeds the simulation, how cost and risk are sampled and combined, how the schedule network is calculated, and how to read the results.

## Overview

The Dash360 Monte Carlo runs on the Risk Analysis page (Risk > Risk Analysis). It is a single, unified engine: one set of simulation runs produces both the **Cost** distribution and the **Schedule** (project finish date) distribution at the same time, so the two views are always consistent with each other.

Each press of **Run** performs thousands of independent "iterations." In every iteration the engine:

1. Samples each activity's duration and each resource assignment's cost from its uncertainty distribution.
2. Rolls each risk event (does it occur this iteration?) and, if it occurs, samples its cost and schedule impact.
3. Sums all costs into a project total, and runs a critical path calculation to get a project finish date.

Recording those two numbers across every iteration produces the cost histogram and the finish-date histogram, plus the cumulative-probability "S-curves" and the percentile tables (the built-in rows are P10, P50, P70, P75, P80, and P90, plus any custom percentile you add).

Two run controls shape the whole simulation:

* **Iterations**: how many scenarios to simulate (more iterations gives a smoother, more stable distribution).
* **Random Seed**: the starting point for the random number generator. Re-running with the same seed and the same inputs reproduces the exact same results, which makes a run auditable. Leave it blank for a fresh random seed each time; the seed actually used is shown under the chart and can be reused.

***

## Shared concepts (apply to both Cost and Schedule)

### Simulation modes

A run can isolate where the variability comes from:

| Mode                                     | What it includes                                                                                                              |
| ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| **Combined (Uncertainty + Risk Events)** | Both estimating uncertainty (activity/cost distributions) and discrete risk events. This is the full picture and the default. |
| **Uncertainty Only**                     | Only the activity-duration and cost-estimate distributions. Risk events are switched off.                                     |
| **Risk Only**                            | Only the discrete risk events. Activities and costs are held at their deterministic (point) values.                           |

The mode is echoed in the chart subtitle so the result is never ambiguous.

### Distribution methods

Every uncertain input (an uncertainty class, or a risk's impact) is sampled from one of four shapes:

| Method           | Inputs used           | Behavior                                                                                    |
| ---------------- | --------------------- | ------------------------------------------------------------------------------------------- |
| **PERT**         | Min, Most Likely, Max | A smooth, Most-Likely-weighted curve (asymmetric Beta). The default and most common choice. |
| **Triangular**   | Min, Most Likely, Max | A sharper peak at Most Likely with straight sides.                                          |
| **Uniform**      | Min, Max              | Every value between Min and Max is equally likely; Most Likely is ignored.                  |
| **Single Point** | Most Likely           | No spread: the value is the same every iteration (deterministic).                           |

If an Uncertainty Class has its Min, Most Likely, and Max entered out of order, the engine sorts them before sampling, so a mis-keyed class will not error (but it also will not warn). This auto-sort applies to Uncertainty Classes only; a risk impact entered with its Min greater than its Max is not reordered. If a PERT or Triangular input is missing its Min or Max, it falls back to the Most Likely single point.

### Risk vs Mitigated Risk

The engine produces **two** distributions:

* **Risk** (the unmanaged, pre-response state): the project before any risk response actions are applied.
* **Mitigated Risk** (after planned responses): the project after the planned responses are applied.

The engine always computes both a Risk and a Mitigated Risk distribution. When at least one risk has a response that changes its outcome, both curves are shown so you can see how much the response plan buys you; if no risk is mitigated, only the Risk curve appears. The Mitigated Risk curve is the one used for contingency and the WBS rollup.

(These two labels are configurable per project; they default to **Risk** and **Mitigated Risk**.)

### Which risks are included

The Risk Analysis page has a **Status** filter and a **Classification** filter (the floating filter bar) that decide which risks enter the simulation. Both the Monte Carlo and the Scenario Planner use the same selection, so the planner always shows exactly the risk set being simulated.

* **Status** defaults to **Active**. You can add Proposed, Realized, Retired, or Deprecated.
* **Classification** defaults to **Threats Only**. You can switch to Opportunities Only or All.

**Threats** add cost and extend the schedule (positive impact). **Opportunities** reduce cost and pull the schedule in (negative impact).

### Percentiles and the S-curve

The cumulative-probability S-curve answers "what is the chance the outcome is at or below this value?" A percentile (for example **P80**) is the value you have an 80% chance of not exceeding. P10 is optimistic, P50 is the median, P80/P90 are conservative. Use the checkboxes in the percentile tables to overlay reference lines on the chart, or **+ Add** to plot any custom percentile.

***

## Uncertainty: the Uncertainty Cascade

Estimating uncertainty is defined by **Uncertainty Classes** and assigned through the **Uncertainty Cascade** on the Risk Analysis page.

### Uncertainty Classes

An Uncertainty Class is a named distribution defined as **percentage factors of the deterministic value**, with a chosen distribution method. For example, a "Conservative" class with Schedule factors 75 / 100 / 105 means an activity can finish as fast as 75% of its planned duration and as slow as 105%.

Each class holds **separate Cost and Schedule factors**, so the same class can shape cost differently from duration:

* **Cost factors** (Min / Most Likely / Max %) scale a resource assignment's cost.
* **Schedule factors** (Min / Most Likely / Max %) scale an activity's duration.

### The cascade and inheritance

Classes are assigned down a hierarchy: **Project > WBS > Work Package > Activity > Resource Assignment**. An assignment at any level cascades down to everything beneath it, and a more specific level overrides a less specific one. In the cascade grid:

* A **lock** icon marks a row with its own explicit assignment.
* An **italic** row is inheriting from a parent.
* The **Off** position (the "Deterministic (single point)" class) stops inheritance and forces no spread for that branch.

An activity or resource assignment with no class anywhere up its chain uses a built-in deterministic fallback (single point, no spread), so unconfigured items simply contribute their planned value.

***

## Risk events

A risk event is a discrete thing that may or may not happen. In each iteration the engine draws a single random number per risk and compares it to the risk's **probability** to decide whether it occurs. If it occurs, the engine samples the risk's cost and schedule impact from its distributions.

### Handling strategies (Risk vs Mitigated Risk)

How the Mitigated Risk impact is derived depends on the risk's **Risk Handling Strategy**:

| Strategy (Threat / Opportunity)           | Mitigated Risk behavior                                                                             |
| ----------------------------------------- | --------------------------------------------------------------------------------------------------- |
| **Accept / Exploit**                      | Mitigated Risk mirrors the Risk value exactly (no change planned).                                  |
| **Avoid**                                 | Mitigated Risk impact is zero (the risk is eliminated).                                             |
| **Mitigate / Transfer / Enhance / Share** | Mitigated Risk is sampled from the separately entered Mitigated Risk Probability and Impact fields. |

The same random draw governs whether the risk fires on both the Risk and Mitigated Risk sides in a given iteration, so the two distributions stay correlated and comparable.

### Response actions

For Mitigate and Enhance risks, individual **Response Actions** can each carry a Probability Reduction, a Cost Reduction, and a Schedule Reduction. Active actions reduce the risk's Mitigated Risk probability and impact. (The Scenario Planner, below, can turn individual actions on and off.)

***

## Scenario Planner

A saved **scenario** lets you ask "what if?" without changing the underlying risk data. A scenario can:

* Turn specific **risks** off (a deactivated risk contributes nothing: its probability becomes zero for that run).
* Turn specific **response actions** on or off for Mitigate risks (so you can model a partial or expanded response plan).

When a scenario is selected for a run, the engine applies those on/off choices before sampling. An action left at its default stays active; only the changes you make are stored, and the engine treats every in-scope action as active unless the scenario explicitly turns it off.

***

## Cost specifics

### Baseline and cost sampling

The **deterministic baseline** is the sum of the selected cost class's resource-assignment costs (Budget by default) at their planned values (the vertical line on the cost chart). Each iteration samples every resource assignment's cost from its Cost Uncertainty Class, then adds the sampled risk-event cost contributions to produce that iteration's total cost.

### Cost Overlay (cost that scales with duration)

Normally cost and duration are sampled independently. **Cost Overlay** links them: when an activity (or resource assignment) is flagged as an overlay, a sampled increase in that activity's duration scales its cost up by the same ratio. This captures the common reality that a task running long also costs more.

* The flag lives on the activity ("Cost scales with duration"), with a per-resource-assignment override of Inherit / Yes / No.
* The scaling uses the iteration's **uncertainty-only** duration ratio (so it does not double-count the risk-event impact).

### Correlation (shared random draws)

To avoid unrealistically independent results, the engine shares one random draw between an activity's duration and the costs of the resource assignments on that activity (and a shared draw per work package). So when an activity is sampled "long" in an iteration, its associated costs tend to be sampled "high" in the same iteration. This positive correlation widens the combined distribution in a realistic way.

### Cost contingency and its decomposition

**Cost contingency** at a confidence level is that percentile minus the deterministic baseline (for example, P80 cost minus baseline). The **Contingency Decomposition** panel breaks the contingency into independent sources at the chosen confidence level:

| Source                        | What it is                                                                                                                                                                                           |
| ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Estimating uncertainty**    | Cost growth from the resource-cost distributions alone.                                                                                                                                              |
| **Cost overlay**              | The additional cost from duration-scaled overlay (cost-only; no schedule analog).                                                                                                                    |
| **Risk events**               | Cost growth from discrete risks alone.                                                                                                                                                               |
| **Interaction / correlation** | The combined contingency minus the parts. A negative value means the sources diversify (they do not all hit their high end together), so the combined contingency is less than the sum of the parts. |

Each source is estimated by running the same iterations through that source alone, so the parts may not sum exactly to the combined contingency; the gap is the Interaction line.

***

## Schedule specifics

The schedule simulation builds an activity network and runs a **Critical Path Method (CPM)** calculation in every iteration on that iteration's sampled durations.

### The CPM calculation

A forward pass computes early start/finish dates from the project start (or the data date for in-progress projects); a backward pass computes late dates and total float. The project finish date is the latest finish among the activities that actually drive the schedule. Total float is tracked so the engine can report each activity's **criticality** (the share of iterations in which it sat on the critical path).

### Link (dependency) types

The network honors three relationship types between activities:

| Type                      | Meaning                                                        |
| ------------------------- | -------------------------------------------------------------- |
| **Finish-to-Start (FS)**  | Successor starts after predecessor finishes (the most common). |
| **Start-to-Start (SS)**   | Successor starts relative to predecessor's start.              |
| **Finish-to-Finish (FF)** | Successor finishes relative to predecessor's finish.           |

**Start-to-Finish (SF)** relationships are **not modeled** and are excluded. SF links are rare and usually a modeling error; an activity whose only predecessor is an SF link will be scheduled from the project start, which can make its dates look optimistic. Convert SF links to a normal Finish-to-Start link for accurate results.

### Activity types

Not every activity is sampled or drives the finish date:

| Type                          | Sampled?           | Drives finish?                                |
| ----------------------------- | ------------------ | --------------------------------------------- |
| **Task / Resource-dependent** | Yes                | Yes                                           |
| **Start / Finish Milestone**  | No (zero duration) | Yes (as a point in time)                      |
| **Level of Effort (LOE)**     | No                 | No (its span follows its bounding activities) |
| **WBS Summary**               | No                 | No                                            |

### In-progress projects

For a project with status, the schedule is calculated from the **data date** (the snapshot's status date) forward; completed work is not re-simulated. An activity's **remaining** duration is its original duration scaled by the percent complete (an activity at 100% contributes zero remaining duration and lets its successors proceed from the data date).

### Calendars

Durations and lags are stepped in **working time**, not raw calendar days:

* Each activity uses its **own assigned calendar** if it has one.
* If not, it uses the **project's default calendar**.
* If no default calendar is set, it falls back to a **5-day work week** (Monday through Friday).
* A lag on a dependency is stepped on the **predecessor's** calendar.

Per-activity calendars currently affect this risk analysis only (not the Schedule Viewer). Float across activities on different calendars is approximate and may differ slightly from other schedulers.

### How risk schedule impact reaches the finish date

A risk's schedule impact has to land somewhere on the network to move the finish date:

* A risk **mapped to one or more activities** extends those activities' durations. With **Absolute** mapping the full impact is applied to each mapped activity; with **Relative** mapping the impact is split by each mapping's weight.
* A risk with **no activity mapping** applies its sampled delay directly to the **project finish** (threats push it out, opportunities pull it in). This way an unmapped risk still affects the schedule rather than being silently dropped. Multiple unmapped risks add in series, which is intentionally conservative.

A mapped risk only moves the finish when at least one of its mapped activities is on the critical path; a risk mapped only to activities with float will not change the finish.

### Constraints are ignored

The simulation intentionally **ignores schedule constraints** (Start/Finish No Earlier/Later Than, Must Start/Finish On, As Late As Possible). A constrained date never moves, which would distort the analysis; remove constraints for accurate schedule risk results.

### Schedule contingency and its decomposition

**Schedule contingency** is the number of days between the deterministic baseline finish and the finish date at the chosen confidence level. It is shown primarily in **calendar days** (unambiguous, and consistent with the finish dates and the Delta column), with the **working-days** equivalent alongside. Working days is counted on the **project's default calendar** (its work week and holidays), falling back to a plain five-day week only if no default calendar is set; because it is anchored to that one calendar, calendar days is the safer figure when the driving path spans multiple calendars. Its decomposition mirrors the cost side, with three sources (there is no cost-overlay analog for schedule):

| Source                            | What it is                                                                                       |
| --------------------------------- | ------------------------------------------------------------------------------------------------ |
| **Activity-duration uncertainty** | Schedule growth from the duration distributions alone (no risk events).                          |
| **Risk events**                   | Schedule growth from discrete risks alone (deterministic durations plus Mitigated Risk impacts). |
| **Interaction / correlation**     | The combined contingency minus the two parts. A negative value means the sources diversify.      |

***

## Reading the results

### Percentile tables and the Mean

Each row of the Percentile Summary (cost) and Percentile Details (schedule) shows the Risk and Mitigated Risk value at that confidence level. The cost tables also show the Reduction and % Improved between Risk and Mitigated Risk; the schedule table shows the Delta in days.

### Monte Carlo by WBS, and why percentiles do not sum

The **Monte Carlo by WBS** rollup shows the Mitigated Risk cost distribution rolled up the WBS tree. Within every single iteration the dollars roll up exactly (a parent equals the sum of its children), which is why the **Mean** column ties out top to bottom. The **percentile** columns do not sum, and should not: a percentile is found by re-sorting each row's own iteration values, and a parent's P80 comes from a different iteration than each child's P80. Because risks do not all hit at once, a parent's upper percentiles are lower (and its lower percentiles higher) than the sum of its children. Capturing that diversification is the entire point of running Monte Carlo at the project level. When you need a column that ties out across the tree, use the Mean.

### Key takeaways

* The **Mean** is additive (it rolls up); **percentiles** are not.
* A wider distribution means more uncertainty.
* The gap between the Risk and Mitigated Risk curves is the value of your response plan.
* Project-level contingency is smaller than the sum of part-level worst cases because of diversification, and that is correct.

### Per-node distributions and bucketing

The Risk Analysis page lets you drill into the Monte Carlo result for any single node from the **Reports** column of the Uncertainty Cascade (Cost, Schedule, and Schedule Delay Drivers). Those per-node views are stored differently from the project total, and it helps to know how.

The **project** result keeps every iteration, so the project charts and percentiles are **exact**. The per-node drill-downs (WBS, Work Package, Activity, Resource Assignment) instead keep a **compact summary** of each node's distribution: a 30-slot histogram (think of it as a tally of how many iterations landed in each slice of the range) plus the exact mean, minimum, maximum, and deterministic value. A real project has hundreds of nodes, so storing every iteration for every node would make a saved simulation enormous; the summary keeps it small, at a small and well-understood cost in precision.

What that means when you read a sub-node chart:

* The **mean, minimum, maximum, and deterministic** values are exact at every node.
* The **project** percentiles are exact.
* A **sub-node's percentiles** are read from its histogram, so they can differ from the exact value by roughly **0.1% to 0.5% of that node's own range** (about a day on a multi-year schedule node, or a few hundredths of a percent on a large cost node). The overall shape of the distribution is preserved.
* A node with **no variance** (for example a fixed-price resource, or a milestone) shows its single exact value at every percentile, with no artificial spread.

If you need an exact percentile for a specific sub-node, read the project-level result (always stored in full), or focus a run on that scope.

***

## Correlation (Pro)

By default every activity and every risk is sampled independently each iteration. Independent draws tend to cancel out (one activity runs long while another runs short), which understates the real spread of the total. **Correlation** lets you tell the simulation that certain items move together.

There are two independent correlation surfaces:

* **Activity correlation** (on the Cost and Schedule Uncertainty tree): pick a driving activity, then select the activities that should follow it. Each iteration the driven activities inherit the driver's uncertainty draw, so they run long or short together. Because an activity's cost draw follows its schedule draw, correlated activities move together on both cost and schedule.
* **Risk correlation** (on the Risk Register): pick an independent risk, then select the risks correlated to it. Correlated risks tend to occur together and to be large together (both the occurrence and the impact draws are correlated).

Each correlation group has a single **coefficient** from -100% to +100%:

* **+100%**: the followers take the driver's draw exactly (they fully move together).
* **A positive value below 100%**: the followers move partly with the driver and partly on their own.
* **0%**: independent (no effect).
* **A negative value**: the followers tend to move opposite the driver.

Correlation is applied at the random-draw level using a single-factor Gaussian copula, so the shape of each item's own distribution is preserved. Positive correlation widens the total cost and finish-date distributions (higher P80 and P90) because related items no longer cancel out, which is the more realistic result. The graphs keep the same shape and chart types; only the numbers shift.

In this release each activity or risk can belong to only one correlation group, and an item cannot be both a driver and a follower. Correlation is a Pro feature.

<Note>
  Correlation links like to like (risk to risk, or activity to activity). It is not the same as **Activity Mapping**, which routes a risk's schedule impact to activities. For a plain-language walk-through of all three features, when to use each, and how they relate, see [Correlation and Activity Mapping](/user-guide/risk/correlation-and-mapping).
</Note>

***

## Assumptions and caveats summary

* Schedule **constraints are ignored**; remove them for accurate results.
* **Start-to-Finish (SF)** links are excluded; convert them to Finish-to-Start.
* Activities with **no calendar** use the project default, or a 5-day work week if none is set.
* A risk's schedule impact only moves the finish if it is mapped to a critical-path activity, or is **unmapped** (in which case it extends the project finish directly).
* Per-activity calendars affect the **risk analysis only**, not the Schedule Viewer; mixed-calendar float is approximate.
* Components in the contingency decompositions are estimated independently and may not sum exactly to the combined contingency; the difference is the Interaction / correlation line.
* Per-node distributions (WBS / Work Package / Activity / Resource Assignment, from the Reports column) are stored as compact histogram summaries, so their percentiles are approximate (within about 0.5% of the node's range); the project result is stored in full and is exact.