Estimate how likely your finish date is

Business planAnyone who can see the project

A plan’s finish date is one number, and everyone knows it is a guess. Schedule risk analysis puts a chance on it. Onplana schedules the plan hundreds or thousands of times. Each time, every open task takes a slightly different length, drawn from its best and worst case, and Onplana counts how often the project finishes by each date. This is often called a Monte Carlo simulation.

The Schedule Risk view answers three questions: when you will probably finish, how likely the plan’s own date is, and which tasks decide it.

Run the analysis

Open the project, open the Plan tab under the project header, and select Schedule Risk.
Give the tasks you know best a range of their own in the Estimates table at the bottom of the view. See Give tasks a range. You can skip this for a first run: every task without a range takes the run’s default range.
Set up the run in the panel at the top, or keep the defaults:
- Iterations: how many times to schedule the plan, a whole number from 100 to 5,000. The default is 1,000. More gives a smoother curve and takes longer.
- Distribution: Triangular (the default) or PERT. See How a run works.
- Default range for tasks with no estimate: how much shorter and longer a task without its own range can be, as a percentage of its most likely duration. The default is 10% shorter and 25% longer. Shorter can be 0 to 99 percent, longer 0 to 900 percent.
- Target date: the date you want the chance of. Leave it empty to use the project’s end date. If the project has no end date either, the run has no target.
Select Run. The run waits in a queue, then runs, and the view shows which of the two it is doing. The results appear when it finishes, which usually takes seconds.

A run reads the plan as it is when the run starts, and the results say so: “Based on the plan as of” a date and time, and how many times it ran. Change the plan and run again to see the effect.

How a run works

In each iteration, Onplana:

draws a duration for every open task, between its optimistic and pessimistic values, around its most likely value
schedules the plan through its dependencies, with Onplana’s scheduler, on the project’s working calendar
records when the project finished, when each milestone finished, and which tasks were on the critical path

What each task contributes:

Most likely is the duration the scheduler already uses for the task. Once a task has started, it is what is left of the task, so only the remaining work varies. See Duration, remaining work and actual start.
Triangular draws from a triangle that peaks at the most likely value. It is the default, and the more cautious of the two. PERT draws closer to the most likely value, so the same range gives a narrower spread.
Done tasks, milestones, and started tasks with nothing left are held still. They do not vary.
Summary tasks are not varied. Their length comes from the tasks under them. For the run, a dependency on a summary task applies to every task under it, with the same type and lag.
Must Start On and Must Finish On constraints with a date keep that date in every iteration. The task’s duration still varies around it. Each one holds a date still and narrows the spread, so the run counts them. See Scheduling constraints.
Durations are counted in working time, so a task drawn at 1.05 days costs 1.05 days, not two whole days.
Remaining work is counted from the status date: the project’s status date, or the moment the run starts when the project has none. See The project status date.

Give tasks a range

A range is a task’s best and worst case, in work days, around its most likely duration. You can enter it in two places:

The Estimates table on the Schedule Risk view. It lists every task a run varies, with Most likely (work days), Optimistic (work days) and Pessimistic (work days). Type a value, then press Enter or move out of the field to save it. Escape puts the saved value back. Empty a field to remove that side of the range. Select No estimate yet to show only the tasks without one. The line above the table counts them, for example “Tasks with an estimate: 12 of 40.” The table shows 50 tasks at a time.
The task form. Open a task, open More, and fill Optimistic (work days) and Pessimistic (work days) under Schedule.

The rules:

Optimistic can be at most the most likely duration, and pessimistic must be at least it. Pessimistic must also be at least optimistic. A value that breaks a rule is not saved, and the reason appears under the field, for example “Optimistic can be at most the most likely duration, 3 work days.”
A task with no range takes the run’s default percentages. A task with only one side set takes the default for the other side.
A range can go out of order later, because the most likely value moves when someone edits the task’s duration. The run does not refuse it. For that run, it moves the out-of-order side to the most likely value, and counts the task under About this run.
A work day is a day of the project’s working calendar, 8 hours unless an administrator has changed it.
The table leaves out done tasks, milestones, summary tasks, and tasks with nothing left to do, because a run holds them still.
You can change the range on any task you are allowed to edit. Other tasks show their values as plain numbers.

Risk events

A range covers ordinary uncertainty in a task. Some delays are different: they either happen or they do not, like a permit that is refused or a supplier that fails. Enter those as risks on the project’s Risks tab, and a run includes them.

On a plan that includes schedule risk analysis, the risk form has a Schedule impact section with three fields:

Probability (%): the chance the risk happens, from 0 to 100.
Impact (working days): how many working days it adds when it happens. More than 0, and at most 3,650.
Affected tasks: the tasks it would delay, up to 200. Search for a task by name.

See Keep a risk register for the rest of the form.

A run includes a risk when:

it is open, so not dismissed and not accepted
it has both a probability and an impact
it names at least one task the run varies

In each iteration, each risk happens or not, by its probability. When it happens, each affected task takes the full impact as extra duration. So a risk that names two tasks in one chain delays that chain twice. A started task gets the impact added to its remaining work. Risks are drawn independently of each other and of the task durations.

What the run ignores:

Affected tasks the run holds still: done tasks, milestones and summary tasks. The form offers done tasks and milestones but does not let you pick them, and leaves summary tasks out.
A risk with no task left after that. The view says how many risks had a probability and an impact but no task the run could delay.

Risk events in the results

When a run includes risks, a note beside the results says how many, for example “This run included 2 risks from the Risks tab”. Below it, each risk has its own row: its description, its chance, and the share of runs in which it happened, for example “30% chance, happened in 29% of runs”.

What moves the finish still ranks tasks by their own durations. A risk’s impact is not counted in a task’s bar there.

An agent can set the same three fields when it records a risk through Onplana’s MCP server.

Read the results

The four figures at the top

Figure	What it means
P50 finish	Half the runs finish by this day.
P80 finish	Four runs in five finish by this day.
Chance of the plan date	The share of runs that finish by the plan’s own finish: the date the plan reaches when every task takes its most likely duration.
Chance of the target	The share of runs that finish by the target date, or by the project’s end date when you left the target empty. It shows No target when the run had none.

“By a date” means by the end of that calendar day, everywhere on the view. A run that finishes at 3 PM on March 8 counts as finishing by March 8. The two chances, the curve, its table and the readout all count this way.

Two notes beside the results

Beside every result, the view shows a note that each task’s duration is drawn on its own, as if one task running late never made another late. On real projects delays tend to travel together: one supplier, one team, one wrong assumption. So the real spread is usually wider than the run shows, and its dates lean optimistic.

A second note appears when the run’s plan finish differs from the project’s end date. It names both dates. The run schedules the plan from its links, while the Gantt chart shows the dates stored on the tasks. The two differ when stored dates no longer follow the links, for example after automatic scheduling was turned off and dates drifted. In that case Chance of the plan date reads against the run’s date, and Chance of the target against the end date, so the two can disagree.

The finish curve

Chance of finishing by each date plots the share of runs that finished on or before each date, from the earliest run finish to the latest. Two marked lines show the plan’s date (Plan) and the target (Target). A marker far outside the curve sits at the edge with an arrow.

Point at the curve, or select it and use the Left and Right arrow keys, to read a line such as “62% of runs finish by Mar 8, 2027”. Select Show the curve as a table to read every value: one row per calendar day, with Finished by, Runs since the row above and Share of runs.

Milestones

Each milestone gets a row: Planned, P50 finish, P80 finish, and P80 against plan, which reads On or before plan or how many calendar days later. Planned is the milestone’s date when every task takes its most likely duration. Select a milestone’s name to open it.

How often each task was critical

The share of runs in which each task was on the critical path, the highest first. Ten show at first; Show all lists the rest. A task that is critical in most runs is one where any slip moves the finish. Select a name to open the task.

What moves the finish

The tornado chart ranks up to 20 tasks by how closely their drawn duration tracked the project finish, as a rank correlation (Spearman) from -1 to 1. The longest bar is on top. A bar marked Longer task, later finish means the runs where that task ran long tended to finish late. A bar on the other side, Longer task, earlier finish, means the opposite. The longest bars are the estimates to get right and the tasks to watch.

A task that is critical in nearly every run can still sit low here when its range is narrow, because its length barely changes from run to run.

About this run

Open About this run for what the run used and found:

Iterations, Seed (where the run’s random draws started) and Distribution
Default range, as two percentages
Tasks in the plan and Tasks whose duration varied
Tasks held still (done, milestones, nothing left)
Tasks with an estimate of their own
Estimates out of order, corrected for the run
Dates held by Must start on or Must finish on
Status date

Below the list, the run names anything about the plan that weakens the result, such as “Some tasks have no links, so nothing moves them when the work before them slips.”

Run history

Under the results, Run history lists the project’s runs, newest first, with Started, By, Status, Iterations, P50 finish, P80 finish, Plan date chance and Target chance. Read P80 down the column to see the trend.

Select a run’s start time to show its results. While a newer run is waiting, running or has failed, the last finished run’s results stay on screen, marked Last finished run. Onplana keeps the last 20 finished runs of each project and removes older ones when a new run finishes.

Limits

Limit	Value
Iterations per run	100 to 5,000, 1,000 by default
Tasks in the project	5,000 at most
Runs waiting to start, per project	One. Selecting Run while one waits shows that run instead of queuing a second.
Runs per organization	20 an hour. After that, the view says how many minutes to wait.
Finished runs kept per project	The last 20
Time to finish	A run still waiting or running after 30 minutes is stopped

When a run fails

The view says	What to do
The project has no tasks to simulate.	Add tasks.
The schedule has a dependency loop, so it cannot be scheduled. Remove the loop and run again.	Remove the dependency that closes the loop. See Circular dependency protection.
The project has more than 5,000 tasks, the most a risk run can simulate.	A run cannot take a plan this large.
The run did not finish within 30 minutes and was stopped. Start a new run.	Run again.
The run could not be queued. Try again in a few minutes.	Wait a few minutes and run again.
The run failed. Try again, and if it fails again, contact support.	Run again, then contact support if it fails again.

Who can use it

Anyone who can see the project can open the view and read its runs.
Starting a run needs permission to edit tasks in the project. With the default permissions that is a project Contributor and up. A Project Viewer can read runs but not start one, and sees “Starting a risk run needs permission to edit tasks in this project.” Your organization can change this in the permission matrix.
Entering a range follows the same rights as editing the task.
Entering a risk’s probability, impact and tasks follows the same rights as adding a risk. See Who can add and edit risks.

Use it with Schedule Quality and baselines

A run is only as good as the links in the plan. A task with no links is not pushed by the work before it, so a slip upstream never reaches it, and the curve comes out too narrow. Run Schedule Quality first and fix what its Logic check flags.

A run does not read baselines: its plan date is the plan as it stands now. To see the chance of a baseline’s finish, enter that date as the Target date. To compare the plan with what actually happened, see Capture and compare baselines.

FAQs

Why is the chance of the plan date lower than I expected? The plan date assumes every task takes exactly its most likely duration. In a run, some tasks run long and some short, and where two paths meet the later one sets the date, so finishes tend to land after the plan. The default range is also lopsided: 10% shorter against 25% longer.

Does a run change my plan? No. A run schedules copies of the plan and saves nothing to it. Only the ranges you enter are saved, on their tasks.

Why did a second run give slightly different dates? Each run draws new random durations, so two runs of the same plan differ a little. More iterations bring them closer together.

Why is a task missing from the Estimates table? It is done, a milestone, a summary task, or a started task with nothing left. A run holds those still, so they need no range.

Should I commit to the P50 or the P80 date? P50 is a coin toss: half the runs finish later. P80 leaves one run in five later, and the note about independent durations says the real spread is usually wider still.

Can I share the view? Yes. The view has its own address, so you can copy the page link and send it to anyone who can see the project.

Was this helpful?