A unit comes back and the manager gives it a look. Straightforward turn, nothing structural, two weeks. It takes five. Not because anything catastrophic happened. The painter started a day late, one fixture was back-ordered, the cleaning slipped a day, and inspection turned up one final thing that needed a second visit. Nothing unusual. Everything normal. And the estimate was wrong by more than double, just as it was on the last turn, and the one before that.

The surprising part is not that the estimate was wrong. It is that it keeps being wrong in exactly the same direction, and every new estimate still starts from scratch.

The Estimate You Build Is The Estimate That Runs Long

This is one of the most reliable findings in the study of how people plan. Daniel Kahneman and Amos Tversky named it the planning fallacy: the systematic tendency to underestimate how long a task will take and how much it will cost, and to do so even when you have watched similar tasks run long many times before. It is built into the way an estimate gets made. Experience does not protect you from it. Experienced people do it too.

When you estimate a specific job, you take what Kahneman called the inside view. You picture this particular unit, this particular project, and you mentally walk through the steps. The walk-through is smooth, because imagined work is always smooth. You do not picture the back-ordered fixture, because you do not know which fixture will be back-ordered. You do not picture the contractor rescheduling, because in your head the contractor shows up on time. So the estimate you build is usually a best-case path. Best cases are rare. The result is a number that is honest, careful, and consistently too low. And here is the cruel part: it is also the number you feel most sure of, because confidence comes from the vividness of the story you just told yourself, not from the accuracy of the forecast. The smoother the walk-through, the more certain you feel, and the more certain you feel, the more wrong you tend to be.

The Outside View Works Precisely Because It Is Boring

Kahneman's fix was to stop looking at the specific job and look instead at the class of jobs it belongs to. He called it the outside view: rather than asking how long this turn will take, ask how long turns like this one actually take, based on the ones you have already done. The researcher Bent Flyvbjerg turned this into a formal method, reference class forecasting, and used it to fix the forecasts on enormous infrastructure projects, the kind famous for running years late and billions over. His data on those projects is brutal. Rail cost forecasts, to take one example, were routinely off by around forty percent, and in the same optimistic direction nearly every time.

What the outside view does is simple to describe and hard to accept. It ignores the story of your specific job entirely. It does not care that this unit looks easy, or that this project has a good contractor, or that this lease-up is in a strong month. It only asks what happened the last thirty times you did something similar.

If your last thirty turns averaged thirty-four days, the outside view says your next turn is a thirty-four day turn, and it says so before you have even looked at the unit. The number feels too high, because you are comparing it to the smooth walk-through in your head. The number is right, and the walk-through is the problem.

"This One is Different" is What You Thought Last Time

The reason people override the outside view, again and again, is that every specific job genuinely looks specific. This turn really does have its own quirks. This project really does have reasons it might go faster. So the manager sets aside the boring average and estimates from the details, confident that this case is an exception. That is exactly why the bias survives. Every job arrives with a convincing story about why it should beat the average.

The trouble is that the last thirty turns each looked like exceptions too, and they still averaged thirty-four days. The quirks are not the exception to the pattern. The quirks are the pattern. There is always some fixture, some reschedule, some small failed inspection. You cannot predict which one it will be this time, which is exactly why you cannot plan it out of the estimate. The only thing that reliably captures all of them at once is the record of how long the work actually took, because that record already includes every quirk that has ever happened, averaged into a single honest number.

Stop Estimating. Start Counting.

The practical move is to change the question. When someone asks how long a turn will take, one answer starts with a fresh estimate built from the details of this unit. The better answer starts with your own history: here is how long our last thirty comparable turns actually took, so that is our estimate, and we will adjust it only for a difference we can specifically name and defend, not for general optimism.

This does two things. It moves the estimate from an act of judgment, which is where the bias lives, to an act of retrieval, which is where the bias cannot reach. And it gives you a timeline far more likely to be right, which means fewer promises broken to owners, fewer move-ins scheduled into units that are not ready, and fewer plans built on a date that was never realistic. You are no longer guessing how long it takes. You are reporting how long it takes.

The Outside View Only Helps If You Let It Win

There is a catch, and it is worth stating plainly, because it is where most attempts at this quietly fail. The outside view will hand you a number you do not like. It will tell you the turn takes five weeks when you wanted to promise two, and every instinct will push you to override it with the confident inside-view story about why this one is faster. Do that, and you are back to guessing, with a spreadsheet for cover.

The discipline is to let the history win the argument by default, and to require a specific, documented reason before you depart from it. Not "this one feels easier," which is what you felt every other time, but a concrete, nameable difference you could point to later and say, that is why I adjusted. Absent that, the average stands. That is the whole method. It is not sophisticated. It just asks you to trust your own record over your own optimism.

Your Reference Class is Already Sitting in Your Data

The reason this is not standard practice is rarely that managers reject the idea. It is that the outside view requires data most operations cannot easily reach. To forecast a turn from your last thirty turns, you need to know how long your last thirty turns actually took, cleanly, in one place, without reconstructing it from memory and a dozen spreadsheets. When that history is scattered, the outside view is technically available and practically impossible, so people fall back on the inside-view guess out of sheer friction.

When that history lives in one system, the outside view becomes easy to use. RIOO keeps a property's operating history together, so instead of rebuilding the last thirty turns from spreadsheets and memory, you already have the reference point in front of you. The outside view stops being a good idea you never get around to and becomes the default answer to how long this will take.

The Takeaway

You almost certainly do not have a forecasting problem in the sense of lacking a technique. You have a problem of trusting a smooth mental walk-through over a rough written record, and reaching for the first because the second is harder to find. The planning fallacy is not a flaw you can think your way out of in the moment, because the flaw is the in-the-moment thinking. The only reliable escape is to stop estimating from the case in front of you and start counting from the cases behind you.

The next time someone asks how long it will take, the best possible answer is not a better guess. It is a quiet look at your operating record, and the number that is already there. You do not have to estimate it. Your history has already done the estimating for you.

FAQ

1. What is the planning fallacy?
It is the well-documented tendency to underestimate how long a task will take, how much it will cost, and how much can go wrong, even when you have direct experience of similar tasks running long. Named by Daniel Kahneman and Amos Tversky, it persists despite experience because it is built into how estimates are made, not into how skilled the estimator is.

2. What is the difference between the inside view and the outside view?
The inside view estimates a job from its own details: you picture this specific unit or project and mentally walk through the steps, which almost always produces an optimistic, best-case number. The outside view ignores those details and asks how long jobs in the same class have actually taken. The outside view is consistently more accurate, because it captures the delays the walk-through leaves out.

3. What is reference class forecasting, and how do I use it for property estimates?
It is the formal version of the outside view, developed by Bent Flyvbjerg. Instead of estimating a turn or a lease-up from scratch, you build a reference class of similar past cases and use their actual distribution of outcomes as your forecast. In practice: pull how long your last twenty or thirty comparable turns really took, and use that as the estimate rather than a fresh guess.

4. How many past projects should be in a reference class?
Usually twenty to thirty comparable cases is enough to produce a stable, useful average. Fewer than that and one unusual job can distort the picture; far more and you risk mixing in cases too different to be comparable. The goal is a group similar enough to be relevant and large enough that no single outlier dominates.

5. Why do my estimates always run long even though I'm experienced?
Because experience does not remove the bias. The error comes from estimating each job by imagining its steps, and an imagined process is always smoother than a real one. Every job has some unpredictable delay, and since you cannot know which one it will be, you cannot plan it out. Only the record of past actual durations captures those delays reliably.

6. When is it okay to override the historical average?
Only when you can name a specific, concrete difference that you could defend later, such as a genuinely smaller scope or a documented process change. A vague sense that "this one is easier" does not count, because that is the same feeling that produced every previous underestimate. Absent a nameable reason, the historical number should stand.