Base rate neglect, also called the base rate fallacy, happens when you give too little weight to how often something occurs in comparable cases. One detail about the case in front of you can draw your attention away from that history.
Suppose a warning caught 8 out of 10 late project launches. This morning, the same warning appeared on your project. Would you tell the sponsor there is an 80% chance of a delay? Before answering, ask how many projects triggered the warning and still launched on time.
What is a base rate?
A base rate is the share of cases in a relevant group that have a particular outcome. If 10 of your last 100 comparable projects missed their launch dates, the base rate of delay in that group was 10%. It gives you a starting estimate before you examine what is unusual about the next project.
You probably use base rates informally. If a colleague says a routine review will take an afternoon, you may remember that most reviews of this kind took two days. Their explanation for expecting a faster review matters. Knowing the usual duration gives you a better question to ask: “What has changed this time?”
Base rate neglect example: Will this project run late?
Imagine you have records for 100 comparable project launches. In each record, a warning means that a required dependency was unresolved at the final readiness review. A delay means the project missed its agreed launch date. These figures are illustrative.
| Launch outcome | Warning | No warning | Total |
|---|---|---|---|
| Late | 8 | 2 | 10 |
| On time | 12 | 78 | 90 |
| Total | 20 | 80 | 100 |
How well did the warning catch delays? Start with the 10 late projects. Eight had a warning, so it caught 8 out of 10 delays, or 80%. That answers a question about the warning’s past performance.
How often did a flagged project actually run late? Start with all 20 flagged projects. Eight ran late and 12 finished on time. For a project like yours that has triggered the warning, the historical estimate is 8 out of 20, or 40%.
The base rate matters because on-time projects were much more common: 90 finished on time and only 10 ran late. Even though the warning appeared in just 12 of those 90 on-time projects, those 12 outnumbered the 8 flagged projects that ran late. Focusing only on how often the warning caught a delay hides that part of the picture.
The warning raises your estimate from 10% to 40%. That is a meaningful change, even though most flagged projects still finished on time. A delivery lead could reasonably check the dependency today and prepare a fallback. Moving the launch date would take more evidence, such as confirmation that the dependency owner cannot deliver in time.
How do you choose a useful base rate?
Start with the decision you need to make. To estimate whether a software release will miss its committed date, look for earlier releases with a similar approval process, dependency structure, and definition of “late.” A record that measures delays against a revised date answers a different question from one that uses the original commitment.
There is a trade-off. A company-wide archive gives you more observations but may mix routine updates with first-time migrations. A group limited to migrations by your own team may contain just three projects. Write down both counts when the choice matters. “One of three migrations ran late” lets a reader see how little evidence sits behind an estimate of 33%.
Choose the comparison group using facts you knew before the outcome. If you narrow it only after seeing which cases support your hunch, you can make almost any prediction look reasonable.
How does base rate neglect relate to the representativeness heuristic?
Imagine interviewing a candidate who explains a difficult client decision just as your strongest account manager would. The resemblance gives you a promising hypothesis about the candidate. You can test it with a second, unfamiliar scenario.
The representativeness heuristic describes judging by resemblance. Base rate neglect can enter when that resemblance dominates your forecast and you overlook how often candidates with comparable interview scores actually succeeded in the role. The two ideas overlap, but they answer different questions: what made this candidate seem promising, and what evidence belongs in your estimate?
Four questions to avoid base rate neglect
- What outcome am I predicting? Write down an observable result and a time frame. “Miss the November launch date” is specific enough to check.
- How often did it happen in comparable cases? Record the numerator and denominator. Ten delays in 100 launches tells you more than the phrase “delays happen.”
- How often did this cue appear when the outcome did not happen? Count the on-time launches that also triggered a warning. Those cases belong in your estimate for a flagged project.
- What estimate and action does the evidence support now? Decide what you will check, when you will act, and what new information could change your mind.
A decision journal helps you keep the original estimate available for review. A short entry is enough:
Before the warning, I estimated a 10% chance of missing the launch date. In similar launches with this warning, 8 of 20 ran late, so my estimate is now about 40%. I’ll ask the dependency owner about the recovery plan today and revisit the estimate on Friday.
Common questions about base rate neglect
What if I don’t know the base rate?
Look for the nearest comparison group you can defend, and say how it differs from your case. If the only records cover routine releases and yours is a first-time migration, label the routine-release figure as a rough starting point. When no group is credible, record the uncertainty and identify one piece of information that would improve the decision. An invented percentage adds little.
When should specific evidence outweigh the base rate?
Give a detail more weight when there is a clear reason it changes the outcome. An unresolved dependency raises risk. A written confirmation that a mandatory component will arrive after launch, with no available substitute, changes what is feasible. The old 10% estimate described launches before you knew that fact.
The next time a detail changes your mind, write down the estimate you started with and what moved it. When the outcome arrives, you can examine how much the cue deserved to count.
Research and further reading
Maya Bar-Hillel studied how people judge the relevance of background rates and details about an individual case. Her paper provides the research basis for the definition used here. The base-rate fallacy in probability judgments (1980).