How BidVariance reaches its numbers

A deterministic estimate — “that task is 8 days” — quietly claims more knowledge than anyone has. The honest form of the same statement is a range: it will probably take around 8 days; it cannot reasonably take less than 5; if the vendor integration bites, it could stretch to 20. Those three numbers (optimistic, most likely, pessimistic) are exactly what BidVariance asks for.

BidVariance then runs the project thousands of times. In each simulated run, every task duration, every cost, and every risk event takes a plausible value rather than its single “expected” value. The collection of results is a probability distribution, and that distribution — not a single number — is what a commercial decision actually needs.

Each three-point estimate becomes a Beta-PERT distribution with λ = 4 (the classic PERT choice):

α = 1 + λ·(M − O)/(P − O)
β = 1 + λ·(P − M)/(P − O)
sample = O + Beta(α, β) · (P − O)

Properties worth knowing: the mean equals the familiar PERT weighted average (O + 4M + P)/6, the classic PERT standard-deviation approximation is (P − O)/6 (not the exact Beta-PERT standard deviation), and when O = M = P the task is treated as deterministic. Most of the mass sits near your “most likely” value; the tails behave sensibly without requiring you to pick a distribution family.

Each simulated run walks your task graph in dependency order (Finish-to-Start; independent tasks run in parallel):

1. sample every task duration from its Beta-PERT distribution;
2. a task starts when all of its predecessors have finished;
3. a task-attributed risk, when it fires, adds cost and/or delay to that task;
4. the project finishes when the last task finishes, plus any project-wide risk delay;
5. cost accumulates: fixed cost + duration × burn rate per task, plus risk costs, plus project fixed costs and overhead.

Circular dependencies are rejected before simulating — the graph must be a DAG. Cost aggregation is explicit: you see fixed costs and overhead added once, never as invisible percentages.

After N runs, BidVariance reports the distribution of outcomes:

P50

Half of simulated outcomes are at or below this. A midpoint — not a safe commitment. Quoting a deadline at P50 is a coin flip.

P80

80% of outcomes at or below. A common commercial reference for bids and delivery dates.

P90

More conservative; reasonable when the downside of overrun is expensive.

These are properties of your assumptions. If the pessimistic values are guesses, P90 is a precise-looking number built on sand. BidVariance flags zero-uncertainty tasks and other structural warnings for exactly this reason.

Joint cost and deadline confidence

Schedule lab counts the runs where duration ≤ the trial deadline and cost ≤ contract price, divided by all runs. This is the probability of meeting both conditions within the model, using matching cost/duration pairs. It is not the product of the two separate percentages. The date shortcuts use a nearest-rank duration rounded up to a whole calendar day, so they cover at least the named share of sampled finishes; chart percentiles retain type-7 interpolation.

The price you charge does not change what the project costs, so the minimum defensible quote has an exact closed form:

requiredPrice = costQuantile(confidence) / (1 − targetMargin)

Example: P80 project cost is 92,000 and you want a 25% gross margin — 92,000 / 0.75 = 122,666.67. At that price, 80% of simulated runs clear your margin target. If a future model version ever makes costs depend on price (penalties, nonlinear terms), this formula is replaced by a numerical solver rather than silently misapplied.

BidVariance converts probabilities into BID / BID WITH CONDITIONS / DO NOT BID AT THIS PRICE using your thresholds — the defaults are the table below, and they are editable at any time. The tool never pretends they are universal truth.

Everything below is read from the same simulated runs, or from short re-runs that reuse the run's random seed so that a difference is caused by the change rather than by sampling noise.

Path to a clean BID

The smallest price meeting each price rule on this sample: P(loss) ≤ limit needs price ≥ the ⌈(1 − limit)·n⌉-th smallest cost; P(margin ≥ m) ≥ bar needs price ≥ the ⌈bar·n⌉-th smallest cost ÷ (1 − m). Each is rounded up to a quoting unit and re-checked on the sample, so applying it and re-running the same seed reproduces a pass. The deadline rule gives the first whole calendar day by which the required share of runs has finished.

Price corridor

The same construction with your refusal limits gives the refusal floor; with your BID limits, the clean-bid price. The confidence-based quote between them uses the interpolated cost percentile from the pricing formula above.

Cost overrun and contingency

The share of runs whose total cost exceeds a reference — the single-number plan at likely durations, the expected cost, or the cost budget your margin allows — and, for each confidence level, the contingency = cost percentile − reference.

Criticality index

In each run the engine walks back from the last task to finish along the predecessor that set each start. A task's criticality is the share of runs in which it was on that chain.

Sensitivity

The tornado pins one driver at a time at its favorable and unfavorable bound (a task at its optimistic or pessimistic duration; a risk never or always firing) and re-simulates P80 cost and P80 finish with a shared seed. The variance-contribution chart uses the full run: the squared correlation of each task's sampled duration (or each risk's firing) with total cost or duration, normalized to 100%.

Scope creep

The duration of each selected task is multiplied by (1 + g). A fixed g draws no random numbers, so every growth level reuses the baseline's draws; an uncertain g is drawn once per run from a Beta-PERT over your low, likely and high growth. Headroom is the growth at which a metric crosses your threshold, interpolated between grid points.

Change requests and mitigation

A change request is added as a task with its own three-point duration, daily cost and position in the network; its quote is the increase in cost at your confidence target ÷ (1 − target margin). A mitigation lowers one risk's probability and impact and adds its cost to fixed project costs, so every probability of the mitigated run already includes what it costs.

Scenarios

A saved scenario keeps its terms, a summary of the run and 101-point quantile sketches of cost and duration (P0, P1 … P100), from which the comparison curves are drawn.

Simulations use a seeded pseudo-random generator. Fix the seed and the same inputs, iteration count, and distribution reproduce identical results — so a number in a meeting can be regenerated exactly.

• Outputs are conditional on your inputs. Weak estimates in, confident-looking nonsense out.
• Task durations are sampled independently; a single risk can affect one task or final project delivery, but there is no general correlated-duration or shared multi-task risk model.
• Finish-to-Start is the only dependency type in this version; lags and overlapping work are not modelled.
• Costs are modeled as burn-rate × sampled task duration. Risk delays do not automatically add burn cost: include associated expense in the risk cost range. Payment timing and cash flow are out of scope.
• Duration uses calendar days. Working calendars, resource leveling and automatic staffing constraints are not modeled.
• Variance contribution is a first-order reading from correlations; drivers that interact through the schedule can share variance. Use the tornado to confirm a lever before acting on it.
• Scope creep scales the durations of the tasks you select; it does not invent new tasks, dependencies or risks. Model a specific addition as a change request instead.
• This is decision support, not legal, tax, accounting, or contractual advice.

BidVariance models uncertainty from user-supplied assumptions. Results are simulated scenarios, not guarantees or professional advice. A result is only as defensible as the estimates, dependencies, cost assumptions, and risk probabilities entered.