Monte Carlo Simulation

Turning “We Don’t Know” into a Decision

A behavioral health transformation program submits a 3-year HRSA grant budget totaling $3.6 million. The budget contains 12 line items — personnel, IT infrastructure, travel, training, subcontracts, indirect costs — each estimated as a single number. The program officer reviews it, the finance team signs off, and the organization commits to delivering defined outcomes within that envelope. Eighteen months later, the program is $420,000 over budget, driven by two line items that nobody flagged: IT vendor costs came in 35% above estimate, and travel-nurse rates spiked during a regional shortage. The budget was not wrong in its averages. It was wrong in its certainty. Every line item was a point estimate where a probability distribution was required.

Monte Carlo simulation is the method for replacing that false certainty with calibrated uncertainty. It does not predict the future. It maps the range of plausible futures, assigns probabilities, and identifies which inputs drive the most risk — so that operators can make decisions with eyes open rather than plans based on single-number fantasies.


What Monte Carlo Simulation Is (and Is Not)

Monte Carlo simulation is a computational technique that quantifies uncertainty by repeatedly sampling random values from input distributions, computing the output for each sample, and analyzing the resulting distribution of outputs. The name comes from the Monte Carlo Casino in Monaco — a reference chosen by Stanislaw Ulam and John von Neumann while developing the method at Los Alamos National Laboratory in the 1940s for neutron diffusion calculations in nuclear weapons research. Nicholas Metropolis, who implemented the computational approach on the MANIAC computer, coined the name. The method was declassified and published by Metropolis and Ulam in 1949.

The core logic is simple:

  1. Define input distributions. For each uncertain input, specify not a single value but a probability distribution — triangular, normal, lognormal, beta, or empirical — based on historical data, expert judgment, or both.
  2. Sample. Draw one random value from each input distribution.
  3. Compute. Run those sampled values through whatever calculation produces the output of interest — total cost, project duration, staffing shortfall, revenue projection.
  4. Repeat. Do this thousands of times (typically 5,000 to 50,000 iterations).
  5. Analyze. The collection of output values forms a distribution. Extract the mean, percentiles (P10, P50, P90), probability of exceeding a threshold, and sensitivity measures showing which inputs drive the most output variation.

What Monte Carlo is not: it is not a model of system dynamics. It does not simulate entities flowing through a process over time — that is discrete-event simulation (DES), covered in 06-discrete-event-simulation.md. Monte Carlo is a method for propagating uncertainty through any static calculation. The calculation itself can be as simple as a budget spreadsheet or as complex as a financial model with interdependent cost drivers. Monte Carlo’s job is to answer: given that these inputs are uncertain, what is the range of possible outputs and how likely is each?

David Vose, in Risk Analysis: A Quantitative Guide (now in its third edition), provides the canonical practitioner treatment: Monte Carlo simulation is the “universal method for propagating uncertainty through models of arbitrary complexity.” It requires no closed-form solution. It scales to any number of inputs. It handles nonlinear relationships, conditional logic, and correlated inputs — all of which break analytical uncertainty propagation methods.


The Flaw of Averages: Why This Matters

Sam Savage formalized the concept in The Flaw of Averages (2009): plans based on average values of uncertain inputs produce results that are wrong on average. The error is systematic and directional — it almost always underestimates cost, duration, and risk, because the functions governing real systems are typically convex (per Jensen’s inequality, as detailed in 01-deterministic-vs-stochastic.md).

Monte Carlo is the operational remedy for the flaw of averages. It does not require the operator to understand Jensen’s inequality or convexity. It requires only that they specify ranges and shapes for uncertain inputs instead of single numbers. The simulation does the rest — revealing the output distribution that the point estimate concealed.

The transformation from point estimate to distribution is not an academic refinement. It changes the nature of the decision:

  • Point estimate: “The project will cost $3.6 million.” → Go/no-go based on a single number.
  • Monte Carlo output: “There is a 50% chance the project costs between $3.2M and $3.9M. There is a 70% chance it stays under $4.1M. There is a 10% chance it exceeds $4.5M. The two largest drivers of overrun risk are IT vendor costs and travel-nurse rates.” → Go/no-go based on risk tolerance, with specific risk mitigation targets identified.

The second framing enables decisions the first cannot support: setting contingency reserves at a defensible level, negotiating fixed-price subcontracts on the highest-risk line items, building contract escalation clauses tied to specific cost drivers, and monitoring the inputs that matter most during execution.


Healthcare Example 1: Grant Budget Under Uncertainty

A critical access hospital in rural Montana receives a 3-year, $3.6 million HRSA transformation grant. The budget has 12 line items. The finance director builds a Monte Carlo model by replacing each point estimate with a distribution:

Line ItemPoint EstimateDistributionRationale
BH clinician salary (3 yr)$720KNormal (720K, SD 36K)Salary bands known; 5% CV from market variation
IT vendor (telehealth)$480KLognormal (480K, SD 120K)Vendor bids ranged $380K–$720K; right-skewed
Travel-nurse coverage$240KLognormal (240K, SD 96K)Rates volatile; 40% CV from recent 3-year history
Training & TA$180KTriangular (140K, 180K, 260K)Expert estimate; upside if curriculum reused
Indirect costs$396KFixed percentage of directNegotiated rate; deterministic
Other 7 line itemsVariousTriangular distributions±15% to ±25% based on historical variance

The simulation runs 10,000 iterations. Results:

  • P50 (median) total cost: $3.65M — close to the point estimate, as expected.
  • P75: $3.92M — a 25% chance of exceeding this.
  • P90: $4.18M — a 10% chance of exceeding this.
  • Probability of exceeding the $3.6M budget: 55%.

The point estimate suggested the budget was adequate. The simulation reveals a coin flip. More importantly, sensitivity analysis (computed by measuring the rank correlation between each input and the total cost output) shows that two inputs drive 68% of the output variance: IT vendor costs (42%) and travel-nurse rates (26%). The other 10 line items combined account for 32% of the risk.

This changes the management strategy entirely. Instead of monitoring all 12 line items with equal attention, the program director:

  • Negotiates a fixed-price contract with the IT vendor, capping exposure at $540K (the P75 of that input).
  • Establishes a travel-nurse rate corridor with the staffing agency, with an escalation clause and a not-to-exceed ceiling.
  • Requests a 12% budget contingency ($432K) from HRSA, justified by the Monte Carlo output showing the probability distribution of overrun.
  • Monitors IT and travel-nurse costs monthly as leading indicators, rather than waiting for the quarterly budget-to-actual variance report.

By year 2, the program is tracking at P40 — below the median projection — because the fixed-price IT contract eliminated the largest source of variance. Without the simulation, the finance director would have had no basis for prioritizing these two line items over the other ten. The point estimate treated all line items as equally certain. They were not.


Healthcare Example 2: Workforce Capacity Under Uncertainty

A 12-provider primary care network serving three rural counties models its probability of falling below safe staffing levels over the next 18 months. The inputs:

  • Annual turnover rate: Beta distribution (mean 18%, SD 5%) — based on 5 years of network data.
  • Recruitment pipeline fill time: Lognormal (mean 4.5 months, SD 1.8 months) — right-skewed because credentialing delays create a long tail.
  • Seasonal demand variation: Normal monthly multiplier (mean 1.0, SD 0.08) — winter months average 1.12, summer 0.91.
  • Retirement risk: Two providers over 60; 30% probability each retires within 18 months.

The simulation runs 10,000 scenarios. In each iteration, it samples turnover events (binomial draws for each provider each quarter), retirement decisions, recruitment durations, and monthly demand. The output metric: number of months where effective provider capacity falls below 90% of demand (the threshold below which the network begins diverting patients to the ED and canceling same-day appointments).

Results:

  • Probability of at least one month below safe staffing: 72%.
  • Probability of three or more months below safe staffing: 34%.
  • Primary driver: The correlation between a retirement event and recruitment pipeline duration. When a senior provider retires, the replacement takes longer to credential (specialist panels, hospital privileges), creating a gap that overlaps with winter demand peaks.

The network administrator uses this to justify pre-emptive recruitment — beginning the pipeline for a replacement provider 6 months before anticipated need, rather than after a vacancy occurs. The cost of carrying an overlapping provider for 2-3 months ($80K-$120K) is small relative to the cost of months below safe staffing: diverted patients, lost revenue, remaining provider burnout, and potential safety events.


Common Mistakes

Too few iterations. Running 100 or 500 iterations produces a noisy output distribution — the percentiles jump around between runs. The law of large numbers requires sufficient samples for the output distribution to stabilize. For most healthcare planning models with 10-20 uncertain inputs, 5,000 iterations is the practical minimum; 10,000 provides stable percentiles through P95. Running one million iterations is wasteful — the marginal information is negligible past 10,000 for typical models.

Correlated inputs treated as independent. If IT vendor costs and training costs are both driven by the same labor market, sampling them independently understates the probability of both being high simultaneously. Ignoring positive correlations between inputs understates tail risk — the probability of extreme outcomes. Vose’s Risk Analysis devotes an entire chapter to correlation modeling in Monte Carlo; the minimum viable approach is to identify the 2-3 strongest input correlations and model them explicitly using a correlation matrix (typically via copulas or the Iman-Conover method).

Garbage distributions. Using a uniform distribution (equal probability across the range) when historical data supports a lognormal or triangular distribution wastes information and distorts the output. Uniform distributions are appropriate when you genuinely have no information about shape — but that is rarer than practitioners assume. Three data points are enough to fit a triangular distribution. Twenty data points support a lognormal. Expert elicitation using Hubbard’s calibrated estimation method (How to Measure Anything, 2010) can produce useful distributions even without historical data.

Confusing precision with accuracy. A Monte Carlo output showing P90 = $4,183,247 is precise to the dollar but accurate only to the degree that the input distributions reflect reality. If the lognormal on IT vendor costs was fitted to three bid quotes rather than a market database, the output precision is illusory. Report Monte Carlo results in round numbers and focus on the shape and drivers, not the decimal places.

No sensitivity analysis. Running the simulation without analyzing which inputs drive the output variance misses half the value. The point of Monte Carlo is not just the output distribution — it is the identification of which uncertainties matter and which do not. A tornado diagram (inputs ranked by their contribution to output variance) should accompany every Monte Carlo result.


Warning Signs of Misapplication

  1. The output distribution is presented but no input was changed. Someone ran a Monte Carlo but used the same point estimate for every input with a ±5% uniform band around each. This is theater, not analysis.

  2. All inputs have the same distribution shape. Real uncertainties have different shapes. Costs are often right-skewed (lognormal). Durations are right-skewed. Demand counts may be Poisson. Proportions are beta-distributed. If every input is triangular with symmetric bounds, the analyst has not thought about the data-generating process.

  3. The model has no conditional logic. Real budgets have “if-then” relationships: if the IT vendor exceeds $500K, the organization must issue a new RFP, adding 3 months of delay. If Monte Carlo treats this as a continuous distribution ignoring the threshold trigger, it understates the impact of the tail scenario.

  4. Results are reported as a single number. “The Monte Carlo says the project will cost $3.8M.” This defeats the entire purpose. The output is a distribution. Report it as a distribution: median, P75, P90, and the probability of exceeding a decision-relevant threshold.


Integration Hooks

Module 1 (Deterministic vs. Stochastic Systems): Monte Carlo is the computational implementation of the stochastic worldview introduced in 01-deterministic-vs-stochastic.md. That page establishes that planning for averages in stochastic systems produces systematically wrong answers — the Flaw of Averages, grounded in Jensen’s inequality. Monte Carlo is how an operator operationalizes that insight without needing to derive the analytical correction. You do not need to know whether your cost function is convex. You sample, compute, repeat, and the output distribution reveals the truth that the point estimate concealed. Every warning sign from Module 1 — staffing to average demand, budgeting to average cost, reporting only means — has a Monte Carlo remedy.

Public Finance Module 6 (Financial Controls and Scenario Planning): Grant budgets are the highest-value Monte Carlo application in healthcare transformation. Every HRSA, SAMHSA, and state-funded program builds a multi-year budget from uncertain inputs: salary projections, vendor costs, travel rates, indirect cost negotiations, patient volume assumptions. Monte Carlo on those budgets produces the probability of overrun by year, by line item, and by cost driver — exactly the information a program director needs to set contingency levels, negotiate contracts, and prioritize financial monitoring. The scenario planning frameworks in Public Finance M6 should treat Monte Carlo budget simulation as a required analytical step, not an optional refinement.


Product Owner Lens

What is the operational problem? Healthcare organizations commit to multi-year budgets, capacity plans, and staffing projections using single-number estimates for inputs that are inherently uncertain. When reality deviates — and it always does — they lack the analytical basis to distinguish expected variation from genuine plan failure, and they cannot prioritize which risks to mitigate.

What mechanism explains it? Uncertain inputs propagated through calculations produce uncertain outputs. The output uncertainty is a mathematical function of input uncertainty, model structure, and input correlations. Point estimates collapse this distribution to a single number, destroying the risk information that operators need.

What intervention levers exist? Replace point estimates with distributions for the 5-10 most uncertain inputs. Run Monte Carlo simulation to generate the output distribution. Use sensitivity analysis to identify the 2-3 inputs that drive the most output variance. Concentrate risk mitigation on those inputs: fixed-price contracts, hedging, pre-emptive recruitment, contingency reserves sized to a defensible percentile.

What should software surface? A budget or capacity planning tool that accepts range inputs (optimistic/likely/pessimistic or distribution parameters), runs Monte Carlo automatically, and displays: (a) the output distribution as a histogram with marked percentiles, (b) the probability of exceeding a user-defined threshold (budget ceiling, staffing floor), (c) a tornado diagram showing which inputs drive the most variance, and (d) trend tracking — as actuals replace estimates during execution, the simulation narrows and the probability projections update in real time.

Tools like Palisade’s @RISK (an Excel add-in, now part of Lumivero) and Oracle’s Crystal Ball have provided this capability for decades. The product opportunity is embedding Monte Carlo natively into grant management and capacity planning workflows — not as a standalone analysis tool that requires a specialist, but as a default mode of budgeting where every uncertain input has a range and every total has a distribution.

What metric reveals degradation earliest? The probability of exceeding budget at completion, updated monthly as actuals replace forecasted distributions. In a well-managed program, this probability should decrease over time as uncertainty resolves. If the probability of overrun is increasing — if each month’s actuals are pushing the remaining distribution upward — the program is on a trajectory toward failure, even if the current spend is on plan. This is the Monte Carlo equivalent of float erosion in critical path analysis: a leading indicator that arrives before the trailing metric (actual vs. budget variance) triggers an alarm.