What Is a Monte Carlo Simulation? (Explained With Dice)
You have probably seen the term attached to weather forecasts, project deadlines, or the odds of your favourite team making the playoffs. Monte Carlo simulation sounds like it requires a mathematics degree. It doesn't — the core idea is something you already understand instinctively, and it fits in one sentence: when a problem is too messy to solve, try it thousands of times and count what happens.
A Monte Carlo simulation answers questions with uncertain inputs by running the same scenario thousands of times, each time picking random values from realistic ranges, then looking at the spread of results. Instead of one prediction that is almost certainly wrong, you get a distribution: what's likely, what's possible, and how likely each outcome is.
The Dice Analogy: Rolling Beats Calculating
Suppose you want to know the chance of rolling a total of 7 with two dice. You could work it out properly: list all 36 combinations, count the six that sum to 7, conclude 6/36 = 16.7%. That's clean, exact, and takes a minute.
Or you could just roll two dice 10,000 times and tally the results. You'd find roughly 1,670 of them came up 7, and you'd get the same answer without doing any mathematics at all.
For two dice, the calculation is obviously the smarter route. You can check it in seconds with a dice probability calculator and be done.
But now make the question harder. Five dice, where you re-roll any 1s once, and if the total goes above 20 you subtract the lowest die. The exact calculation becomes a genuinely difficult piece of combinatorics. The rolling approach doesn't get any harder at all — it's still just "do it a lot and count."
That asymmetry is the entire point of Monte Carlo. As problems get more tangled, exact mathematics gets exponentially harder while random trials stay exactly as easy. Past a certain level of messiness, rolling stops being the lazy option and becomes the only practical one.
Why Is It Called Monte Carlo?
The name comes from a casino, and the method comes from a card game.
In 1946 the mathematician Stanislaw Ulam was recovering from an illness and passing the time playing solitaire. He got curious about a simple question: what are the odds of winning a given hand? He tried to work it out with combinatorics, got nowhere useful, and then had the thought that founded a whole field — it would be far easier to play a hundred hands and count the wins.
Ulam was working at Los Alamos on the Manhattan Project at the time, where the pressing problem was neutron behaviour: particles bouncing through material along paths far too chaotic to solve with equations. The solitaire insight applied directly. Together with John von Neumann he began simulating thousands of random neutron paths on some of the first electronic computers.
The work was classified and needed a code name. Their colleague Nicholas Metropolis suggested "Monte Carlo" — after the casino in Monaco where Ulam's uncle would borrow money from relatives to gamble. The name stuck, which is why a serious statistical technique used in nuclear physics and aerospace engineering is named after a relative's gambling habit.
How Monte Carlo Simulation Actually Works
Every Monte Carlo simulation, no matter how sophisticated, is the same three steps.
Step 1 — Replace each guess with a range
Normally when you estimate something uncertain, you commit to a single number. A task "will take 5 days." Monte Carlo asks you to be honest instead: it will take somewhere between 3 and 10 days, most likely 5.
That range is the crucial input, and it's where the method gets its honesty. You are no longer pretending to know something you don't — you're stating what you actually believe, including how wrong you might be.
Step 2 — Run the scenario thousands of times, rolling dice for every unknown
Now the computer plays out the whole scenario once, picking a random value from each range as it goes. Task one lands on 4 days, task two on 9, task three on 13. Total: some number. Write it down.
Then it does it again, with fresh random draws. And again. Ten thousand times. Each run is one plausible version of how things could unfold — some optimistic, some disastrous, most somewhere in between.
Step 3 — Look at the shape of all those results
You now have ten thousand possible outcomes instead of one prediction. Sort them, and questions that were previously unanswerable become straightforward counting exercises:
- What's the most common result?
- What's the realistic worst case?
- What are the odds we finish by a specific date?
- How much buffer do we need to be 90% confident?
That last question is the one Monte Carlo answers better than any other method, and it's why planners use it.
A Worked Example: How Long Will This Project Really Take?
A small team is redesigning a website. Four tasks, done one after another. Nobody knows exactly how long any of them will take, but everyone has a decent sense of the range.
| Task | Best case | Most likely | Worst case |
|---|---|---|---|
| Research & wireframes | 3 | 5 | 10 |
| Visual design | 4 | 6 | 12 |
| Build | 8 | 12 | 25 |
| Testing & fixes | 2 | 4 | 12 |
| Sum of "most likely" | 17 | 27 | 59 |
The obvious move is to add up the middle column. Five plus six plus twelve plus four equals 27 days. That's the number that goes in the plan, gets promised to the client, and ends up in a calendar invite.
It is also almost certainly wrong. Let's find out how wrong.
Run the simulation
Each trial rolls a random duration for all four tasks and adds them up. One bar = one range of total durations. Add trials and watch a shape emerge from pure randomness.
Real simulation, not an animation: every bar is generated by actual random sampling in your browser, so your numbers will differ slightly from the ones quoted in the article — which is itself a useful thing to notice.
Why Does Adding Up the Estimates Give the Wrong Answer?
Run the simulation to a few thousand trials and the result is uncomfortable. The average project takes about 34 days, not 27. Only around 5% of simulated projects finish within the planned 27 days. The plan wasn't slightly optimistic — it was a one-in-twenty outcome presented as the expectation.
The reason is visible in the histogram's shape. It isn't symmetric. It has a wall on the left and a long tail trailing off to the right, and that asymmetry comes straight from the estimates themselves.
Look at the Build task: best case 8 days, most likely 12, worst case 25. It can finish 4 days early. It can finish 13 days late. Every task in the table has that same lopsided shape, because that is how work genuinely behaves — there's a limit to how fast something can possibly go, and no limit at all on how badly it can go wrong.
So the "most likely" value is not the middle of the range. It sits well below the average outcome. Add four of those together and you get a number that is systematically, predictably too low.
This is the most valuable thing Monte Carlo does for ordinary planning, and it has nothing to do with sophisticated mathematics. It just refuses to let you quietly discard the bad half of every range.
Reading the Results: What P90 Means
Once you have the distribution, you stop giving deadlines as single numbers and start giving them as confidence levels. From the simulation above:
| Promise | Chance of hitting it | What it means |
|---|---|---|
| 27 days | 5% | The original plan. A near-fantasy. |
| 34 days | 50% | A coin flip. Fine internally, risky as a promise. |
| 38 days | 80% | A reasonable commitment with real buffer. |
| 41 days | 90% | The "P90" figure. Safe enough to sign. |
Notice that going from 50% confidence to 90% confidence costs only 7 extra days. That's a bargain most teams would take instantly if anyone framed it that way — and nobody can frame it that way without a distribution to look at.
These percentile figures are just sorted positions in a list of results, so you can pull the same numbers out of any dataset with a statistics and percentile calculator. To run a full simulation on your own tasks or cost estimates rather than this example, use a Monte Carlo risk simulator.
How Many Simulations Do You Actually Need?
Fewer than people expect. Run the widget in steps and you can watch it happen: at 10 trials the histogram is noise, at 100 the shape is recognisable, at 1,000 it's stable, and by 10,000 the answer barely moves no matter how many more you add.
For most practical work, 10,000 trials is plenty, and it takes a fraction of a second. Accuracy improves with the square root of the number of trials, which means going from 10,000 to 1,000,000 — a hundred times the work — only makes the answer ten times more precise. Long before that point, the limiting factor stops being the number of trials and becomes the quality of your input ranges.
Where Monte Carlo Simulation Is Used
Once you know the pattern, you start seeing it everywhere. Any field with uncertainty it can describe but not solve tends to end up here:
- Engineering and manufacturing — tolerance stacking, where thousands of parts each vary slightly and you need to know how often the assembly fails to fit.
- Weather and climate — forecasts are run many times with slightly different starting conditions. The "60% chance of rain" on your phone is a count of how many of those runs produced rain.
- Physics and biology — the original application, still going: particle transport, molecular behaviour, epidemic spread. It is also how physicists judge whether a bump in the data is real, which is the arithmetic behind the LHC’s 4-sigma anomaly.
- Video games — both in graphics, where realistic lighting is computed by tracing enormous numbers of random light paths, and in game AI, where a program evaluates a move by playing thousands of random games from that position.
- Finance and insurance — the best-known use, and the reason the term escaped into general vocabulary. Running a project’s cash flows this way turns a single NPV figure into a range with odds attached.
- Project planning — the example above, used routinely for large construction and software schedules.
What Monte Carlo Can't Do
One honest limitation, because it gets oversold.
A Monte Carlo simulation produces confident-looking output — smooth curves, precise percentages, a number to two decimal places. But every one of those digits rests entirely on the ranges you typed in. If your "worst case" was optimistic, the simulation will faithfully reproduce your optimism at high resolution and hand it back to you looking like evidence.
It also assumes you told it how the variables relate. In the project example, each task was drawn independently — but in reality, the thing that delays the design phase (a difficult client, a sick teammate) is often the same thing that delays the build. Real risks are correlated, and a simulation that ignores that will understate how bad the bad cases get.
Monte Carlo doesn't create knowledge. It takes what you already believe about uncertainty and works out the consequences of those beliefs far more reliably than your intuition can. That's a genuinely powerful thing — as long as you remember which part is the machine's contribution and which part is yours.
The Takeaway
Monte Carlo simulation is the formal version of an instinct you already have: when something is too complicated to reason through, try it a lot of times and see what usually happens. A man playing solitaire in a hospital bed in 1946 turned that instinct into a method, and it now sits underneath weather forecasts, film rendering, drug trials and construction schedules.
The practical lesson is smaller and more useful than the history. Whenever you catch yourself adding up a column of best guesses and treating the total as a plan, that total is not the likely outcome — it's close to the best realistic case. The honest answer isn't a number at all. It's a range, and the odds attached to it.
Run it on your own numbers
Enter best case, most likely and worst case for each of your variables and get the full distribution back, with percentiles. Free, no sign-up, runs in your browser.
The worked example was checked against an independent 200,000-trial run: mean 34.3 days, P50 34.1, P90 40.8, and 5.2% of projects finishing within the planned 27 days. Educational content on the method, not project-management advice.
Did this help? You can buy me a coffee.