Planning Fallacy Examples: 10 Everyday Cases (and the Fix for Each)

You said the email would take five minutes. It took forty. You said you would leave the house at 8:15. You left at 8:32. You said the kitchen renovation would be done by spring. It is autumn.

None of this is a character flaw. It is one of the most reliable patterns in human judgment, and it has a name: the planning fallacy. The concept is easier to spot once you have seen enough planning fallacy examples side by side, because the same mistake shows up whether the project costs a hundred million dollars or ten minutes of your morning.

This article walks through ten planning fallacy examples, from famous public projects to small daily ones, and pairs each with the fix that would have caught it. If you want the theory and the full list of strategies, start with the planning fallacy guide. This page is the casebook.

What the Planning Fallacy Actually Is

Psychologists Daniel Kahneman and Amos Tversky described the planning fallacy in 1979: people underestimate how long their own tasks will take, even when they know that similar tasks took longer in the past.

The key word is "even". It is not that people lack information. It is that, when planning, we picture the best-case version of this specific task and ignore what usually happens. Researchers call this the "inside view": you look at the steps you can imagine and add them up. The "outside view" asks a different question: how long did things like this take, the last several times?

Every example below is a version of the same gap between those two views.

Big, Famous Planning Fallacy Examples

1. The Sydney Opera House

The textbook case. When construction was approved, the building was expected to open in 1963 at a cost of roughly 7 million Australian dollars. It opened in 1973, scaled down from the original design, at around 102 million.

What went wrong: the design was unprecedented. Nobody had built those shells before, so every estimate came from the inside view of a plan, not from comparable projects.

The fix: when a project has no close precedent, treat the estimate as a guess and budget a large buffer on purpose. Novelty is a warning sign, not a detail.

2. Kahneman's Own Textbook

Kahneman tells this story about himself. He led a team writing a decision-making curriculum. After a year of good progress, he asked everyone to estimate how long the rest would take. The answers clustered around two more years.

Then he asked a colleague who had seen many similar projects how long they usually took. The answer: around seven to ten years, and a large share never finished. The team finished about eight years later.

What went wrong: the people who knew the base rate did not apply it to their own project. Their inside view felt more relevant than the statistics.

The fix: before you estimate, ask "how long did the last three projects like this take?" Write that number down first, then adjust.

3. Berlin Brandenburg Airport

Planned to open in 2011. It opened in October 2020, after years of fire-safety, design and construction problems.

What went wrong: large projects are chains of dependencies. One failed system (in this case, fire protection) can stall everything behind it.

The fix: identify the parts that block everything else and estimate those with the most pessimism. A single bottleneck sets the timeline.

Everyday Planning Fallacy Examples

The famous cases get the headlines, but the planning fallacy costs most people far more in small daily misses.

4. The Five-Minute Email

You open your inbox to send one quick reply. You need to find an attachment, check a detail with a colleague, rewrite the second paragraph because the tone is off, and answer the two messages that arrived while you were doing that.

What went wrong: you estimated the typing. You did not estimate the finding, checking and deciding, which is where the time goes.

The fix: estimate the whole task, not the visible part. A useful rule of thumb is that "quick" admin tasks take three times your first guess.

5. Leaving the House on Time

You plan to leave at 8:15 because the drive takes 20 minutes. You forget that finding your keys, filling a water bottle, a last bathroom trip and walking to the car add 10 to 15 minutes before the clock you planned around even starts.

What went wrong: the transition time between tasks is invisible when planning.

The fix: plan backwards from the arrival time, and add a fixed buffer for "getting out the door". Time it once for a week; the real number is rarely what you think.

6. The Student Thesis

This one comes from research. In a well-known study by Roger Buehler and colleagues, students estimated when they would finish their honours thesis. The average prediction was about 34 days. The average actual time was about 55 days. Even their "worst case" estimates were too optimistic for most of them.

What went wrong: the students imagined how the project would go if things went to plan, and almost nothing goes to plan for weeks at a time.

The fix: ask for a worst-case estimate, then assume reality will be worse than that. It sounds pessimistic. It is usually just accurate.

7. Cooking a "30-Minute" Dinner

The recipe says 30 minutes. It does not count washing the pan you need, chopping more slowly than a chef does, or the 10 minutes the oven takes to heat.

What went wrong: you borrowed someone else's estimate made under ideal conditions.

The fix: time your own version once. Your personal number beats any published one, because it includes your kitchen and your speed.

8. Weekend Home Projects

Paint the spare room on Saturday. It needs two trips to the hardware store, a second coat, and the cleanup takes the rest of the afternoon. Sunday disappears too.

What went wrong: home projects hide setup and cleanup at both ends, and they often reveal problems once you start (the wall needs filling, the tape pulls paint off).

The fix: split the estimate into setup, work, and cleanup, and double the setup. Expect one surprise and leave room for it.

9. "I'll Finish This Report Tonight"

The report is "almost done" at 7 PM. At 11 PM, you are still reformatting tables and chasing one missing number.

What went wrong: the last stretch of a project is the part we underestimate most. There is even a name for it, the ninety-ninety rule: the first 90 percent of the work takes 90 percent of the time, and the last 10 percent takes the other 90 percent. We wrote a whole piece on why projects stall at 90 percent.

The fix: list every remaining step before you estimate the finish. "Almost done" is a feeling. A written list of what is left is a plan.

10. The Packed Day

You put eight tasks on today's list. Each estimate feels reasonable on its own. Together they add up to eleven hours, and that is before lunch, messages and interruptions.

What went wrong: single-task estimates are each a little optimistic, and the errors stack. Nobody plans for the interruptions that always come.

The fix: plan only 60 to 70 percent of your available time. The rest is not wasted. It is where the overruns go. Time blocking makes this visible, because a full calendar shows you the day is already overbooked before you start.

The Pattern Behind Every Example

Look back over the ten planning fallacy examples and the same three causes appear:

• Picturing the best case. You imagine the task going smoothly, and the estimate reflects that ideal run.
• Ignoring the edges. Setup, transitions, cleanup and the final 10 percent get left out.
• Skipping your own history. You have done similar things before, but you estimate from scratch.

The fixes follow from those causes. Use the outside view first: ask how long it took last time. Estimate the whole task, edges included. Add a deliberate buffer, larger for anything new. And keep a simple record of estimate versus actual, so next time you have a real number instead of a hopeful one.

Why Some People Are Hit Harder

The planning fallacy is universal, but it lands harder for people who struggle to sense time passing. If you have ADHD, the gap between "this will take a minute" and reality is often wider, partly because of time blindness: the minutes spent on a task do not register the way they do for others.

For that kind of brain, external tools beat good intentions. A visible timer, a schedule with real blocks, and reminders that check in when a block ends do the job that an internal clock does not. Planning with if-then rules also helps, because it decides in advance what happens when a task runs over.

FAQ

What is a simple example of the planning fallacy? Saying a "quick" email will take five minutes, then spending forty minutes finding attachments, checking details and rewriting it. The typing was estimated correctly. Everything around it was not.

What is the most famous planning fallacy example? The Sydney Opera House is the classic one: expected to open in 1963 for about 7 million Australian dollars, it opened in 1973 for around 102 million.

Is the planning fallacy the same as procrastination? No. Procrastination is delaying a task you know you should do. The planning fallacy is misjudging how long a task will take. They often appear together, because an optimistic estimate makes it feel safe to start late.

How do I stop making the same estimating mistakes? Write down your estimate and the actual time for a week. You will quickly see your personal multiplier, for example "my admin tasks take 2.5 times my first guess", and you can apply it automatically.

Does experience fix the planning fallacy? Only if you use it. Experienced people make the same error when they estimate from the inside view. Experience helps when you deliberately ask how long similar work took before.

The Takeaway

The planning fallacy is not about being bad at planning. It is about planning from the hopeful picture of one task instead of the record of many. Every example here, from an opera house to a weeknight report, fails the same way and can be fixed the same way: look at what usually happens, include the edges, and leave room for the surprise you know is coming.

Pick one thing on today's list, write down how long you think it will take, and time it. That single comparison will teach you more about your own estimates than any rule of thumb.