How BidVariance reaches its numbers

Why one estimate is not one number

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.

The Beta-PERT distribution

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 is (P − O)/6, 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.

How a run is scheduled

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.

Reading percentiles honestly

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.

From probabilities to a price

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.

The decision label

BidVariance converts probabilities into BID / BID WITH CONDITIONS / DO NOT BID AT THIS PRICE using your thresholds (defaults: loss ≤ 10% and target-margin probability ≥ 80% and deadline confidence ≥ 80% to bid; loss > 25% or target-margin probability < 50% to refuse). These are your risk appetite, editable at any time — the tool never pretends they are universal truth.

Reproducibility

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.

Limitations — read before trusting anything

• Outputs are conditional on your inputs. Weak estimates in, confident-looking nonsense out.
• Task durations are sampled independently; common-cause correlations (one sick architect slowing many tasks) are only captured if you model them as explicit risks.
• Finish-to-Start is the only dependency type in this version; lags and overlapping work are not modelled.
• Costs are modeled as burn-rate × duration; payment timing and cash flow are out of scope.
• 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.