Base rates and the outside view: using past results to estimate deadlines

A team promises to complete a data migration in ten business days. The plan details steps and owners, but nobody has checked how long similar migrations took. All projects and numbers in this example are fictional.

The inside view describes how this migration should unfold. The outside view starts with results from comparable cases. The difference between the two estimates helps locate an expectation that needs explaining before becoming a commitment.

Define the outcome you want to estimate

A base rate is an observed frequency within a relevant reference class. Using it requires defining the outcome and which cases enter the comparison. The share of migrations completed on time answers a different question from their typical duration.

Also establish what completion means. Transferring files, validating data and closing the old system are different milestones. A record that mixes these milestones may offer apparent precision without answering your question.

Reference class forecasting, discussed by Bent Flyvbjerg, uses outcomes from comparable projects as a starting point. Applying that perspective to a small migration requires choosing your own comparison set.

Choose cases before looking at the outcome

Look for projects with conditions relevant to the question: data sources, external dependencies, scope and team experience, for example. Explain why each characteristic matters; similarity in the project name may reveal little about the work.

If you select only completed migrations, you will exclude those abandoned or still open. Include those records and identify their status. A project without an end date should not be given an invented duration to fit the calculation.

Avoid changing the group just because its results contradict your expectation. If there is a reason to exclude a case, record it. When two defensible selections produce different conclusions, show that difference in the estimate.

Worked example: from a ten-day plan to negotiating a deadline

Consider these durations for ten comparable migrations, in business days: 8, 9, 10, 10, 11, 12, 13, 14, 16 and 18. All were measured to the same milestone: validated data and closure of the old system. To simplify the calculation, suppose each also had an initial deadline of ten days.

Six exceeded the deadline. The historical frequency of delay is 6 ÷ 10 = 60%; completion by the tenth day is 4 ÷ 10 = 40%. Now compare other deadline limits within this set:

Promising ten days leaves six of the ten previous results outside the deadline. Fourteen days would accommodate eight; two migrations would still fall outside it. Even the final row's 100% does not guarantee a future deadline: the table describes a small sample that may omit relevant difficulties.

One defensible proposal would be to negotiate fourteen business days, with a data quality check on the third day. If that check finds a dependency absent from previous cases, the team would revise the deadline before continuing. Choosing fourteen days expresses a negotiated tolerance for risk; it does not turn the observed 80% into an established individual probability.

The decision journal entry could read: “Internal plan: ten days. Comparable record: eight of ten cases finished within fourteen. Proposal: fourteen days, subject to a data check on the third day. We still need to confirm whether the customer can tolerate a longer deadline and what we will do if the check fails.”

Check the quality of the records and whether projects share problems. Alongside frequencies, examine how much deadlines varied and under what conditions delays occurred. An isolated average hides those differences.

If records are missing, say what is absent. Team accounts can guide the search if identified as recollections. A guess collected in a meeting remains a guess even when it appears in a spreadsheet.

Explain what makes this case different

Perhaps the current migration uses a tool that shortened a slow step. To adjust the reference, ask whether that reduction was observed under similar conditions and whether the step actually constrained the total schedule.

A motivated team or an important customer does not, by itself, explain why the record no longer applies. Look for a difference that changes how the work functions. Also consider unfavorable changes, such as a new dependency or less organized data.

Keep the historical record and the adjustment separate. Another person can then discuss whether the claimed difference supports the forecast without reconstructing which numbers belonged to previous cases and which came from your interpretation.

Use the reference to change the commitment

The record may lead you to negotiate a range of dates, bring a validation forward or reduce the initial scope. It may also reveal that the decision depends on information not yet obtained.

Investigate that question when the answer could change the plan. The article on when to seek more information helps compare the expected benefit of investigation with its cost and the delay involved.

When speaking to the customer, present the completion milestone, the reference used and the review point. If the ten-day date cannot change, the team needs to discuss reduced scope or another delivery arrangement. Changing the estimate in a spreadsheet alone does not change the work required.