Project managers live by estimates. We estimate timelines, budgets, resource needs—and then we wonder why reality keeps hitting our forecasts. A recent analysis of project planning pitfalls explores why our brains systematically miscalculate success probabilities, and what we can do about it.
According to research on judgment under uncertainty, two structural patterns explain much of the gap between planned and actual outcomes: conjunctive chains and disjunctive funnels. Understanding these patterns won't make you psychic, but it will help you stop setting your teams up to fail.
The Chain Problem: Why Multiple Dependencies Kill Your Schedule
Conjunctive events work like chains. Every link must succeed for the whole thing to work. You might estimate one task with high confidence. Fine. But chain several such tasks together, and your actual probability of completing the entire sequence drops far more than intuition suggests.
The math is straightforward: multiply the probabilities. With a chain of independent tasks where each has the same success rate, the combined probability shrinks geometrically. As the reference analysis notes, seven tasks each running at roughly nine-in-ten confidence yields less than one chance in two that the full chain succeeds.
Most planners see multiple high-confidence tasks and mentally file that as "pretty likely to succeed." It isn't. The research on heuristics and biases shows we consistently underestimate how quickly confidence erodes across sequential dependencies.
Quick take:
- Multiple tasks with strong individual confidence yield much lower overall confidence when chained together
- Each additional dependency multiplies your failure risk, not adds to it
- The longer your critical path, the more your estimate drifts from reality
The Funnel Problem: Why Any Single Failure Tanks the Project
Disjunctive events work differently. Think of items falling through a funnel. If any one fails, the outcome fails. The reference analysis examines a funnel with multiple objects, each carrying a roughly nine-in-ten chance of success against a one-in-ten chance of failure. The finding: the probability of at least one failure among those objects is better than one in three.
That means more than a third of such systems will break down due to a single point of failure. In project terms: if you have several dependencies that could derail your delivery, assume one will. Plan accordingly.
The Anchor Problem: Where Estimates Go Astray
Anchoring bias adds another layer of distortion. We fixate on initial numbers—a deadline suggested in a meeting, a budget figure from leadership, a velocity average from last quarter—and fail to adjust far enough from that anchor.
In sales, anchoring works for the seller. In project planning, it works against you. The sponsor anchors on a budget. The team anchors on an optimistic timeline. Nobody adjusts far enough because the anchor feels authoritative.
The result: estimates that look reasonable in isolation but crumble when stacked against real-world probability distributions.
Our analysis
Why does this persist? Because chain and funnel logic feels unnatural. We reason one task at a time, not across entire sequences. We treat dependencies as roughly independent when they're actually multiplicative. And we confuse "this task has strong confidence" with "our project has strong confidence."
Senior practitioners often know this intellectually but still build schedules that assume everything goes right. We pad estimates a bit, but rarely enough to account for geometric degradation across a lengthy critical path.
The real cost isn't just missed deadlines. It's the trust erosion when teams repeatedly fall short of commitments they never had a realistic chance of hitting.
A practical scenario
Say you're planning a product launch with four major phases: design, development, testing, and deployment. Your "total confidence" might feel roughly equivalent to a single task's confidence. Reality: each phase multiplies your cumulative risk. If any one slips, the whole launch shifts.
Better approach: build your schedule with explicit buffer for chain degradation. If your critical path has multiple sequential dependencies, assume you'll lose a meaningful portion of your schedule to chain failures. That's not pessimism; it's calibrated realism. Rather than padding a single number at the end, front-load your contingency thinking by examining how each phase's risk compounds across the full path.
What to watch next
The bias patterns here are well-documented but rarely operationalized in project tooling. Spreadsheet-based schedules almost never show cumulative probability. If your planning tools don't surface these calculations, demand them—or build the discipline into your estimation process manually. Your sprint planning and stakeholder commitments will be better for it.
Bottom line: Stop estimating tasks and start estimating sequences. The math hurts at first, but your credibility will recover.
Key takeaways
- Multiply probabilities across sequential dependencies, don't average them
- Assume at least one component will fail in parallel dependency structures
- Anchor adjustments require deliberate effort—default human adjustment is insufficient
- Build buffers that account for geometric probability degradation
Frequently asked questions
Why do project estimates feel accurate when they're often wrong?
Because we evaluate each task in isolation rather than calculating cumulative probability across the full sequence. Individual high-confidence tasks feel safe; several of them together can yield low overall confidence.
What's the difference between conjunctive and disjunctive events?
Conjunctive events (chains) require all links to succeed—failure is multiplicative. Disjunctive events (funnels) fail if any single element fails—any one failure cascades to the whole system.
How does anchoring bias specifically affect project planning?
Initial numbers—budget figures, deadline suggestions, past velocity—become mental anchors. We adjust from them insufficiently, leading to systematically optimistic estimates that don't reflect actual probability distributions.
Can experience override these biases?
Not naturally. Domain experts often fail to apply probabilistic reasoning even when they understand it intellectually. The fix is structural: use formal estimation techniques that force cumulative probability calculations rather than relying on intuition.
What practical buffers should project managers use?
For critical paths with multiple sequential dependencies carrying strong individual confidence, build meaningful schedule buffer rather than minimal padding. Accept that estimates even with typical buffers are still likely optimistic.