Psychology & Behavior
ProPlanning Fallacy Check
規劃謬誤檢查 · Source: Daniel Kahneman / Amos Tversky
Counteracting systematic over-optimism when estimating time, cost, and resources
Core Concept
When planning future projects, people almost universally underestimate time, cost, and difficulty while overestimating completion probability. This isn't a personal flaw — it's a built-in cognitive bias. The antidote is the "outside view": look at statistical outcomes of similar past projects rather than the internal details of this one.
✓ When to use this
When estimating project completion time, launch dates, time-to-profitability. Humans systematically underestimate time and cost — especially when enthusiastic about the plan, this check should be forced.
✗ When not to use this
Highly standardized work with reliable historical timelines (production lines, packaged services) does not need this check. Also do not use it to rationalize over-pessimism — inflated estimates harm equally.
Questions you will be asked
Using this framework, you will work through —
- 1.What is your plan or commitment? What are your original time and cost estimates?
- 2.What historical data from similar projects can you find? What were their actual outcomes?
- 3.Based on this external data, what would be a more realistic estimate?
- …and 3 more
Worked example
Expand to see what a filled-in run looks like
›
Worked example
Expand to see what a filled-in run looks like
Situation
估自己「3 個月內把新產品 MVP 做完上線」，準備跟投資人 pitch 這個時程。團隊 4 人。
1. What is your plan or commitment? What are your original time and cost estimates?
估 MVP 開發時間：3 個月。
2. What historical data from similar projects can you find? What were their actual outcomes?
我假設一切順利、團隊全速、沒有 spec 改動、無人請假、API 沒問題、QA 一次通過。
3. Based on this external data, what would be a more realistic estimate?
過去 3 個 project 我估的時間：6 週/8 週/10 週，實際完成：12 週/14 週/18 週。平均偏差 70%。
4. Which parts of your plan are most likely to experience delays or cost overruns?
可能讓進度延後的具體原因：第三方 API 改版（過去 6 個月已經改 2 次）、QA 來回 2–3 輪、設計師會接其他案子、年中有 2 週連假。
5. How will you adjust your plan to build in sufficient buffers?
用外部視角校正：我抓 3 個月，歷史偏差 70%，意味實際大概 5 個月；加上具體可預見的延誤再 +0.5 個月，誠實估計約 5.5 個月。
6. Based on the adjusted estimates, is this plan still worth pursuing? Does the commitment need renegotiating?
對外承諾「6 個月內 MVP 上線」（含 buffer），對內目標 4.5 個月衝。寫下 milestone 在 2 個月時做 checkpoint。
Use it inside ChatGPT / Claude
Paste the prompt below and the AI will walk you through this framework, one question at a time.
你現在是引導使用者做「規劃謬誤檢查」的教練（Kahneman / Tversky）。 依序問： 1) 你估的時程或預算是什麼？ 2) 你的估計假設了什麼順利情境？（坦白回答） 3) 過去類似 project 你估了多久、實際多久？平均偏差多少？ 4) 寫下至少 3 個可能讓進度延誤的具體原因——它們在過去 6–12 個月發生過嗎？ 5) 用歷史偏差比例校正：原估 × (1 + 平均偏差 %)，再加上可預見的具體延誤。 6) 你的修正版估計是什麼？對外承諾要不要再加 buffer？ 提醒：知道有規劃謬誤不會讓你免疫——必須強制用歷史資料校正。 互動規則： 1. 一次只問一題，等使用者回答後再進入下一題。 2. 使用者答完所有題目前，不要做總結或下結論。 3. 若答案太抽象、太籠統，請追問一次具體例子或數字後再繼續。 4. 全部答完後，輸出三段：(a) 摘要使用者的關鍵判斷；(b) 你看到的盲點或張力；(c) 一個具體下一步行動建議。 5. 不要替使用者做決定，只把判斷攤開讓他自己決定。
Related Frameworks
Psychology & Behavior
Inside View vs Outside View
Planning and forecasting — especially when you're overly optimistic about your own project, goals, or capabilities
Psychology & Behavior
Base Rate Forecasting
Decisions requiring outcome forecasts — from startup success rates to investment returns, start by asking "how does this type of thing typically go"
Management & Thinking
Pre-mortem
Stress-testing a plan before committing — finding failure paths you haven't seen yet
FAQ
How does the planning fallacy check relate to base rate forecasting?
The planning fallacy check's core remedy is exactly base rate forecasting / the outside view: instead of looking at the plan's internal details, look at how long and how much similar plans actually took. It's essentially base rate forecasting applied to the specific domain of time and cost estimation.
I already added a buffer and still ran over — now what?
Because even your deliberately "realistic" estimate still underestimates — research confirms this repeatedly. Switch to the outside view: start from how long similar projects actually took, rather than padding your internal estimate. And decompose the project into chunks, estimate each independently, then sum; estimating the whole at once is almost always more optimistic.
How much buffer should I actually add?
Add 50% by default; 100% for novel or highly uncertain projects. A more reliable method is a correction factor — track the "actual ÷ estimated" ratio from your past similar projects and scale this estimate by that ratio, rather than picking a comfortable-sounding number by feel.
Related studies