The Optimism Trap: Predicting Deadlines with Monte Carlo Simulations | Sanjana

The Optimism Trap: Why Single-Number Deadlines Fail

[0:00]Hi, I'm Sanjana, a project manager at Humanitarian's AI. And this video is about the one thing every project comes down to, the deadline. We'll look at a simple but powerful idea called Monte Carlo schedule risk. Don't let the name scare you. It just means letting a computer play out your project thousands of times, so you can see not only when you hope it finishes, but when it realistically will. Here's the trouble with most plans. We give each task our best guess number of days, add them up, and call that the deadline. Design five days, back end eight, test four, release two. 19 days. Done. But a

The 4-Step Solution: Transitioning from Guesses to Ranges

[0:37]Best guess isn't a promise. Some tasks finish a little early, and others blow up by a week. And here's the catch. A task can only save you a day or two, but it can cost you many. So, when you add up all those lopsided guesses, the real finish almost always lands later than the plan. That single number isn't just rough. It's quietly too optimistic nearly every time. So, instead of one guess, we use a method with four simple steps. Step one,

Coding with Claude: Building the 10,000-Run Simulation

[1:05]For each task give three numbers instead of one. A best case, a most likely case, and a worst case. That's the task's range. Step two, let the computer roll the dice once picking a random length for every task inside its range and add them up. That's one possible version of your whole project. Step three, do that 10,000 times. Now you don't have one guess, you have 10,000 outcomes. Step four, instead of the average, the date you'll hit 80% of the time. That's

Visualizing the Risk: Understanding P50, P80, and Safety Buffers

[1:35]The date you can actually promise. Let's build it with Claude. The instructions are short and clear. Take my list of tasks, and for each one use its three numbers, best, likely, and worst. Pick a random length for every task, add them up for one run, then repeat that 10,000 times, and tell me the results. Because I'm being specific about exactly what to do, the code Claude writes back is code I can read and check myself. Here's what it wrote. You don't need to read every line, just the shape of it.

The Merge Bottleneck: Why Parallel Paths Increase Delay Risk

[2:05]Up top is the list of tasks, each with its three numbers. The sample function picks one random length inside a task's range. It leans toward the likely value, but it leaves room for that long, painful worst case. One trial does that for every task and adds them up, giving one imagined run of the whole project. Then we run it 10,000 times and notice it also prints the old plan number, the simple sum of the best guesses, right next to the results, so we can see just how far off that single

Your Turn: Identifying and Estimating Your Riskiest Tasks

[2:36]Guess really is. Now, let's run it. Watch the 10,000 outcomes stack up into a shape. Each bar is how often the project finished on that day. Remember our plan said 19 days. Look where 19 lands, right at the hopeful, early edge. The middle of the pile, a true coin flip, is already later. And the date we'd actually commit to, the P80, is further out still. That gap between the plan and the P80 isn't extra padding. It's the risk that was hiding inside the single number the whole time, but our first version quietly cheated. It added the tasks up as if they happened one after another in a single line. Real projects don't work that way. Some tasks run at the same time. Here, back-end and front-end both start after design and run together, and

Testing can't begin until both are finished. And that's the key idea. When two paths join back up, the project has to wait for the slower one. So, let's fix it. We'll tell Claude which task depends on which, so each task only starts once everything before it is done. The whole fix is really just one line. Each task now starts at the latest finish time of the tasks before it. That little word max is the important part. It's the moment where paths join. You can't move forward until every path leading in is finished. It's also why adding more people to parallel work doesn't always help. Your finish is decided by the slowest path, and the more paths running at once, the better the chance that at least one runs late. Run it again. The new

Shape sits a little to the right of the old one, and it spreads out wider, exactly what waiting for the slowest path predicts. The date you can promise moves out by a few days, and that's not bad news. It's the truth showing up early while you still have time to plan around it. Now you can give a real answer, an 80% chance we're done by this day, instead of a single number everyone secretly knows will miss. So here's what to remember, and you can use it on any project. One number hides the risk. Instead, give each task a range, let the computer run it thousands of times, and read three numbers. P50 is a coin flip. P80 is the date you can safely commit to. And P90 is a date you'll almost never miss.

The gap between your old single number plan and the P80 is your safety buffer. And now, for the first time, you can actually see it, measure it, and defend it. Now it's your turn. Think of a project you're not quite sure about. Write down its tasks, give each one three honest guesses, best, likely, and worst, and note what has to happen before what. Then paste this prompt into Claude. It'll run the simulation, hand you back a date you can actually promise, and the most useful part, tell you which task's uncertainty is causing the most trouble, so you know exactly where a better estimate would help the most. Monte Carlo schedule risk with San Jana Rao for Humanitarian's AI. Give your plan a range, and let the simulation tell you the truth. Thanks for watching.