Effort Estimation & Probabilistic ETA

A date without uncertainty is not a forecast contract

A learning-platform team has a baseline, some observed effort and several remaining tasks. Two of the tasks are dependent, one external review may add delay, and management asks for “the ETA.” Returning one date hides the exact evidence that makes the date uncertain.

This lesson builds Probabilistic Effort & ETA Forecast Contract v1. It separates observed actuals from assumptions about remaining work, stores duration distributions and their basis, keeps dependencies and discrete risks explicit, computes a completion distribution, reports selected percentiles such as P50 and P80, exposes sensitivity drivers and schedule margin, and creates a new forecast revision when actuals, scope or risk state changes.

The strongest successful state is FORECAST_REVIEW_REQUIRED. A percentile is evidence for a bounded planning decision, not a guarantee. The lab is synthetic and offline; it does not alter a live project baseline or commit an external delivery date.

For: learning-platform/product engineers, project-control owners, delivery leads, analytics engineers and reviewers. Not for: contractual commitments, health/workload diagnosis, invented probabilities, hidden AI estimates, or silently moving a baseline date.

Route orientation and ownership boundary

MKN-016 owns probabilistic effort and ETA evidence. Its hard prerequisite is MKN-013; MKN-015 is a soft prerequisite that supplies progress/control context. MKN-015 owns weighted project progress; MKN-017 owns OAuth/OIDC and social publishing. This lesson may consume progress evidence but must not absorb those adjacent outcomes.

Foundation learners should follow one three-task schedule from visible assumptions to P50/P80. Repair learners should isolate the first missing or stale evidence dimension and stop the forecast there. Experienced learners should defend the distribution basis, dependency/risk model, percentile communication policy, sensitivity result and revision trigger.

Checkpoints: F1 separate actual effort from remaining-work assumptions; F2 reject single-point durations as a substitute for uncertainty evidence; F3 make a discrete risk certain after two tasks finish early and recompute rather than preserving the old P80 for appearance.

Mental model: evidence → uncertainty model → completion distribution → percentile decision → revision

Use this flow:

baseline + actuals + remaining work → duration distributions + dependencies + discrete risks → deterministic simulation contract → completion distribution → P50/P80 + margin + sensitivity → human forecast review → revision when evidence changes

actual_effort_to_date is observed evidence. remaining_work_estimate is a current assumption. A duration distribution expresses uncertainty about elapsed duration; it is not the same thing as an effort total. A discrete risk has a probability and an impact model; it must not be smuggled into the task duration without provenance.

The output should be treated as a distribution. P50 is the date by which about half the simulated outcomes finish at or before that point under the model. P80 is a more conservative percentile under the same assumptions. Neither proves that the project will finish on that date. If assumptions change, the old distribution becomes historical evidence and a new forecast_revision is required.

Foundation contract: twenty frozen evidence dimensions

The frozen dimensions are forecast_id, baseline_ref, work_package_ref, actual_effort_to_date, remaining_work_estimate, duration_distribution, distribution_basis, dependency_ref, discrete_risk_ref, risk_probability, risk_impact, simulation_model_ref, completion_date_distribution, p50_date, p80_date, confidence_level, schedule_margin, sensitivity_driver, forecast_revision, and review_owner.

Minimum invariants:

1. Forecast, baseline and work-package identity are explicit and versioned.
2. Actual effort is recorded separately from remaining-work assumptions.
3. Every remaining duration has a non-degenerate uncertainty distribution and an evidence basis.
4. Dependencies are explicit; parallel and serial work cannot be inferred from row order.
5. Each discrete risk has an explicit probability and impact distribution; missing probability is not zero.
6. The simulation model and run count are versioned and reproducible from visible evidence.
7. The completion-date distribution is primary output; P50/P80 are summaries of it.
8. p80_date cannot be earlier than p50_date under the same output distribution.
9. Schedule margin is explained as an allowance tied to uncertainty/risk, not a hidden buffer that freezes an old date.
10. Sensitivity identifies which assumptions drive forecast spread or movement.
11. New actuals, scope or risk-state changes require a new forecast revision.
12. Review owner and provenance make the bounded decision auditable.

Deep explanation: uncertainty, margin and percentile language

Schedule Risk Analysis — FACT. NASA's current PP&C glossary describes Schedule Risk Analysis as probabilistic analysis of a schedule using Monte Carlo simulations that incorporate duration uncertainty distributions and discrete risks, producing confidence levels for completion or key milestones. The same glossary describes probabilistic schedule estimating as producing a cumulative distribution of possible completion dates. NASA does not thereby prescribe MAKNOW's exact task distributions, run count or review threshold.

Schedule margin — FACT. NASA guidance describes schedule margin as an allowance carried to account for uncertainties and risks. The Schedule Management Handbook recommends using probabilistic schedule risk assessment as a basis for determining adequate margin and warns against using margin merely to hold a deliverable forecast to a static date.

Forecast communication — INFERENCE. MAKNOW therefore reports a small set of percentiles together with assumptions and sensitivity drivers rather than presenting one date as certainty. If actuals or risk states change, the old forecast is retained as revision history and a new distribution is computed.

Local design — DESIGN. Distribution families, minimum simulation runs, P50/P80 display, sensitivity method, escalation states and the FORECAST_REVIEW_REQUIRED ceiling are MAKNOW design authority. External project-management guidance informs evidence boundaries; it does not make the local forecast a contractual commitment.

Worked examples

Example A — baseline with visible uncertainty

Three remaining serial tasks use triangular duration distributions with visible min/mode/max values. External review has a 25% chance of adding a triangular delay. The deterministic lab uses a fixed seed and recorded run count to produce a completion distribution. P50 and P80 are derived from that distribution, the difference between them is reported as an indicative margin, and the strongest state is FORECAST_REVIEW_REQUIRED.

Example B — single-point shortcut

A planner replaces every triangular distribution with one “best estimate.” The schedule still looks computable, but uncertainty evidence has been removed. The correct state is HOLD_UNCERTAINTY_MODEL; running Monte Carlo on constants does not restore the missing uncertainty model.

Example C — risk becomes certain

The external review risk was previously 25%, then becomes certain. If the record keeps the old forecast revision, the state is REFORECAST_REQUIRED. The repair is not to edit P80 manually; update the risk state, create a new forecast revision and rerun the same transparent model.

Example D — transfer after one week

Two tasks finish early, but the external-review risk becomes certain. Actuals improve while risk worsens. Recompute from the new state. The resulting P80 can stay near or move later than the earlier P80 even though two tasks finished early. Keeping the old date merely to show “schedule stability” would destroy the evidence trail.

Failure modes that must fail closed

• Single-point durations replace uncertainty distributions → HOLD_UNCERTAINTY_MODEL.
• Distribution exists but no basis/source is recorded → HOLD_DISTRIBUTION_BASIS.
• Dependency graph references a missing task or contradictory ordering → HOLD_DEPENDENCY.
• Discrete risk lacks probability or impact evidence → HOLD_RISK_MODEL.
• Risk or actuals change but revision is not advanced → REFORECAST_REQUIRED.
• Only one deterministic due date is stored and no completion distribution can be reconstructed → HOLD_OUTPUT_CONTRACT.
• Simulation model/version or run count is missing → HOLD_MODEL_EVIDENCE.
• Sensitivity evidence is absent → HOLD_SENSITIVITY.
• Forecast/baseline/work-package identity is incomplete → HOLD_SCOPE_IDENTITY.
• Review owner or provenance is missing → HOLD_AUDIT_PROVENANCE.
• Transfer copies the old P80 instead of recomputing → HOLD_BASELINE_ORACLE_REUSE.

Alternatives and trade-offs

Three-point/triangular task durations. Easy to explain and useful for bounded exercises, but they can create false precision if the min/mode/max values have no evidence basis.

Historical empirical distributions. Better grounded when comparable work exists, but comparability and sample drift must be defended.

Scenario bands instead of Monte Carlo. Easier to operate for small projects, but loses a full completion distribution and can hide interactions between multiple risks.

P50 as the visible planning date. Less conservative and useful for internal planning, but more likely to be exceeded than a higher percentile under the same model.

P80 as a review point. More conservative but still not a guarantee. The percentile label must travel with the assumptions and revision identifier.

Large static buffer. Simple, but easy to confuse with a commitment and easy to consume without risk evidence. Prefer explicit risk-informed margin and revision history.

Experienced bridge: four things worth defending

First, defend assumption provenance. A probability or duration spread without a basis is not stronger because it has decimals.

Second, defend model identity. Reproducibility requires a model reference, seed/run contract and versioned input evidence. A changed model is a changed forecast even if the displayed P80 is coincidentally similar.

Third, defend sensitivity over storytelling. If one task or risk dominates output variance, surface it. Do not write a narrative that focuses on a low-impact item simply because it is politically convenient.

Fourth, defend revision history. Forecast v1 can be wrong in light of new evidence without being rewritten. Preserve v1, record what changed, compute v2 and compare. That is how a forecast becomes auditable rather than cosmetic.

Guided and independent practice

Guided: open lab://MKN-016/MKN-016-LAB1. Run the baseline fixture. Inspect the visible duration distributions, dependency chain, risk probability/impact, fixed simulation model and resulting P50/P80. Explain why the output stops at human forecast review.

Repair: mutate one field at a time. Replace distributions with constants, remove the distribution basis, break a dependency, remove risk impact, hide sensitivity evidence or change actuals without advancing the revision. Name the first invalidated dimension and the smallest safe repair.

Independent: use the transfer fixture. Two tasks have completed earlier than their baseline durations and the external review risk is now certain. Update actual effort, remaining work, risk state and revision, then recompute. Do not copy the baseline percentile dates.

Verification evidence: what a reviewer must reconstruct

A reviewer must be able to reconstruct which baseline/work package the forecast belongs to, what effort is already observed, what work remains, each remaining duration distribution and its basis, the dependency graph, every discrete risk probability/impact, the simulation model/run count, the completion distribution summary, P50/P80, confidence label, margin, top sensitivity driver, revision and owner.

The reviewer must also prove negative boundaries: a constant duration did not masquerade as uncertainty; missing risk data did not default to zero; schedule margin was not used to freeze an old date; changed actuals/risk created a new revision; and the transfer result was recomputed from the changed fixture.

If decisive evidence is missing, stale or contradictory, the record stays in a typed hold/reforecast state. A plausible date is not verification evidence.

Assessment and transfer

S1: Explain the difference between observed effort, remaining-work estimate and elapsed-duration uncertainty. S2: Build Probabilistic Effort & ETA Forecast Contract v1 for the baseline fixture and report P50/P80 plus the top sensitivity driver. S3: Replace the duration distributions with single-point estimates; identify the invalidated evidence and safe state. S4: One week later, two tasks finish early but the external-review risk becomes certain. Rebuild the forecast as a new revision and compare its P80 with the baseline without preserving the old date as an oracle.

Blocking misconception: “P80 means an 80% guarantee and should remain stable once communicated.”

AI may organize supplied synthetic evidence and run deterministic simulation. It may not invent task distributions, risk probabilities, confidence labels, live project state or contractual commitments.

References, freshness and authority boundary

• NASA PP&C Glossary — FACT: current glossary defines Schedule Risk Analysis as probabilistic schedule analysis using duration uncertainty and discrete risks/Monte Carlo, producing confidence levels for completion milestones.
• NASA Schedule Management Handbook — FACT: schedule margin is tied to uncertainty/risk and probabilistic schedule assessment can inform adequacy of margin; margin should not merely keep a forecast artificially static.
• MAKNOW inference/design: selected percentile communication, minimum run count, sensitivity method, typed hold states and revision policy are local design authority.

Freshness was rechecked on 2026-09-13. Re-review by 2027-01-15, or earlier if NASA schedule-risk or schedule-management guidance materially changes.