The Optimism Trap: Why Your Timelines Are Always Wrong
We are wired to expect the best. That wiring routinely wrecks our schedules.
Psychologists Daniel Kahneman and Amos Tversky identified what they called the planning fallacy in 1979: the consistent tendency to underestimate the time, costs, and risks of future actions while overestimating the benefits. Decades of research since then have confirmed this bias, which appears across industries, cultures, and experience levels. It affects students' estimates of homework, executives' forecasts of product launches, and seasoned project managers' commitments to milestones.
The pattern is stubborn. We, collectively, imagine a "best-case scenario" where traffic is light, dependencies arrive on time, nothing breaks, and everyone stays focused (ohh, look, a squirrel…). We treat that scenario as the baseline, then act surprised when reality intrudes.
For project managers, this is not a curiosity. It is the root cause of countless late deliveries, burned-out teams, and damaged credibility. If you want to lead wisely, you must confront your own optimism before it misleads your stakeholders.
Why We Keep Falling for It
Kahneman's research shows that people rely heavily on their present emotional state when predicting future outcomes. Because we imagine the future while feeling calm, focused, and energized in the present, we systematically underestimate obstacles, delays, and fatigue. We also tend to ignore past delays. Somehow, the memory of the last three assignments, each taking longer than expected, does not stop us from believing this time will be different.
Oxford professor Bent Flyvbjerg has termed a related phenomenon "strategic misrepresentation": the planned, systematic misstatement of costs and schedules to secure project approval 1. Sometimes the optimism is innocent self-deception. Sometimes it's political pressure. Either way, the outcome is the same: plans that assume everything will go right.
This connects directly to what we explored last week in the pre-mortem exercise. The pre-mortem asks, "What could go wrong?" The optimism bias exercise asks, "Where am I assuming everything goes right, and why?"
Seneca captured this tension two thousand years ago:
“We suffer more often in imagination than in reality.”
In the journal's Week 4 prompt, I apply his insight this way: We often imagine things will go smoother than reality permits. The Stoic move is not to become a pessimist but to see reality without wishful thinking. That clarity is the foundation of wisdom.
The Stoic Case for Honest Estimates
When you give an optimistic estimate that you suspect is unlikely, you are not being collaborative. You are trading short-term comfort ("don't worry, we got this") for long-term pain (reputation burned). The sponsor smiles today; the team works weekends in month three.
The journal's Week 4 reflective prompt asks a pointed question: Why do you hesitate to give realistic, longer estimates? Is it fear of disapproval? A desire to please?
For most of us, the honest answer is yes. We want to be seen as capable, positive, and team-oriented. Saying "this will take eight weeks, not four" can feel like admitting weakness. Besides, don't all project managers do this? No. Not the good one, at least.
The Stoic response flips that frame. Giving an accurate estimate is not a weakness. It is an act of courage and justice. Courage because it risks the sponsor's displeasure in the service of the truth. Justice because it protects your team (my personal number one rule) from exploitation and your stakeholders from nasty surprises.
Think of it through the dichotomy of control (Week 1). You do not control whether the stakeholder likes your estimate. You do control whether you tell the truth. Your duty is to the second.
A Case Study: The Overconfident Sprint
Let me give you a scenario that plays out in agile shops every two weeks.
A Scrum team is committed to 10 user stories for this current sprint, "because we did 10 last sprint." Velocity says 10, so 10 it is. The planning session took 20 minutes, everyone nodded, and the sprint started.
What they ignored:
- Two of this sprint's stories were larger and more ambiguous than anything in the last sprint.
- A critical hardware dependency on the platform team, which was itself underwater. (Enter the truth of RAM costs today!)
- The senior developer was taking three days off mid-sprint.
By day seven, reality set in. Stories piled up. The team worked late. The demo was thin. Morale dropped.
This happens because the team planned for best-case conditions and treated optimism as a baseline. In Stoic terms, they confused hope with judgment.
A Stoic PM would have interrupted the planning session:
"Let's do three-point estimates on the big stories. What's the optimistic case, realistic case, and pessimistic case? And let's explicitly name that dependency and the PTO before we commit." [I saw in my first draft that I wrote vomit instead of commit, which may have actually worked.]
The result would likely have been eight stories, not ten, and a sprint that actually closed cleanly. Fewer heroics, more trust.
A Practical Framework: The Three-Point Estimate
Three-point estimating has been part of the PM toolkit for decades, but optimism bias often leads us to skip it or phone it in. Here is how to use it with discipline:
For any significant task or milestone, require your team to provide three numbers:
- Optimistic (O): Best case if everything goes smoothly, no surprises, full focus.
- Most Likely (M): Realistic case accounting for normal friction.
- Pessimistic (P): Worst reasonable case if several things go sideways.
The classic Program Evaluation and Review Technique (PERT) formula weights these:
Expected Duration = (O + 4M + P) / 6
For a task where the team says:
- Optimistic: 4 weeks
- Most Likely: 6 weeks
- Pessimistic: 10 weeks
The PERT expected duration is (4 + 24 + 10) / 6 = 6.3 weeks.
But the formula is not the point. The conversation, that is, the exchange of words, is the point. When you force the team to articulate the pessimistic case out loud, you surface hidden risks. When you present the range to stakeholders, you shift the dialogue from "when will it be done?" to "what range are we managing within?"
That shift is both practical and Stoic. You stop pretending certainty you do not have. You prepare everyone for what might actually happen.
How to Run This With Your Team
You can apply three-point thinking in a 15-minute segment of your next planning session.
Step 1: Pick the milestone or deliverable that matters most. Usually, this is the next major commitment visible to leadership.
Step 2: Ask for three estimates. Have each contributor write their O, M, and P silently first. Then share. The silent writing surfaces disagreement you would not hear in a free-for-all discussion.
Step 3: Explore the gaps. If one person says "Pessimistic: 6 weeks" and another says "Pessimistic: 12 weeks," you have just found hidden risk or hidden assumptions. Talk about it.
Step 4: Choose your planning baseline. Unless you have a compelling reason to bet on the optimistic case (spoiler: you rarely do), anchor your commitment to the realistic or pessimistic range.
Step 5: Communicate the range, not the point. When you talk to your sponsor, say something like:
“The optimistic case is four weeks if everything goes right. The realistic range is six to eight weeks. We are planning for eight and will celebrate if we land sooner.”
That language does several things at once. It signals competence (i.e., that you have considered uncertainty). It sets expectations honestly. And it gives you credibility when, inevitably, one of the "eight-week risks" materializes.
The Language of Stoic Estimates
Framing matters. When you deliver a longer estimate, avoid defensive language (" Well, I guess it might take..."). Instead, speak with calm authority:
- "To ensure quality and account for the unknowns, we are targeting May 15, not May 1."
- "Based on historical data and known dependencies, I/we recommend planning for the realistic range."
- "Here is what would have to go perfectly for the optimistic case to hold. I/we do not recommend betting on it."
Notice the pattern: you are not apologizing. You are explaining. The Stoic PM treats honesty as a service, not a confession. As for the I/we, it's situation-dependent on what you use. I've been in situations where I was asked who's in charge. Several years ago, it was "me." Today, I consider Waterfall, Hybrid, Agile, and Scrum to be 100% team sports.
What You Control (And What You Do Not)
Apply the dichotomy of control to this exercise:
What you control:
- Whether you ask for three-point estimates
- Whether you communicate ranges rather than single points
- Whether you build buffers into the schedule and explain them transparently
- Whether you push back on unrealistic pressure with data and calm clarity
What you do not control:
- Whether the sponsor likes the estimate
- Whether leadership overrides your recommendation
- Whether external dependencies slip anyway
- Whether the market changes and renders the timeline moot
Your job is to act on the first list. The second list is fate. A Stoic PM does their duty, communicates the truth, and then releases attachment to whether that truth is welcomed.
Building The Habit
This is not a one-time exercise. Integrate it:
- Add it to sprint planning. For any story above a certain size, require O/M/P estimates before commitment.
- Add it to phase gates. Before moving from planning to execution, revisit the schedule with a fresh three-point analysis.
- Add it to your own weekly review. Ask yourself: Where am I hoping for the best right now? What does the realistic case actually look like?
- Model it in your own language. Every time you communicate a date, add the qualifier. "We're targeting X, accounting for Y risks."
Over time, this becomes second nature. You stop trafficking in false precision. Your stakeholders begin to trust your forecasts because they come true. 🙌
Your Assignment This Week
Here is your action, straight from Week 4 of the Stoic Project Management Journal:
- Look at your project schedule. Identify the task where you are hoping for the best. Be honest.
- Write down three estimates: Optimistic, Realistic, and Pessimistic.
- Ask yourself the reflective question: Why do you hesitate to give realistic, longer estimates? Is it fear of disapproval? A desire to please?
- Take one action: Add a buffer of reality to one deadline you communicate this week. State clearly: "To ensure quality and account for unknowns, we are targeting [Date]."
- Journal for 5 minutes: How did it feel to speak the realistic number out loud? Did the conversation go better or worse than you feared?
That is it. One milestone. One honest conversation. One small (yet BIG) act of Stoic courage.
A Challenge and An Invitation
The hardest part of beating optimism bias is not intellectual. It is emotional. We want to believe that this time will be different. We want to please. We want to avoid the discomfort of disappointing a sponsor.
The Stoic response? Face reality. Speak truth. Protect your team. And then accept that the reaction is not yours to control.
Seneca again: "We suffer more often in imagination than in reality." The conversation you fear about the longer timeline is almost never as painful as the crisis you will face when the short timeline fails.
Choose the discomfort of honesty now over the chaos of broken promises later. That is the Stoic way to manage estimates.
Call to Action
When you do your three-point estimate this week, what is the gap between your optimistic and realistic numbers?
Share it in the comments. Just the gap and what it taught you about your own bias.
Next week: Learning from History. Why do the same mistakes keep happening on projects, and how can we build a habit of consulting the past?
Ryan Erickson, PMP, veteran, student, father
Learning to lead with wisdom, courage, justice, and temperance, one project at a time.
P.S. If you have a story about a time an honest estimate saved a project (or a time optimism bias burned you), I would love to hear it. Drop a comment. Those real stories are how we all get smarter.
1 https://en.wikipedia.org/wiki/Megaproject
Member discussion