why independent estimates lie to you

a monte carlo schedule simulation is, at heart, a very fast way to roll dice. each activity gets a duration drawn from its three-point estimate, the dates fall out, and you do it thousands of times. the usual default is to roll every activity's dice separately. that's called independence, and it's quietly generous.

two tasks, one cause

take two activities that each have a 1-in-5 chance of running long. if they're independent, the chance that both run long is 1 in 25. now suppose the same small team owns both, or both wait on the same vendor. when one runs long, that tells you a lot about the other, and the chance of both running long climbs somewhere between 1 in 25 and 1 in 5, depending on how tightly they're tied.

independence picks the bottom of that range and doesn't tell you it did.

what it does to the whole plan

add up lots of independent durations and the highs and lows partly cancel: a long task here, a short one there. the total clusters tightly around its average. add up durations that move together and they don't cancel, so the total spreads out. the average finish barely changes. the long end does.

here's the same small example we use in a p50 date is not a commitment: six activities in a row, each estimated at 3, 5 and 10 workdays. treated as independent, the forecast puts the p50 near 33 workdays and the p95 near 38. now tick "shared person" and "shared uncertainty" on every pair, as if one team owned all six and all six leaned on the same unknown. the p50 stays near 33. the p95 moves out to about 44.

same estimates, about six more days at the end of the forecast, which is the end where you promise things.

why activities run long together

there are many reasons work runs long together, but four cover most of the ground. they're the four things jollygig asks about.

• a shared person. the same person or small team owns both activities. if their time gets pulled elsewhere, both stretch.
• a shared uncertainty. both depend on the same unknown: a vendor, an unproven library, a ruling that hasn't landed. one answer decides both.
• domain proximity. they're in the same technical area. if the first was harder than expected, you've learned something about the second.
• sequential dependency. the second estimate was anchored on the first. if the first stretches, your estimate of the second was probably too small as well.

how jollygig asks

asking for a correlation coefficient doesn't work. nobody knows what a 0.4 means for their project. so you pick two activities and tick what's true of them. each tick adds to how tightly the pair is tied, with the shared person and the shared unknown counting for more than the shared area and the anchoring, and no pair ever being tied completely. the forecast then draws their durations together instead of separately, so when one is long the other is more likely to be. the maths has a name, and you don't need it.

what to do with it

you don't have to tick every pair. start with the ones you'd bet on: the team that sits behind three activities on the main path, the vendor everything waits for. then look at the p95 before and after. if it hardly moves, your estimates were more independent than you feared. if it moves a lot, that's the number to show whoever is asking for a date.

if jollygig says it softened a couple of your hints so they fit together, that's because ties like "a is like b, b is like c, a is unlike c" can't all be true at once. look for the odd one out.

a note on people

sharing a person is a fact about the plan, not about the person. we ask because capacity is one of the most common shared causes of delay, not because anyone is the problem. nothing here scores the people involved, and the forecast never names them.