Deadline Risk Calculator

What this tool does

CM8-341 answers the question every plan avoids: what is the actual chance of hitting this date? You give each task three estimates instead of one, group tasks into parallel streams, and the tool reports the probability of finishing on time, the date you could commit to with the confidence you actually want, and which tasks are contributing the risk.

Everything runs inside this single file — no account, no upload, no network request — which matters when the output is a candid view of whether a committed date is achievable.

The three-point estimate

Single-point estimates are the root of the problem. Asked how long something will take, people answer with the duration if it goes well, and a plan built by adding those together has roughly a coin-toss chance of holding — before anything unusual happens at all.

• Optimistic — a genuinely good run, where nothing goes wrong. Not the shortest imaginable time.
• Most likely — the single duration you would bet on. This is the number people give when asked for "an estimate".
• Pessimistic — a bad outcome you have actually seen. The key person off sick, the part arriving wrong, the decision taking three weeks.

The familiarity column is a cross-check rather than an input. A task marked new to us with a narrow range has not been estimated; it has been asserted, and those rows cause most overruns. On genuinely new work, a pessimistic figure less than about twice the optimistic one is almost always understated.

Why PERT rather than an average

The expected duration is (optimistic + 4 × likely + pessimistic) ÷ 6. The likely value carries four times the weight of either extreme, which keeps the mean near what you actually expect while still letting a long tail pull it out.

The spread is (pessimistic − optimistic) ÷ 6, on the reasoning that the range between best and worst covers about six standard deviations. It is a rough rule, and its roughness is one reason not to read the second decimal place of any probability here.

Notice what the mean does on the sample's migration task: five to sixty days with a likely of twenty gives an expected duration of about twenty-five days, not twenty. That five-day difference is the tool doing its job — asymmetric risk moves the expected date even when the likely case does not change.

Streams and parallel work

Tasks in the same stream run one after another; different streams run at the same time. This is a deliberate simplification of a full critical-path network, and it is worth being explicit about.

A proper network lets any task depend on any other. Streams handle the common case — a few parallel workstreams, each internally sequential — with one field instead of a dependency graph, and for most plans they give the same answer. Where they will not is a plan with genuine cross-stream dependencies, and the practical fix is to put anything that truly cannot start until something else finishes into the same stream as it, in order.

Because streams run in parallel, the longest one sets the date. That is why the stream table is sorted by duration and why the driving stream appears in the headline tiles: work on the others buys you nothing.

How the risk is combined

Within a stream, durations add and variances add — so the spread grows as the square root of the sum, not as the sum. Ten tasks each uncertain by two days do not give a plan uncertain by twenty days; they give one uncertain by about six. Some tasks run late and others run early, and they partly cancel.

The practical consequence is important: one very uncertain task can dominate a plan full of well-understood ones, because the squares are what add. Breaking that single task into pieces you understand is almost always the cheapest risk reduction available, and it is why the uncertainty chart is sorted the way it is.

Across streams, the tool multiplies the individual probabilities. That treats the streams as independent, which flatters the plan — see the warning below.

Reading the S-curve

The curve shows the chance of being finished by each date. Two features matter.

It is flat at the bottom: dates well before the expected finish have almost no chance, however much anybody wants them. And it is flat at the top: the last few per cent of confidence cost a great deal of time. The steep middle is where the negotiation should happen, because that is where a week of buffer buys the most confidence.

The single most useful conversation this chart supports is showing somebody the probability attached to the date they have already announced.

Buffers, and where to put them

The tool reports the buffer needed to reach your target confidence, and it should be held as a single buffer at the end of the driving stream — not spread across the tasks.

Padding every task individually is worse in two ways. It is mathematically wasteful, because it adds the padding rather than combining it as a square root — the same protection costs far more time. And it does not survive contact with people: a task with a comfortable estimate expands to fill it, so the protection is spent quietly, task by task, and is gone before the risk arrives. One visible buffer at the end can be managed, reported and defended.

Why the answer is more optimistic than reality

Two things make every probability in this tool too high, and both should be said plainly.

The pessimistic estimate is not pessimistic. Asked for a worst case, people describe a bad version of the normal case. They do not describe the supplier going into administration, the specification changing in month three, or the two key people leaving. The stretch the pessimistic estimates setting exists for exactly this: set it to 50 or 100 and see how far the answer moves. If a 50% stretch turns a comfortable plan into a marginal one, the plan was never comfortable.

Delays are correlated, and the model assumes they are not. Multiplying stream probabilities assumes each stream fails independently, when in practice the same absent expert, the same late decision and the same scope change hit several at once. Real projects therefore have far fatter tails than a normal approximation suggests. Treat a computed 80% as "likely, if nothing systemic goes wrong" rather than as four times in five.

The formulas

FAQ

The probability is much lower than I expected. That is usually the tool working. A plan built from likely estimates with no buffer sits near 50% by construction, and any deadline earlier than the expected finish is below that.

Should progress really shorten the spread? Yes, and it is one of the few genuinely encouraging things in project statistics: work that is done carries no remaining uncertainty. Be sceptical of reported progress above eighty per cent, though — the last fifth routinely takes as long as the first four.

What if a task has no uncertainty at all? A fixed date — a shutdown week, a regulatory window — is a constraint rather than an estimate. Give it a token spread and note it, or model it as the deadline itself.

Can I use this for a fixed-scope, fixed-date project? You can use it to find out that the combination is not available, which is worth knowing early. If the probability is unacceptable and the date cannot move, the only remaining variable is scope — which is what the cut row in the sample data illustrates.

Why not a Monte Carlo simulation? Because it would not change the conclusion. The uncertainty in the three estimates dwarfs the difference between a normal approximation and a simulation, and a simulation would make the output look more authoritative than the inputs deserve.

Saving your work

Tasks, settings and the report header are written to this browser's local storage as you type. Treat Export .json as the real save, which Import .json restores anywhere. Export CSV gives you the estimates for spreadsheet work. Reset asks twice, then erases everything. There is no undo.

Accuracy & disclaimer

Every probability here comes from three numbers somebody made up, and the arithmetic cannot be better than they are. The pessimistic estimate is almost never pessimistic, which makes every figure too optimistic; and the model treats task durations as independent when the causes of delay are shared, which makes real outcomes far worse in the tail than a normal approximation suggests.

Treat a computed 80% as "likely, if nothing systemic goes wrong". These figures are for deciding whether a plan is sound and how much buffer to hold — not for presenting to a customer as a commitment.