Planning fallacy की classic study में psychology students से पूछा गया कि वो अपना honors thesis कब जमा करेंगे। उनसे यह भी पूछा गया कि वो उसे कब जमा करेंगे "अगर सब कुछ जितना बुरा हो सकता है उतना बुरा गया।" क़रीब आधे उस worst-case date से भी चूक गए।
आपकी कल्पना का worst case कोई safe date नहीं है।
छोटा जवाब: planning fallacy अपने tasks में लगने वाले समय को underestimate करने की प्रवृत्ति है, तब भी जब आप जानते हैं कि ऐसे tasks पहले late हुए थे। Daniel Kahneman और Amos Tversky ने 1979 में इसे नाम दिया। यह आपके दिमाग़ में बने plan से forecast करने से आती है, न कि इससे कि ऐसे tasks में असल में कितना समय लगा, और एक ऐसी memory से जो past को छोटा कर देती है। Recorded actuals पर बने corrections के पीछे research support है, और यहाँ की recipe उन्हें जोड़ती है: दस tasks log करें, actual और estimate का median ratio लें, और अपने अगले gut estimate को उससे गुणा करें।
Planning fallacy क्या है?
यह आपके अपने काम के forecasts में एक optimistic bias है। आप अगले task के पिछले कुछ tasks से तेज़ होने की उम्मीद करते हैं, जबकि जानते हैं कि पिछले कुछ late हुए थे। Kahneman और Tversky ने 1979 में यह term गढ़ा, और classic 1994 study के lead author Roger Buehler (2019) इसे एक task को underestimate करना बताते हैं — "यह जानते हुए भी कि ऐसे tasks ने past में आमतौर पर उनका कहीं ज़्यादा समय लिया है।"
दो बातें planning fallacy की definition को और sharp करती हैं। पहला, यह आपके अपने tasks की बात है: Buehler, Griffin and Ross (1994) में किसी और का completion time बता रहे observers ने उसे overestimate किया। दूसरा, यह सिर्फ़ megaprojects की curiosity नहीं है। Buehler का summary इसे घर के chores और subway construction दोनों में पाता है, अलग-अलग personality types और cultures में।
एक planning fallacy example: classic study में क्या मिला
औसतन, students को अपने best guess से क़रीब 64% ज़्यादा समय लगा, और क़रीब आधे अपने worst case से भी चूक गए।
Buehler, Griffin and Ross (1994) ने honors-thesis course के आख़िरी semester में 37 students को फ़ोन किया। उन 33 में से जिन्होंने तब submit किया जब researchers records रख रहे थे, average best guess 33.9 दिन था। Average actual 55.5 था। उनका best-case guess औसतन 27.4 दिन था। उनका worst case औसतन 48.6, क़रीब एक हफ़्ता जल्दी, हालाँकि वो gap statistically significant नहीं था। सिर्फ़ 29.7% अपने best estimate तक ख़त्म कर पाए।
उस paper के दो और results problem को fix करने के लिए headline से ज़्यादा मायने रखते हैं।
Estimates noise नहीं थे। Predicted और actual times का correlation r = .77 था। जिन students ने ज़्यादा समय लगने की उम्मीद की, उनका सच में ज़्यादा समय लगा। Guesses में असली information थी — वो shifted थे, random नहीं — और यही चीज़ correction factor को मुमकिन बनाती है।
Past याद करना काफ़ी नहीं था। Study 4 में 123 students ने क़रीब एक घंटे के computer assignment को ख़त्म करने का समय बताया। पहले पुराने assignments याद करने से कोई significant फ़र्क़ नहीं पड़ा: 38.1% ने अपनी prediction तक ख़त्म किया, control group के 29.3% के मुक़ाबले।
जिन students को उन यादों को नए task से जोड़ने की प्रक्रिया से गुज़ारा गया — यह task आपकी आम assignments जैसा चला तो कब ख़त्म होगा? — वो 60.0% तक पहुँचे, और उनकी average prediction (7.0 दिन) उनकी average finish (7.0) से मेल खाई। Authors फिर भी उन predictions को absolute terms में "ज़्यादा accurate नहीं" कहते हैं। Average हिला। Scatter नहीं।
Kahneman Kahneman and Lovallo (1993) में अपने career की एक कहानी बताते हैं। उनकी team Israeli high schools के लिए decision-making curriculum लिख रही थी। काग़ज़ की पर्चियों पर members ने finished draft तक 18 से 30 महीने का estimate लगाया। फिर उन्होंने team के curriculum expert से पूछा कि ऐसी teams का क्या हाल रहा: क़रीब 40% कभी ख़त्म नहीं कर पाईं, और बाक़ी में से किसी को सात साल से कम नहीं लगा। यह team क़रीब आठ साल बाद ख़त्म कर पाई।
Hofstadter's law: planning fallacy, recursively
Hofstadter's law Douglas Hofstadter की Gödel, Escher, Bach (1979) से आती है, recursive structures और processes वाले chapter में: "इसमें हमेशा आपकी उम्मीद से ज़्यादा वक़्त लगता है, तब भी जब आप Hofstadter's Law को ध्यान में रखते हों।" मौक़ा था computer chess। लोगों ने computer world champion को दस साल दूर बताया था, और दस साल बाद भी वो दस साल से ज़्यादा दूर लग रहा था।
यह recursion पर एक joke जैसा पढ़ा जाता है, और thesis का data उस पर फ़िट बैठता है: जिन्हें सब कुछ ग़लत होने की कल्पना करने को कहा गया, वो students भी क़रीब आधी बार उस date से चूके। Feel से padding करना कमज़ोर रास्ता है, क्योंकि padding उसी inside view से आती है जिसने estimate बनाया था। आप Hofstadter's law को सोचकर नहीं हरा सकते। आप correction का अंदाज़ा लगाना बंद करके उसे measure कर सकते हैं।
ऐसा क्यों होता है
ज़्यादातर इसलिए कि आप history से नहीं, plan से forecast करते हैं, और वैसे भी जो history आपको याद है वो बहुत छोटी है।
आप inside से plan बनाते हैं। Kahneman and Lovallo (1993) forecast करने के दो तरीक़े अलग करते हैं। Inside view आपके सामने वाले plan से एक scenario बनाती है। Outside view details को नज़रअंदाज़ करके पूछती है कि ऐसे cases का नतीजा कैसा रहा। लोगों का default पहला ही होता है: Buehler की think-aloud study में prediction करते वक़्त students ने जो कहा उसका 74% इस बारे में था कि task कैसे चलेगा, और 7% relevant past experience के बारे में।
आप past को बहानों से टाल देते हैं। उन्हीं students ने अपनी past की चूक को "काफ़ी हद तक external, transient और specific factors" पर डाला। पिछली बार flu हो गया था। इस बार नहीं होगा।
आपकी memory past को छोटा कर देती है। Roy, Christenfeld and McKenzie (2005) ने duration research को review किया और एक memory-based explanation दिया: "लोग future events की duration को इसलिए underestimate करते हैं क्योंकि वो past events की duration को underestimate करते हैं।" अगर वो सही हैं, तो यह असहज करने वाली बात है, क्योंकि memory से बनी एक ईमानदार outside view भी वही bias inherit करती है। मैंने इसे अपने 30-दिन के time audit में देखा, जहाँ 15 मिनट की याद रहीं meetings बार-बार 40 मिनट की निकलीं।
आप वही projects शुरू करते हैं जो आसान लगते हैं। Halkjelsvik and Jørgensen (2018) बताते हैं कि optimistic estimate आपको task शुरू करने की ज़्यादा संभावना देता है, और आप सिर्फ़ उन्हीं tasks पर सीख पाते हैं कि कितने ग़लत थे, जो आपने शुरू कीं। Durations right-skewed भी होती हैं: 2-घंटे का task छह घंटे ज़्यादा ले सकता है, छह कम कभी नहीं। आपकी याददाश्त पर overruns का ही ज़ोर रहता है।
यह universal नहीं है। छोटे tasks अक्सर उल्टा चलते हैं। Roy के review में क़रीब 5 मिनट से कम के tasks के overestimate होने की संभावना ज़्यादा मिली। Halkjelsvik and Jørgensen के review में छोटे software tasks unbiased या बल्कि pessimistic मिले, जबकि कम से कम 100 work hours वाले projects में क़रीब 20% का median overrun दिखा। यह fallacy ऐसे काम में रहती है जो interruptions इकट्ठा करने जितना लंबा हो।
Planning fallacy को क्या कम करता है
नीचे दी गई studies में, जिन fixes ने estimate में असली past durations को शामिल किया, उन्होंने bias कम किया या accuracy सुधारी। Unpacking, जो बस plan पर और ज़ोर लगाने को कहता है, के results मिले-जुले रहे।
| Method | आपको क्या करना है | Evidence | Catch |
|---|---|---|---|
| Reference-class forecasting | ऐसे past outcomes के spread से forecast करें | बड़े construction projects पर accuracy सुधारता है; personal ones के लिए "इसके ऐसे ही फ़ायदे हो सकते हैं" (Buehler 2019) | Comparable tasks का data चाहिए |
| Past को present से जोड़ें | पूछें कि यह आपकी आम tasks जैसा चला तो कब ख़त्म होगा | On-time share 29% से 60% तक बढ़ा (Buehler 1994, Study 4) | Bias गिरा; absolute error नहीं |
| Unpacking | Subtasks की list बनाएँ, फिर एक total दें | Experiments 3–4 में लंबे estimates, कम biased (Kruger and Evans 2004); checklists use करने वाले projects ने औसतन 10% कम estimate किया, बिना checklist के 38% कम के मुक़ाबले (Halkjelsvik and Jørgensen 2018) | असामान्य रूप से छोटे या देर वाले steps को list करना estimate को घटा सकता है (Hadjichristidis et al. 2014) |
| Memory को measured durations से सुधारें | Estimate करने से पहले देखें कि ऐसे tasks में कितना समय लगा | तीनों experiments में feedback ने accuracy बढ़ाई (Roy, Mitten and Christenfeld 2008) | एक भरोसेमंद record चाहिए |
Buehler पहली row की individuals के लिए क़ीमत को लेकर साफ़गो हैं: पूरी procedure "subway builders के लिए subway sandwich makers से ज़्यादा काम की हो सकती है।" अगला section sandwich-maker version है।
Estimate vs actual: 10 tasks में personal reference-class forecasting
Flyvbjerg (2006) reference-class forecasting को तीन steps में रखते हैं। ये एक इंसान और एक spreadsheet तक सिमट जाते हैं:
- Class चुनें। एक तरह और क़रीब-क़रीब एक size के tasks, मान लीजिए development tasks जिनका estimate आपने 1 से 8 hours लगाया। Flyvbjerg का test: "इतनी broad कि statistically meaningful हो, पर इतनी narrow कि सचमुच comparable हो।"
- Distribution बनाएँ। हर finished task के लिए actual को estimate से भाग दें। Kahneman and Lovallo (1993) इस तरह के actual-to-planned ratio की सलाह देते हैं क्योंकि यह "अलग-अलग projects के बीच meaningful comparisons की इजाज़त देता है।"
- नए task को रखें। अपने gut estimate को अपनी ज़रूरत की confidence वाले ratio से गुणा करें।
Free estimate vs actual tool में built-in दस demo tasks का हिसाब यह है। इसे दोहराने के लिए "or load 10 demo tasks" पर click करें। ये बनाए हुए developer tasks हैं, किसी का असली log नहीं।
| Task | Estimate (h) | Actual (h) | Actual ÷ estimate |
|---|---|---|---|
| Refactor auth middleware | 4 | 11 | 2.75 |
| Fix flaky test in checkout | 1 | 3.5 | 3.50 |
| Bump Postgres minor version | 2 | 1.5 | 0.75 |
| Onboarding doc rewrite | 6 | 9 | 1.50 |
| Migrate to Tailwind 4 | 8 | 18 | 2.25 |
| Add dark mode to admin | 3 | 5 | 1.67 |
| Localize error messages | 4 | 4.5 | 1.13 |
| Investigate prod 500 | 1 | 6 | 6.00 |
| Q3 metrics dashboard | 5 | 7.5 | 1.50 |
| Standup notes refactor | 1 | 0.5 | 0.50 |
Sort करने पर ratios इस क्रम में हैं: 0.50, 0.75, 1.13, 1.50, 1.50, 1.67, 2.25, 2.75, 3.50, 6.00। उस list से तीन numbers निकलते हैं, हर एक अलग काम के लिए।
- Median, एक task plan करने के लिए: (1.50 + 1.67) ÷ 2 = 1.58। जिस task को आपका gut 3 hours बताता है वो plan में 3 × 1.58 ≈ 4.75 hours, क़रीब 4 h 45 m बनकर जाता है। यह coin flip है: आपके आधे tasks इसके अंदर ख़त्म होने चाहिए। Tool इसे ×1.58 दिखाता है।
- 80th percentile, वादों के लिए: 10 sorted ratios में से 8वाँ, 2.75। वही task 3 × 2.75 = 8.25 hours बन जाता है जब date पर किसी और का काम टिका हो। Flyvbjerg बताते हैं कि UK Department for Transport इसी level का use करता है: बड़े local transport investments पर 20% overrun risk मंज़ूर।
- Totals का ratio, एक हफ़्ते के लिए: 66.5 actual hours ÷ 35 estimated = 1.90। Estimated tasks के बीस घंटे मतलब क़रीब 38 घंटे का काम। यहाँ median ग़लत tool है। Halkjelsvik and Jørgensen (2018) दिखाते हैं कि medians और most-likely values जोड़कर realistic total नहीं बनाते, और सिर्फ़ predicted means बनाते हैं। Totals का ratio estimate-weighted mean है। Tool दोनों totals दिखाता है।
10 में से सिर्फ़ 2 estimate के ±25% के अंदर आए, तो tool का "on the nose" share 20% आता है।
कुछ भी log करने से पहले एक फ़ैसला: आप effort का estimate लगा रहे हैं या calendar का? Buehler के students ने finish dates बताईं। Time tracker काम के घंटे measure करता है। 3-घंटे का task 4.75 घंटे का effort और calendar के तीन दिन ले सकता है, तो दोनों को अलग-अलग classes में रखें।
Actuals कहाँ से आने चाहिए
अगर आप actual memory से टाइप करते हैं, तो जिस bias को आप सुधारना चाह रहे थे वो सीधे correction में वापस चला जाता है। Roy, Christenfeld and McKenzie (2005) सुझाते हैं कि ज़रूरी tasks के लिए "task के शुरू और ख़त्म होने के समय के records रखना काम आ सकता है।" Roy के 2008 के experiments में लोगों ने तब अच्छा predict किया जब उन्होंने "past task duration की memory पर नहीं, बल्कि actual duration के measures पर" भरोसा किया।
कोई भी ईमानदार record चलेगा। Start/stop timer ठीक है अगर आप उसे भरोसे से start करते हैं। Finish dates के लिए आपका calendar और sent mail काफ़ी हैं।
मैं Timex बनाता हूँ, Mac के लिए एक automatic time tracker, और वो बिना start बटन के effort side को cover करता है। वो हर सेकंड frontmost app, window title और active browser tab का URL एक local SQLite file में record करता है। एक task का actual निकालने के लिए:
- App में: drill-down में app को expand करें और उसके top window titles समय के साथ देखें, या Today timeline पर उस हिस्से पर drag करें जितनी देर आपने उस पर काम किया, और filtered totals पढ़ें।
- SQL से: file को free SQLite viewer में खोलें और किसी ऐसी चीज़ से sum करें जो titles या URLs में दिखती हो, जैसे ticket ID:
SELECT ROUND(SUM(duration) / 3600.0, 2) AS hours
FROM activity
WHERE title LIKE '%ACME-142%' OR url LIKE '%ACME-142%';
नतीजे को estimate-vs-actual tool में actual की तरह paste करें। Timex कुछ भी estimate, plan या schedule नहीं करता। वो actuals देता है, और estimate करना आपके पास रहता है। वो सिर्फ़ आपका Mac भी देखता है। Phone call या whiteboard session के लिए manual entry चाहिए, जो Timex 5 मिनट दूर रहने पर offer करता है।
ईमानदार limits
Multiplier average सुधारता है, spread नहीं। Buehler की Study 4 ने यह पहले ही दिखा दिया। Feedback आपकी spread की समझ को ज़्यादा realistic बनाता है, पर धीरे-धीरे।
Halkjelsvik and Jørgensen (2018) जिस एक study का ज़िक्र करते हैं, उसमें software professionals ने 30 tasks के लिए 90% ranges दिए, और हर task के बाद असली समय सामने आया। पहले 10 tasks पर उन ranges ने 64% बार actual time को पकड़ा, अगले 10 पर 70% और आख़िरी 10 पर 81%। यह ज़्यादा realistic है, और फिर भी 90% से कम। इसीलिए आप जो number वादा करते हैं वो 80th percentile है, median नहीं।
दस tasks एक छोटा sample है, और class खिसकती रहती है। दस points का 80th percentile एक task बदलने से हिल जाता है, तो log करते रहें और दोबारा compute करें। 1-घंटे के bug fix को तीन हफ़्ते की migration के साथ न मिलाएँ; बहुत छोटे tasks वैसे भी overestimate हो सकते हैं। और एक बार आप correct करना शुरू करें, तो आपका gut ख़ुद padding शुरू कर सकता है। दोबारा compute करना उसे भी पकड़ लेता है।
Parkinson's law दूसरी तरफ़ धकेलता है। काम उपलब्ध समय को भरने के लिए फैलता है, और Halkjelsvik and Jørgensen इसे "प्लस थोड़ा और" तक बढ़ाते हैं। ख़ुद को target के तौर पर 80th-percentile number थमाएँ और slack ख़ुद ग़ायब होने लगता है। अपना दिन median पर plan करें, वादा 80th percentile पर करें, और फ़र्क़ को task के बाहर एक visible buffer की तरह रखें।
यह recipe हिस्सों को जोड़कर बनी है। हर हिस्से के पीछे evidence है: outside view, past को present से जोड़ना, measured durations। मुझे कोई study नहीं मिली जो individual knowledge workers पर "आपके पिछले दस tasks का median" test करती हो। अपने multiplier को ख़ुद के बारे में आपका फ़िलहाल सबसे अच्छा estimate मानें, कोई law नहीं।
अगले दस से शुरुआत करें
शुरू करने से पहले estimate लिख लें। Actual किसी record से लें, memory से नहीं। दस tasks के बाद ratios को sort करें और बीच वाला लें। यह करने के लिए एक stopwatch और एक spreadsheet काफ़ी हैं।
अगर आप stopwatch चलाना नहीं चाहते, तो Timex download करें और अपने अगले दस tasks उसके साथ log करें; trial 100 घंटे की tracked activity है, कोई credit card नहीं।
— DK