Historical Project Outcome Database¶
Evidence repository — instantiates Reference-Class Planning Calibration
A durable store of comparable completed projects and their real outcomes — medians, tails, overruns, and abandonments — from which a reference-class distribution can be drawn.
Every reference-class method needs a reference class to exist somewhere, and in most organizations it does not: past projects live as sanitized status decks, tribal memory, and the occasional war story, none of which yields a distribution. Historical Project Outcome Database is the standing store that fixes this — a structured record of comparable completed efforts, each with its actual outcome (final cost, final duration, rework incurred, whether it was abandoned) attached to enough descriptive attributes that a similar-cases query can be run against it later. Its defining property is that it holds outcomes, not plans, and holds inconvenient ones — the projects that doubled, the ones quietly cancelled — because a class built only from tidy successes produces a base rate that lies. It is infrastructure: it supplies the raw material a forecast draws on, but it does not itself select the class for any particular forecast, adjust an estimate, or judge whether a candidate case truly belongs.
Example¶
A large enterprise IT organization keeps migrating business units off legacy systems onto a shared cloud platform, and every migration is estimated fresh as if it were the first. The Historical Project Outcome Database is built to end that. Each completed migration is entered with attributes — source system age, number of integrations, data volume, whether a vendor was involved, business-unit size — and with its actual outcome: planned versus realized months, planned versus realized cost, count of post-cutover defects, and, crucially, the two migrations that were abandoned mid-flight after data-quality problems proved intractable. When a new migration for the finance unit is being sized, an analyst can now query the store for "migrations off a 15-plus-year-old system with more than twenty integrations" and get back not an average but a shape: a median around eleven months, a cluster near fourteen, a long tail past twenty, and a non-trivial abandonment rate. That shape — the base-rate distribution — is what makes the finance migration's optimistic six-month plan look like what it is. The database does not tell anyone what to do with that; it just makes the honest distribution retrievable.
How it works¶
- Enter completed cases, with outcomes. Every finished project is logged with its final realized figures, not the plan it started from. The unit of record is a real result.
- Attach descriptive attributes. Each case carries the features that let future queries define "comparable" — domain, scale, complexity, dependency count — so a class can be constructed on demand rather than fixed in advance.
- Keep the inconvenient cases. Overruns, reworks, cancellations, and near-failures are retained deliberately; the store's honesty depends on not pruning the tail.
- Serve distributions, not point averages. A query returns the spread of outcomes for matching cases — median, variance, tails — because a base rate is a shape, not a single number.
The database is passive and general-purpose: it answers questions, and different forecasts will slice it into different classes.
Tuning parameters¶
- Inclusion breadth — how wide a net of projects the store captures. Broad coverage supports many future classes but strains data quality and comparability; narrow coverage is cleaner but may leave a new forecast with too few analogues.
- Attribute granularity — how many descriptive features each case carries. Rich attributes let queries carve precise classes but raise the entry cost and tempt users to slice until only flattering cases remain.
- Outcome fields captured — cost and schedule only, or also rework, defects, and abandonment. The richer the outcome record, the more failure modes a class can reveal — and the more uncomfortable the store becomes to maintain.
- Retention and refresh — how far back cases are kept and how current they must be. Old cases add sample size but may reflect conditions that no longer hold.
When it helps, and when it misleads¶
Its strength is that it is the precondition for every other reference-class move: independent estimates, adjustment rules, and reserves all presuppose a distribution, and this is where the distribution comes from. By retaining abandonments and reworks it directly defends the archetype's invariant that the class must include inconvenient outcomes. It is the organizational form of the outside view — the deliberate replacement of a project's inside story with the statistics of its class.[n1]
It misleads when the store's contents are unrepresentative and its size lends them false authority: a database populated only with completed (never cancelled) projects produces a survivorship-flattered base rate, and one whose entries are self-reported plans-relabelled-as-outcomes bakes optimism into the "evidence." A tempting misuse is querying it after the answer is chosen — slicing attributes until only the reassuring cases remain, which is class-gerrymandering with a database's credibility. The guarding discipline is to hold data hygiene at intake (real outcomes, tail cases kept) and to route class selection through a separate step that can be challenged, so the store supplies candidates but does not silently decide membership.
How it implements the components¶
base_rate_distribution— its core deliverable: a queryable spread of actual outcomes for comparable cases, medians and tails and abandonments included, not a single average.reference_class_boundary— its attribute schema is what lets a boundary be drawn around "comparable" cases; it holds the raw material a class is cut from.
It does not compute the outside-view adjustment or challenge whether a chosen class was gerrymandered (outside_view_adjustment_rule, class_membership_challenge) — that per-forecast reasoning is the Reference-Class Forecasting Workbook; the database supplies candidate cases, the workbook decides which count and by how much they move the estimate. It also does not record any single forecast's error (forecast_outcome_memory); that loop is the Forecast Backtesting Review.
Related¶
- Instantiates: Reference-Class Planning Calibration — provides the base-rate evidence the whole calibration gate stands on.
- Consumes: Forecast Backtesting Review — closed forecasts and their errors flow back in as fresh entries.
- Sibling mechanisms: Reference-Class Forecasting Workbook · Forecast Backtesting Review · Independent Estimate Round · Three-Point Estimate with Base Rates · Contingency Reserve Formula · Schedule and Cost Risk Register · Launch or Commitment Readiness Gate · Premortem as Auxiliary Probe
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Historical Project Outcome Database operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it a durable store of comparable completed projects and their real outcomes — medians, tails, overruns, and abandonments — from which a reference-class distribution can be drawn
Independent corroboration: The frozen evidence defines Historical Project Outcome Database as 'A durable store of comparable completed projects and their real outcomes — medians, tails, overruns, and abandonments — from which a reference-class distribution can be drawn', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Maintaining actual cost, duration, overrun, abandonment, and comparable-project attributes is chiefly a project and portfolio management capability.
Related originating lineages:
- Behavioral Economics — Retained as a formative lineage because the independent reviewer identified it as primary: The artifact operationalizes Kahneman and Tversky's outside view by forcing forecasts to begin from a reference class of completed cases.
- Statistics & Experimental Design — Empirical distributions, sampling, and tail estimation supply the database's calibration machinery.
Review resolution: UK government reference-class guidance requires collecting actual outcomes from comparable past projects to correct optimism bias. That institutional project-learning lineage makes organizational management primary, while behavioral economics explains the bias being corrected. The retained alternate domains identify independent or materially shaping provenance, not downstream reach alone. domain_reach=multi_domain because the mechanism has independent established use in several fields. The encyclopedia entry deliberately composes those lineages.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- https://www.gov.uk/government/publications/optimism-bias-and-contingency-at-homes-england/optimism-bias-and-contingency-at-homes-england-accessible-version — Government guidance using reference-class outcomes to correct project optimism bias.
Notes¶
[n1] The outside view, in Kahneman and Tversky's sense, forecasts a project by treating it as an instance of a class of similar projects and using that class's statistical outcomes, rather than by reasoning forward through the project's own intended plan (the inside view). A historical outcome store is the outside view made into standing infrastructure. ↩