Overview
Advanced Risk Modelling in @Risk: Behaviour-Driven Patterns for QCRA
Most QCRA models are built correctly, but many still miss how risks actually behave.
In real projects, risks are rarely simple or static. Some are conditional. Some only matter once a threshold is crossed. Some interact with each other, change form, or stop being relevant as the project evolves. Those behaviours are often present in workshops and discussions, but they are not always carried through into the QCRA model.
This article is about modelling behaviour, not just picking distributions. It sets out four practical modelling patterns that can be implemented directly in Excel and @Risk to reflect how risks really behave in QCRA models, including probabilistic scenario selection, step-change impacts, interaction between risks, and conditional gating.
The goal is not to make models more complicated. It is to make them structurally honest, so the outputs support real decisions rather than false confidence produced by smooth curves.
These patterns are not always required. They are most useful when behaviour is clearly conditional, discrete, or state-dependent. For straightforward risks, simpler representations are often sufficient.
Related reading (optional):If you are interested in distribution choice, I have explored this topic in more detail in the following article:
Better Than Rules of Thumb: Choosing Risk Distributions by Testing Behaviour, Not Opinion
Probabilistic Scenario Selection
(mutually exclusive outcomes with uncertainty inside each outcome)
Some risks do not have a single credible impact range. Instead, they have distinct outcomes, each with its own uncertainty.
For example:
a risk may result in minor rework, major rework, or a full redesign,
these outcomes are mutually exclusive,
and each outcome behaves differently once it occurs.
Behaviour being modelled
Exactly one outcome applies per iteration.
Once selected, uncertainty is sampled only within that outcome. Outcomes are not blended.
Conceptual logic
RiskBernoulli(p) *
RiskDiscrete(
{Outcome A, Outcome B, Outcome C},
{p1, p2, p3}
)where p is the probability of occurrence
Occurrence may be modelled explicitly using functions such as RiskBernoulli, or implicitly through conditional logic within the model, depending on how the behaviour is defined.
Each outcome may be represented by:
a distribution,
a calculation,
a deterministic value,
or a more complex logic block.
The key point is that selection is probabilistic but exclusive.
Example (Excel logic)
Scenario = RiskDiscrete({"A","B","C"},{50%,30%,20%})
Impact = IF(Scenario="A",
RiskTriang(100000,200000,350000),
IF(Scenario="B",
RiskPert(300000,500000,900000),
1200000))Ground contamination may result in minor treatment, major remediation, or full redesign of foundations. RiskDiscrete selects one of the defined scenarios (A, B, or C) per iteration, in line with the specified probabilities. Only one outcome occurs in each iteration, followed by conditional impact logic for the selected outcome (Figure 1).
The following describes how similar behaviour is typically represented in schedule risk analysis models. The implementation differs, but the underlying logic is comparable.
QSRA equivalent
Conditional branching in the schedule, where only one path is activated per iteration.
When Pattern 1 is essential
When outcomes are mutually exclusive.
When stakeholders describe behaviour as "if this happens, then that".
When a single smooth distribution would blur fundamentally different cost mechanisms.
Pattern 2
Probabilistic Triggers and Step-Change Impacts
(uncertain triggers with deterministic or block-based consequences)
Some impacts do not scale smoothly. They arrive in blocks, once a trigger is crossed.
This is where many QCRA models fail, smoothing step-based behaviour into continuous curves and treating fixed responses as random variation.
Pattern 2 separates:
uncertainty in whether something happens, from
certainty in what happens once it does.
Behaviour being modelled
A trigger variable is evaluated.
If the trigger exceeds a threshold, a block of cost is applied.
If not, nothing happens.
Crucially, the trigger itself can be probabilistic.
Conceptual logic
IF( Trigger > Threshold,
StepImpact,
0 )Where:
Trigger may be probabilistic (for example, represented by a distribution) or deterministic, depending on how the condition is defined.
StepImpact is often a fixed value, but can also include uncertainty if the response itself is variable.
This pattern deliberately mixes probabilistic behaviour with deterministic consequences when that is how the risk actually behaves.
Example (Excel logic)
Delay = RiskPert(10,25,60)
Impact = IF(Delay>30,
1200000,
0)Here, delay is uncertain, but once the 30-day threshold is crossed, a fixed acceleration package of $1,200,000 is applied. The consequence does not scale gradually. It switches on (Figure 2).
QSRA equivalent
Recovery or acceleration logic, where additional activities or sequences are inserted only if delay exceeds a defined threshold.
When Pattern 2 is essential
When costs are incurred as fixed actions or packages.
When escalation is abrupt rather than gradual.
When smoothing behaviour would understate tail exposure.
Pattern 3
Risk Dependency and Interaction Logic
(how risks influence each other)
Risks rarely act independently.
One risk may:
enable another risk,
suppress it,
worsen it,
or change the way it must be modelled altogether.
Pattern 3 models these cause-and-effect relationships explicitly, using logic rather than correlation.
Correlation changes how often risks move together.Pattern 3 changes what is allowed to happen(Figure 3).
These interactions can appear in several forms, outlined below.
Pattern 3A – Enabling dependency
(Risk A makes Risk B possible)
Risk B cannot occur unless Risk A occurs.
IF( RiskA_Occurrence = 1, RiskB_Output, 0 )This is a hard dependency. Without Risk A, Risk B does not exist.
Example (Excel logic)
RiskA_Occurrence = RiskBernoulli(pA)
RiskB = RiskBernoulli(pB) * RiskPert(200000,400000,800000)
Impact = IF(RiskA_Occurrence=1,
RiskB,
0)Here, Risk B has its own probability and impact distribution, but it is only allowed to operate if Risk A occurs. Without Risk A, Risk B is structurally disabled.
QSRA equivalentConditional existence of activities, where downstream tasks only occur if a prior condition is met.
Pattern 3B – Suppressing dependency
(Risk A reduces Risk B)
Risk B exists under normal conditions. If Risk A occurs, Risk B is reduced.
IF( RiskA_Occurrence = 1, RiskB_Reduced, RiskB_Base )This typically represents decisive outcomes that collapse uncertainty.
Example (Excel logic)
RiskA_Occurrence = RiskBernoulli(pA)
RiskB_Base = RiskBernoulli(pB) * RiskPert(200000,400000,800000)
RiskB_Reduced = RiskBernoulli(pB_Reduced) * RiskPert(50000,150000,300000)
Impact = IF(RiskA_Occurrence=1,
RiskB_Reduced,
RiskB_Base)Here, Risk B exists in both cases. If Risk A occurs, Risk B may have lower likelihood, lower severity, or both. Risk A suppresses exposure, not existence.
QSRA equivalentReduction or removal of downstream activities or uncertainty following a prior event or decision.
Pattern 3C – Escalating dependency
(Risk A worsens Risk B)
Risk B can occur independently. If Risk A also occurs, Risk B becomes more severe.
Impact = IF( RiskA_Occurrence = 1, RiskB_Escalated, RiskB_Base )This mirrors Pattern 3B, except exposure increases rather than decreases. The structure of the risk is unchanged, only the parameters differ.
QSRA equivalentTightening logic or worsening durations once a triggering condition is met.
Pattern 3D – Conditional reshaping
(Risk A changes how Risk B must be modelled)
This is the most advanced and most commonly misunderstood dependency pattern.
Here, Risk B may exist in all cases, but the way its impact is modelled can change depending on Risk A.
This is not about adjusting likelihoods or impact ranges.
It is about changing the logic that generates impact.
IF( RiskA_Occurrence = 1,
ImpactLogic_B2,
ImpactLogic_B1 )Unlike Pattern 2, which applies a step-change once a condition is met, this pattern selects between alternative impact mechanisms. The impact is generated in all cases, but the mechanism changes.
ImpactLogic_B1 and ImpactLogic_B2 may use entirely different distributions or calculations.
One may be probabilistic, the other fully deterministic.
Only one logic applies per iteration. Impacts do not stack.
Example (Excel logic)
RiskA_Occurrence = RiskBernoulli(pA)
Impact = IF(RiskA_Occurrence=1,
1200000,
RiskBernoulli(pB) * RiskPert(200000,400000,800000))If Risk A occurs, Risk B is replaced with a fixed redesign cost. If not, Risk B behaves as a probabilistic rework risk. The modelling logic itself changes, not just the parameters.
RiskA_Occurrence = RiskBernoulli(pA)
RiskB_Occurrence = RiskBernoulli(pB)
Impact = IF(AND(RiskA_Occurrence=1, RiskB_Occurrence=1),
RiskPert(1500000,2200000,3500000),
IF(RiskA_Occurrence=1, RiskPert(300000,600000,900000),
IF(RiskB_Occurrence=1, RiskPert(200000,500000,800000), 0)))Two component defects are possible. If either occurs individually, repair follows its own cost distribution. If both occur together, the repair strategy changes and a replacement solution is required. The combined case is therefore modelled using a separate distribution rather than summing the individual risks.
QSRA equivalentRemoval and replacement of activities or entire sub-networks, such as switching from a normal execution path to a recovery network.
When conditional reshaping is justified
When behaviour genuinely changes, not just magnitude.
When incremental and recovery behaviour should never coexist.
When forcing a single distribution would distort tail behaviour.
Pattern 4
Conditional Logic and Risk Gating
(controlling when risks are allowed to apply)
Some QCRA models fail not because impacts are wrong, but because risks are allowed to contribute after they are no longer valid.
Pattern 4 prevents that.
It does not define impacts.It controls when other modelling patterns are allowed to apply.
Behaviour being modelled
Risks are valid only in certain states.
Once a gate is passed, the risk must contribute zero.
Conceptual logic
IF( GateState = TRUE,
RiskOutput,
0 )Once the gate closes, the contribution is forced to zero, regardless of how RiskOutput is defined.
Example (Excel logic)
ProjectStage = [Risk Register Stage Column]
Impact = IF(ProjectStage="Design",
RiskTriang(100000,250000,500000),
0)The risk applies only while the project is in Design. Once the stage changes, it is structurally gated (Figure 4).
QSRA equivalent
Logic switches that disable activities or paths once a milestone or state condition is reached.
When Pattern 4 is essential
When risks cease to exist after decisions or milestones.
When late-stage tails are driven by early-stage risks.
When uncertainty should genuinely collapse over time.
How the patterns work together
Pattern 1 selects which outcome occurs.
Pattern 2models threshold-driven step changes.
Pattern 3models interaction between risks.
Pattern 4 controls when any of the above are allowed to apply.
The key is not complexity, but transparency. Each pattern should be explainable, reviewable, and traceable back to how the risk is described.
The four patterns above describe how risks behave. Some risks, however, are better described by how impacts accumulate over multiple occurrences.
These are not alternative states or conditional behaviours, but repeated events occurring multiple times within the same iteration.In those cases, the structure is frequency and severity, not scenario selection. Using RiskCompound, a sampled count distribution such as RiskPoisson determines how many severity samples are drawn and summed, producing tail behaviour that cannot be replicated by a single aggregated distribution(Figure 5).
Example (Excel logic)
EventCount = RiskPoisson(3)
Impact = RiskCompound(EventCount,
RiskTriang(50000,100000,200000))On average, three defect events occur per iteration. The number of occurrences is sampled using RiskPoisson, and each occurrence carries its own repair cost sampled from a triangular distribution. The total impact is the sum of those occurrences within the same iteration.
These modelling patterns are not specific to Monte Carlo simulation. The logic can be applied in deterministic models or scenario analysis. However, without simulation, the ability to represent interaction, repeated events, and tail behaviour becomes limited.Used together, these patterns allow QCRA models to reflect real project behaviour rather than statistical convenience.
What comes next
This article focused on modelling behaviour inside advanced QCRA models.
In the next article, I will focus more directly on scenario-style risks, where outcomes are discrete and mutually exclusive. I will look at how to structure these risks clearly, and how to implement scenario-based modelling when QCRA models or RMIS exports are constrained.
After that, the series will shift from modelling to quality assurance. I will look at practical approaches for reviewing QCRA models, followed by a companion piece on quality assurance for QSRA models.
Closing thought
Advanced modelling is not about adding complexity.
It is about representing behaviour explicitly.
If a model smooths what is discrete, ignores interaction, or carries risks beyond where they are valid, the results may look stable but will not reflect how the project actually behaves.
These patterns exist to prevent that.
