Planning Fallacy

We tend to view past events more positively than we experienced them at the time. This phenomenon can significantly influence our decision-making processes and how we perceive our past experiences. We often look back on previous times with a sense of nostalgia, potentially overlooking the difficulties and challenges we faced during those periods.

But first, let's hear from this week's sponsor...

Now, back to the Planning Fallacy⏬

Why do we keep convincing ourselves that this time the project will be different, when it almost never is?

Several years back, after I finally left advertising, I joined a giant global conglomerate enterprise company. I joined the team about a month or two into a massive software project. And the initiative sounded bold (and it was!): take an old legacy web application used by engineers out in the field and rebuild it as a native iOS app with complete 1:1 feature parity. But here’s the kicker… It was all supposed to be finished in exactly one year.

On my very first day, when someone explained the plan from leadership, my immediate thought was, “There is absolutely no way in hell this will happen! You’re crazy!”

To meet the deadline, the team had implemented a “follow the sun” engineering model. That’s where teams in the U.S., Europe, and Asia are passing code back and forth around the clock. On paper, it looked like a clever way to speed things up. But in practice, it created chaos.

Engineers were constantly inheriting half-finished user stories, spending just as much time cleaning up handoffs as writing new code. Instead of improving efficiency, it magnified the complexity and generally just made it all a giant mess..

The project ultimately failed to meet its one-year deadline, and it took almost another full year before the app was finally shipped. Even then, the scope had been dramatically cut. Feature parity with the old tool didn’t happen until more than a year later.

As a UX designer, I saw this dynamic play out the same way across multiple large enterprise projects. Leadership would set aggressive timelines, often due to shareholder or stock market pressures, and middle managers would frequently nod along—partly out of optimism, partly out of pressure. The people on the ground thought it was nuts. And almost inevitably, deadlines slipped. The Planning Fallacy wasn’t a one-time mistake; it was a recurring pattern embedded in the culture.

​

Would you rather listen? Follow the Cognition Catalog on Spotify!

The Planning Fallacy: Why We... Oct 2 · Beyond UX Design 10:53   ​

---

The Planning Fallacy was first introduced by psychologists Daniel Kahneman and Amos Tversky in 1979. Their research revealed a consistent human tendency: when predicting the duration of future tasks, individuals often imagine a best-case scenario rather than relying on realistic averages from prior experiences. Even experts and professionals who have managed similar projects tend to fall into this trap. This demonstrates how deeply ingrained the bias is.

One of the most well-known case studies of this bias is the Sydney Opera House project. Originally estimated to take about four years and cost $7 million AUD, the project ballooned into a 14-year construction project costing more than $100 million AUD. Despite clear evidence of delays and rising costs, decision-makers repeatedly relied on overly optimistic projections. This famous example highlights how optimism, group pressure, and political motivations can collectively reinforce the Planning Fallacy on a large scale.

More studies have shown that we don’t fall for the Planning Fallacy simply because we’re overly optimistic. We often fall for the planning fallacy because we don’t consider “outside views.” Kahneman later stressed the importance of what he called reference-class forecasting, which means comparing current projects to historical data from similar reference classes. And yet, even with an awareness of the bias, we tend to continue to fall for it. And that’s often because focusing on potential setbacks feels discouraging or less motivating.

For teams, the Planning Fallacy can have serious consequences.

At a leadership level, the Planning Fallacy can warp strategic decision-making. Executives may greenlight initiatives with aggressive schedules to please the board or investors, knowing deep down that the estimates are entirely unrealistic. Over time, this erodes morale within teams, who end up seeing leadership and their timelines as detached from reality.

Product teams may agree to leadership’s unrealistic goals, thinking it’s possible. Engineers may underestimate complexity, and designers may believe they can finish more research and design iterations than time allows. These overly optimistic estimates not only create stress and burnout, but they can also damage credibility with important stakeholders and customers when deadlines are missed.

For agile teams, the Planning Fallacy often shows up in sprint planning. Teams may load their backlog with more work than they can realistically accomplish, because they’re under pressure to show progress. While the intention is positive—we think it demonstrates ambition and efficiency—the result is often incomplete tasks, stories rolling over to the next sprint, and growing frustration. This ultimately undermines trust in the planning process itself.

The bias also affects cross-functional collaboration. For example, engineers might promise delivery based on their portion of the work, forgetting to account for QA, acceptance testing, or unforeseen integration and deployment hurdles. Marketing teams might plan product launches without considering the inevitable technical delays. When each function underestimates in isolation, the collective outcome becomes even more unrealistic.

---

🎯 Here are some key takeaways

1️⃣ Recognize our bias for optimism: We naturally picture the best-case scenario when estimating, even when past evidence suggests otherwise. Naming it creates awareness that can reduce overconfidence.

2️⃣ Adopt an outside view: Instead of relying only on your gut, compare your current project to historic data from similar projects. This “reference class forecasting” approach grounds estimates in reality instead of wishful thinking.

3️⃣ Add intentional buffers: Building contingency time into your plan isn’t a weakness, it’s a safeguard. Unexpected delays are the norm. Increasing estimates or adding margin may feel conservative, but it reduces the risk of missed deadlines and credibility loss.

4️⃣ Make estimation collaborative: Involve x-functional teams when estimating. Eng, designers, QA, and marketing all have blind spots when working in isolation. A shared view reduces surprises and helps align expectations across functions.

5️⃣ Track outcomes and learn: Keep a record of your original estimates and compare them with actual delivery times. Reviewing mismatches over time reveals recurring patterns and helps teams improve forecasting accuracy. Turn mistakes into learning opportunities.

Learn more about the Planning Fallacy!

---

---

---

---

---