Specialized Risk Analyses practice questions

The activity with the highest 'Float' value.

Why it fails: High float usually indicates lower impact on the critical path.

The activity with the lowest baseline duration.

Why it fails: Duration length does not necessarily correlate with risk impact.

The activity with the most resource assignments.

Why it fails: Number of resources is not the primary driver for sensitivity in a tornado diagram.

$44,000

Why it fails: This excludes the initial decision cost.

$60,000

Why it fails: This is a calculation error in applying the probability distribution.

$34,000

Why it fails: This fails to account for the probability weighting of the success scenario.

The 'Risk Threshold' is set to zero for all activities.

Why it fails: Setting thresholds to zero does not improve the statistical convergence of the simulation.

The 'Resource Calendar' is disabled.

Why it fails: Disabling the resource calendar would remove necessary constraints on duration.

The 'Baseline Project' is set to read-only mode.

Why it fails: Baseline settings do not influence the random sampling of the Monte Carlo engine.

Set all task priorities to 'High'.

Why it fails: Priority does not address calendar constraints.

Disable the 'Critical Path Method' (CPM) engine.

Why it fails: CPM is required to calculate the project finish date.

Increase the 'Buffer' duration.

Why it fails: Buffers are passive; resource calendars are active constraints.

Change the simulation random seed.

Why it fails: Changing the seed only changes the simulation sequence.

Remove the task from the schedule entirely.

Why it fails: Removing tasks is generally not an option for project scope.

Increase the iteration count of the simulation.

Why it fails: This improves accuracy, it does not mitigate project risk.

The risk is already scheduled to be mitigated next month.

Why it fails: Mitigation timing is irrelevant to the need for analysis.

The risk has a low probability of occurring.

Why it fails: Low probability risks are often excluded from detailed quantitative study.

Delete all non-critical tasks from the model.

Why it fails: This would invalidate the schedule network logic.

Update the project budget based on the results.

Why it fails: Budget updating is a separate, subsequent step.

A predefined risk response plan for each identified risk.

Why it fails: Risk response plans are outputs of risk management planning, not inputs to Monte Carlo simulation. The simulation models the inherent uncertainty in project variables, regardless of planned responses. While responses may later alter distributions or probabilities, they are not required to run the simulation. This option misplaces the sequence of risk processes, as simulation is part of quantitative analysis, which precedes response planning.

A fixed discount rate for cost-benefit analysis.

Why it fails: A discount rate is used in financial analysis to calculate net present value, not in Monte Carlo simulation for risk analysis. Monte Carlo focuses on modeling uncertainty in project variables, not on discounting future cash flows. While cost-benefit analysis may be part of project selection, it is not an input to the simulation itself. This option confuses a financial metric with a risk analysis requirement.

A deterministic schedule with no uncertainties.

Why it fails: A deterministic schedule assumes fixed durations and costs, which contradicts the purpose of Monte Carlo simulation. The simulation is designed to incorporate uncertainty; using a deterministic schedule would yield the same result every iteration, providing no probabilistic insight. While a baseline schedule is needed as a framework, the uncertainties must be layered on top. This option misrepresents the core requirement of the technique.

You reset the probabilities of all chance nodes to zero.

Why it fails: Folding back never resets probabilities; it multiplies each outcome value by its branch probability and sums these at chance nodes, then rolls the resulting EMV back through the tree. Resetting probabilities to zero would destroy the analysis. Probabilities are estimated beforehand and remain fixed inputs throughout the calculation.

You assign risk scores to each decision alternative.

Why it fails: Folding back calculates expected monetary value by weighting each chance node's outcomes by probability, then rolling values back to compare decision alternatives. Risk scores are assigned earlier, during risk identification and qualitative analysis. Assigning scores is not the arithmetic rollback that produces EMV for each path.

You calculate the probability of each branch ending in failure.

Why it fails: Folding back computes expected monetary value at each chance node and rolls those values back through the tree to the root, selecting the optimal path. It does not calculate branch failure probabilities; that is sensitivity or Monte Carlo analysis. This option confuses probability assessment with the EMV rollback calculation that folding back actually performs.

The variable is independent of the outcome.

Why it fails: Independence would appear as a shapeless cloud with no directional trend, whereas a diagonal line shows the outcome tracking the variable's values. It is tempting because both involve visual patterns, but the diagonal slope specifically evidences strong sensitivity rather than independence.

Low sensitivity.

Why it fails: A tight diagonal cluster indicates a strong positive correlation between the variable and the outcome, meaning high sensitivity, not low. It is tempting because clustering can suggest limited spread, but the diagonal pattern itself shows the variable drives the outcome's variation.

The simulation failed to converge.

Why it fails: Non-convergence produces erratic, scattered or non-repeating results across iterations, not a coherent diagonal band. It is tempting because a suspiciously neat pattern can look artificial, but a diagonal cluster is the expected signature of a strongly correlated, sensitive variable.

To cover scope creep requested by the client.

Why it fails: Contingency reserve covers identified risks with quantified impact; client-requested scope creep is unapproved scope change funded from the change-control process, not the reserve. It is tempting because both consume budget, and it would be correct when funding a known risk response such as a supplier delay.

To account for inflation over the project lifecycle.

Why it fails: Inflation is handled through escalation clauses or a separate inflation allowance, not contingency. Contingency covers identified risks and uncertainty within the cost baseline, sized via expected monetary value or Monte Carlo analysis. It would be tempting when budgeting for multi-year projects where currency erosion matters, but that is a forecasting adjustment, not risk response.

To replace the management reserve.

Why it fails: Contingency reserve addresses identified risks; management reserve covers unknown-unknowns and sits above the cost baseline, so it cannot be replaced. It is tempting because both are budget buffers, and it would be correct when funding unforeseen work outside the approved baseline scope.

Normal distribution.

Why it fails: Normal distribution is symmetrical and unsuitable for skewed duration data.

Discrete distribution.

Why it fails: Discrete distributions are for categorical outcomes, not continuous time durations.

Uniform distribution.

Why it fails: Uniform distribution assumes all values are equally likely, which is rarely true for project tasks.

To double the number of items in the Risk Register.

Why it fails: The Risk Register's item count is unaffected by whether opportunities are included in EMV; both threats and opportunities are already logged. It is tempting because a fuller register feels thorough, yet EMV combines probability and impact values to give net expected exposure, not to inflate the register.

To ensure the contingency reserve is maximized.

Why it fails: EMV sums probability-weighted outcomes to derive expected monetary value, not to maximise any reserve; threats reduce and opportunities increase the net figure. It is tempting because contingency reserves are sized from EMV output, but the calculation's purpose is an unbiased net exposure, not a larger reserve.

To satisfy regulatory reporting requirements.

Why it fails: EMV aggregates probability-weighted monetary outcomes across the whole risk register; regulatory reporting never depends on including opportunities. It is tempting because governance frameworks do mandate documented risk reporting, and EMV outputs can feed those reports — but the calculation's purpose is an accurate expected value, which omitting positive risks would understate.

It reduces the number of iterations required for convergence.

Why it fails: Correlation changes how durations are sampled across iterations, not how many iterations the Monte Carlo simulation runs; convergence depends on iteration count and result stability. The option tempts because correlated inputs can narrow output variance, but the setting itself does not control iteration volume or stopping criteria.

It forces all tasks to have the same duration.

Why it fails: Correlation samples each task's duration from its own distribution while linking deviations via a correlation coefficient, so durations vary and diverge. Forcing identical durations would require deterministic values, which correlation does not impose. The option tempts because correlation links tasks, but it preserves individual three-point estimates rather than equalising them.

It automatically removes all risk events from the schedule.

Why it fails: Correlating task durations applies a correlation coefficient to sampled durations across tasks; it never deletes risk events, which remain in the risk register and are applied separately during simulation. The option is tempting because correlation does alter the sampled schedule, but risk-event removal is a manual modelling action, not a simulation setting.

Stakeholder Engagement Plan.

Why it fails: The Stakeholder Engagement Plan defines how stakeholders are identified and involved, not the risk information itself. It is the correct input for planning stakeholder communication, but quantitative analysis draws its risks from the Risk Register, which already lists identified and prioritised risks.

Lessons Learned Repository.

Why it fails: A lessons learned repository stores historical information from past projects, not the current project's identified risks awaiting quantitative analysis. It is tempting because it genuinely informs risk identification, and it would be correct when gathering analogous data to seed a risk register or improve identification techniques.

Project Charter.

Why it fails: The project charter authorises the project and names high-level objectives, but it holds no structured risk register entries, so it cannot feed quantitative analysis. It is tempting because it is a genuine project input, yet it would be the right choice only for confirming scope boundaries or success criteria at initiation.

The average cost of the project.

Why it fails: The mean of the simulated cost distribution sits near the middle of the S-curve, around P50, not at P80. Averaging is tempting when summarising cost data, and the mean would be the right figure for expected-value budgeting, but P80 is a confidence level, not a central tendency.

The cost value representing the 20th percentile of risks.

Why it fails: P80 marks the cost exceeded in only 20% of simulation iterations, so it sits at the 80th percentile of total cost outcomes, not the 20th percentile of risks. Percentile framing is tempting because the number 20 appears, but the curve plots cumulative cost probability, not risk counts.

The baseline cost before risk adjustments.

Why it fails: P80 is the cost value with an 80% probability of not being exceeded, incorporating contingency from the simulation; it is not a pre-risk baseline. It is tempting because both represent cost figures, and a baseline would be correct where the question asks for the approved budget before risk adjustments.

The two tasks are perfectly independent.

Why it fails: A coefficient of -0.8 indicates a strong inverse relationship, where one task's duration tends to rise as the other falls, not independence. It is tempting because the negative sign suggests no linkage, and a value near zero would correctly indicate the tasks are independent.

The correlation is too weak to be significant.

Why it fails: Magnitude, not sign, determines strength: -0.8 is a strong correlation, close to the -1.0 extreme. It tempts because negative values are sometimes misread as weak, but the sign only shows inverse direction. Weak correlation would be a value near zero, such as -0.1.

The tasks will always finish at the same time.

Why it fails: A coefficient of -0.8 signals a strong inverse relationship: as one task's duration rises, the other's tends to fall, not that both finish simultaneously. It tempts because magnitude 0.8 is high, but the negative sign denotes opposite movement, and correlation never guarantees identical completion times.

It provides a single, definitive project completion date.

Why it fails: Monte Carlo produces a probability distribution of completion dates, not one definitive date; its output is a confidence-level curve from which a date at a chosen percentile is read. It is tempting because deterministic scheduling does yield a single date, but that certainty is exactly what simulation replaces with probabilistic ranges.

It requires less data to perform than static analysis.

Why it fails: Monte Carlo simulation consumes more input data, not less: it needs probability distributions for each activity's duration, cost or risk, plus correlation assumptions, whereas static analysis needs only single-point estimates. It is tempting because static scheduling is often criticised for oversimplifying, but data volume is not the axis of advantage here.

It completely removes the need for expert judgment.

Why it fails: Monte Carlo quantifies schedule risk by sampling duration distributions, but those distributions and correlations still come from expert judgement, so the need remains. It is valuable for probabilistic completion dates and confidence levels; it does not replace the estimators who supply the input ranges.

Risk events are modeled with triangular distributions.

Why it fails: Triangular distributions can model either risk events or duration uncertainty, so the distribution shape does not separate them. It is tempting because triangular estimates are common in quantitative schedule analysis, but the real distinction is discrete probabilistic events versus continuous variability in activity durations.

Risk events are always more expensive than uncertainty.

Why it fails: Cost magnitude does not define the distinction; a low-cost risk event and a high-cost uncertainty can coexist. It is tempting because risk events often carry financial impact, but the actual difference is that risk events are discrete probabilistic occurrences while uncertainty is continuous variability in activity duration.

Uncertainty can be mitigated, but risk events cannot.

Why it fails: Both risk events and duration uncertainty can be addressed through response planning, so mitigation capability does not separate them. It is tempting because risk events are often framed as threats, but the genuine distinction is discrete probabilistic occurrences versus continuous variability in activity durations.

Increase the task duration by the total estimated impact.

Why it fails: Adding total estimated impact to duration converts a probabilistic count of events into one deterministic delay, removing the variability simulation exists to capture. It is tempting because padding estimates for known downtime is common, and this would be correct when the aggregate impact is genuinely fixed and known in advance.

Assign a fixed date for each occurrence.

Why it fails: Fixed dates hard-code each occurrence, so the simulation cannot vary breakdown frequency or timing across iterations. It is tempting because scheduling known maintenance windows as calendar milestones is normal practise, and this would be correct when occurrences are contractually or operationally predetermined rather than probabilistic.

Delete the task and recreate it as multiple tasks.

Why it fails: Deleting and duplicating the task models a fixed number of discrete occurrences, so it cannot represent a random count of breakdowns within the simulation. It is tempting because splitting work into separate activities is standard scheduling practise, and this would be correct when each occurrence is genuinely independent with its own deterministic timing.