Planning Fallacy

A simple explanation

Planning fallacy is the bias Kahneman and Tversky named for the gap between how long you think a task will take and how long it actually takes. The gap is robust, asymmetric, and persistent. People who have just spent twice their estimate on the last project will, when asked about the next one, return a number close to the original estimate again. The forecast does not learn from its own history.

The bias is not naive optimism. It is a specific malfunction of the Reward System's anticipation circuitry: the felt experience of imagining completion is far more vivid than the felt experience of imagining all the steps between now and then. The completion image is the motivator. The intervening steps are what take the time.

An everyday example

You sit down on Sunday evening and map the week. The report is two days. The pitch deck is one day. The home admin is half a day. The exercise window is built in. The buffer is honest.

By Wednesday, the report is at sixty percent. By Friday, the deck has not started. The half day of home admin became two evenings of email triage. The exercise window survived twice. On Sunday again, you sit down to map the next week, and the new report is two days. You believe the estimate. The estimate is wrong in exactly the same way as last week.

Why do I always underestimate how long things take?

Because the Reward System, asked to mobilise effort, runs the cheapest possible calculation: visualise the completed state, return the directness of the line between here and there. The line is short because the visualisation skips the texture. The texture is what eats the time — the email that needs a clarifying reply, the figure that needs to be redrawn, the meeting that runs long, the unexpected dependency, the day a child is home sick.

The System is not malfunctioning. It is doing exactly the work of generating motivation in the moment, and the felt brightness of imagined completion is precisely what gets the project started. If the forecast were honest about the texture, the project might not begin at all. The bias is the price the System pays to keep you in motion.

The behavioral loop

A loop that produces motion now and breakage later:

1. Task selection — a new project enters the queue.
2. Completion visualisation — the System generates a vivid image of the finished state and routes felt reward toward it.
3. Inside view estimate — you forecast the time the task will take based on imagining the steps from here to completion, not on the reference class of how long similar tasks have actually taken.
4. Commitment — the estimate is shared, scheduled, promised to others.
5. Texture arrives — the work encounters the unanticipated friction that was invisible in the completion image.
6. Effort surge — the back half compresses. Hours expand into nights. Adjacent commitments suffer.
7. Delivery, late — the task ships at or past the original deadline, often at lower quality than the visualisation promised.
8. Memory editing — the overrun is attributed to the specific surprises of this project, not to the forecasting strategy. The next forecast inherits the same shape.

Emotional drivers

Four feelings, in stack:

• A bright felt anticipation of completion that the System uses as fuel.
• A faint identity attachment to being someone who delivers on ambitious timelines.
• A creeping anxiety in the back half, attributed to the work rather than to the original estimate.
• A small private shame on delivery that is rarely metabolised into a forecasting update.

What your nervous system does

In the imagining phase, the body shows a low-grade reward activation — a slight lean-in, a quickening that feels like motivation. As the deadline approaches and the estimate proves wrong, sympathetic load climbs. Sleep shortens. Heart rate elevates. The body absorbs the cost of the surge in the back half: cortisol stays high, recovery shrinks, and a particular kind of fatigue accumulates that is specifically about catching up to a forecast.

Across years, this rhythm becomes the body's normal cadence. The conscious mind reads it as the texture of being a productive person, while the autonomic system reads it as chronic over-extension.

The DojoWell interpretation

Planning fallacy is one of the cleanest examples of a Reward System deposit that doubles as a forecast distortion. The original ask — get me started on something hard — is real and is solved by the vivid completion image. The substitute — use that same image as the time estimate — feels identical to the original answer but does opposite work.

The deposit register shows real wins: things get started, ambition stays alive, projects you would have refused on an honest forecast get launched. The residue register shows the larger cost: the back-half surges, the downstream commitments that break, the sleep borrowed against, and the slow erosion of trust with people who have learned not to take your dates at face value.

The density signature is false_progress because the loop keeps logging successful launches. Every project starts. Most projects finish. The motivation system is, in its own register, working. The residue accumulates in a separate register the System does not consult — the people who quietly recalibrate your timelines, the body that learns to brace for the surge, the texture of competence that never gets to be calm.

How do I plan more accurately without losing motivation?

You separate the two jobs the System was doing with one image. One job is starting; the other is forecasting. They need different inputs.

Three moves:

1. Use the outside view for the estimate. Ask how long similar tasks have actually taken in the past, in clock hours, in the worst recent case. That number is the planning input. The completion image stays available for motivation but is no longer the schedule.
2. Break the task into texture. List the small steps you usually skip in the visualisation — the review cycle, the unexpected dependency, the meeting that has not yet been scheduled. Each one is an hour you will spend.
3. Add an honest buffer for the unknown. Not a comfort margin. A specific multiplier — often 1.5x or 2x — that the reference class supports. The System will protest. The protest is the bias.

Practical steps

1. Keep a reference-class log. For each project type, record actual elapsed time. After three or four entries, the inside-view estimate becomes auditable against your own history.
2. Estimate ranges, not points. A best case, expected case, and worst case. The expected case is the commitment date. The bias hates this and that is why it works.
3. Pre-mortem before commitment. Imagine the project has run late. Write the reasons. Each reason is a step the visualisation skipped.
4. Borrow from someone who has done it. A peer estimate is often more accurate than your own because they do not carry your completion image. Trade estimates with someone whose timeline you trust.
5. Honour the delivered date in the next forecast. When this project ships late by a certain ratio, apply that ratio to the next estimate of its kind. The forecasting strategy updates only if you make it.

Reflection questions

• For which kind of project does your planning fallacy run widest — creative work, admin, technical builds, relational projects?
• Where has chronic underestimation cost you something less visible than time — sleep, trust, the quality of the work itself?
• What would change if your delivered dates routinely matched your committed dates?
• Which completion image, right now, is doing too much work as both motivator and schedule?

Frequently Asked Questions