Critical path and schedule risk for the PMO — the project management office — and delivery leads. A date is a guess; a distribution is an answer.
Free. Your figures never leave your browser — no signup, nothing you enter is uploaded. The chat assistant is the one part that talks to a server, and only what you type into it is sent.
Worked example. Take the Core build row. On a good run it is done in 20 days. Normally it takes 28. And if the integration spec moves halfway through, 45. Those three numbers took ten seconds to think of, and they are worth far more than one confident 28.
| Rule | Why |
|---|---|
| Count working days, not calendar days | Weekends are added back for you once you give a start date, so a 5 day task starting Thursday correctly lands the following Wednesday. Counting calendar days here would count the weekend twice. |
| Do not pad the numbers | This is the big one. Quietly adding a few safe days to every task hides where the risk actually is, and double-counts the buffer. Working out the buffer is Sooth's job — give it honest numbers and it tells you how much you need and where to put it. |
| The gap is the signal, not the middle | A task estimated 20 / 28 / 45 carries far more risk than one at 26 / 28 / 30, even though both are "about 28". The width of the spread is what decides whether your date is a commitment or a coin flip. |
| One number is allowed | If a task genuinely cannot vary, put the figure in Best and leave Likely and Worst empty. It is then treated as fixed and will not move in the simulation. A duration of 0 is a milestone — a date to hit, with no work behind it. |
| Rough beats blank | A guessed range you are 70% happy with tells you more than leaving the task out, and far more than a single date nobody believes. You can sharpen it later. |
One task per line, separated by |, tab or comma.
id | name | best | likely | worst | predecessors, or
id | name | duration | predecessors with a single estimate. Edits here rewrite the
rows above, and the rows above rewrite this, so the two can never disagree.
The same task list, simulated thousands of times. Every task's duration is drawn from its own three estimates, the whole network is re-solved each time, and what comes back is a range of finish dates with the odds attached.
A percentile is a diagnosis, not a plan. This takes the same task list and asks the next question: what can you actually do about it, and what is it worth? Every figure below is measured by re-running the simulation with that change applied — nothing here is a rule of thumb. Where the date cannot practically be improved, it says so and names the reason.
Every risk model rests on assumptions. These are the ones behind these numbers, so you can judge where they hold and where they do not.
| What is assumed | Why it matters |
|---|---|
| Task durations are independent | The simulation draws each task on its own. In real projects delays are correlated: the same absent specialist, the same late vendor, the same optimistic team. Correlated risk makes the true spread wider than shown, so treat the P80 here as a floor rather than a ceiling. |
| Your three estimates are honest | Garbage in, garbage out applies with force. If "worst case" is really "worst case if nothing unusual happens", the model inherits that optimism. The worst case should be a genuine bad day, not a slightly disappointing one. |
| The network is right | Only the dependencies you list are respected. A missing dependency lets two tasks run in parallel that in reality cannot, and the finish date will be too early. The critical path is only as good as the links you gave it. |
| Finish to start only | A task starts when all its predecessors finish. No leads, no lags, no start-to-start or finish-to-finish links, and no partial overlap. |
| Unlimited resources | This is a schedule model, not a resource model. If two parallel tasks both need the same person, the plan shown is impossible and the real finish is later. That is what the WFM Scheduler is for on the staffing side. |
| No scope change | The task list is fixed for the whole simulation. Work discovered later is the single largest source of overrun in real projects and no schedule model can see it. |
| Working days, not calendar days | Durations are working days. Weekends are skipped when a start date is given. Public holidays are not modelled, so a project spanning a holiday period will run later than shown. |
Monte Carlo does not make a bad plan good. It makes an honest plan legible, and it exposes the false confidence in a single date. Sense-check the output before it reaches a client, the way you would any other model.