Epistemic Status: Search your feelings, you know it to be true.
I’ve had planning fallacy on the mind recently, for a combination of both personal and professional reasons. This cognitive bias has been a focus of mine, again for both personal and professional reasons, for many years. It’s perhaps ironic, then, that I experienced it so greatly, in multiple areas, between the time I decided to write about it and the time I actually sat down to write. And that motivates me to write about it even more.
Planning fallacy usually refers to the consistency tendency of humans to underestimate how long it will take to complete a task. The term is also sometimes applied to underestimates of cost and risk, because those often see similar failures of estimation. I suspect that all my readers (yes, both of you) can think up multiple times you underestimated how long something will take, despite having all the relevant knowledge and experience to make a more accurate prediction.
Interestingly, planning fallacy is mostly an egocentric bias. We typically do better when looking at the timelines for others’ tasks, even overestimating how long such things will take.
Various explanations have been proposed, but I’m less confident that any particular explanation survived the replication crisis than the concept of planning fallacy itself. A number of the proposed explanations relate specifically to project management, which is of course a major motivation for my studying the phenomenon, but which is also heavily dependent on the organizational context, and thus less generalizable.
On the other hand, there are a few basic strategies for combating the planning fallacy, and these are applicable in most contexts.
Implementation Intentions are concrete plans for action, focused on the where, when, and how. All too often, we have a clear answer for who, what, and why, but neglect the other questions. If, for instance, you want to write a novel, you need to decide where the actually writing is going to take place (your house, a coffee shop, on your patio, etc.), and when (in the morning, late at night, only on weekends, etc.), and how (in a Microsoft Word document, on a typewriter, with quill & parchment, etc.).
There’s some evidence, though I haven’t checked whether these studies are still replicating, that simply thinking things through explicitly helps one commit to actually completing the task. (It’s easier to get up and go if you’ve already planned everything out.) Additionally, this explicit breakdown leads to the second major technique…
Segmentation refers to explicitly breaking down the task into subtasks, and estimating the time (or cost) of these subtasks before adding them up. Humans are notorious for giving a top-level estimate significantly smaller than the sum of its parts. This is less a matter of fudging, though that certainly happens, especially in contexts with pressure from above. Rather, we simply come up with a more optimistic overall answer than when we stop and think through everything that the larger goal entails.
This assumes, of course, that we have a clear sense of what said goal entails. Sometimes, starting out, that’s not the case. Either we don’t know the breakdown, or we don’t know how long some of the individual components will take. (For large and complicated projects, it’s probably some of both.) In this case, we can use reference class forecasting to get a starting value to iterate around.
We use this a lot in engineering design, and I realized the application for combating planning fallacy years before I formally encountered the term. Take the relevant figure-of-merit (usually time or cost, in project management) and check what the number ended up being for a prior comparable project.
If a comparable project took two years, maybe revise up your estimate of six months. Maybe there’s a good reason to believe you can get it done faster—but maybe you’re full of it. Unless you can very clearly spell out what you’re going to do different and how it will make things better, basing your estimates on past performance is safer.
For a concrete example, when my parents decided to move, they could have used the recent experience they’d had cleaning out my grandmother’s house as a starting point. That took them nine (9) months, with considerable assistance from me. Moving to a new house is a different but somewhat comparable experience, so use nine months as a starting point. But then consider the two storage units of stuff from my grandmother’s house that wouldn’t fit in our old house, and that I was attending college full-time in Lawrence instead of living at home, and it’s not easy to see that it could end up taking quite a bit longer that that.
In the end, it took 26 months—far longer than my parents remotely expected when they chose to undertake the project. The last seven months featured full-time contributions from me, because I graduated college and moved back home. I was never able to prove it, but dumping all of my breaks during Junior and Senior year into unpaid household labor (instead of, you know, resting after finals) probably had something to do with my abject lack of job offers on graduation.
If I sound bitter, it’s because I am. I predicted this would go poorly, that no lessons had been learned from the preceding comparable operation, and that I would have a miserable time for no personal benefit. My concerns were dismissed, and then borne out even worse than I’d imagined. Applying some simple reference class forecasting, using the previous move as the starting point, would have gotten them a lot closer to the actual ~3x factor than the wildly optimistic vague intentions they used to make a major life decision.
Now, sometimes it’s not clear what the relevant reference class actually is. This is a legitimate limitation to reference class forecasting, especially when you’re trying to do something new. Cleaning out a dead person’s house is not exactly comparable to moving your own house, but it clearly in the same general ballpark. But if you’re trying to do something almost entirely new, then you have a bigger challenge. When trying to scope out a Mars mission architecture, for instance, there’s not really a directly comparable project to work off. We can learn lessons from previous infrastructure and aerospace projects, but they aren’t exactly the same thing.
That’s no excuse for throwing up our hands and pulling numbers out of thin air. Setting arbitrary targets is a recipe for disappointment. Instead, we use these techniques to come up with our best estimate based on the information available, however incomplete, and build in a healthy margin (especially when succeeding on-time is important). Your idea of “a healthy margin” will almost certainly be too small, as I learned the hard way this last weekend. Make it bigger.
In a professional context, upper management won’t like it. But they’ll like it less if they get fired for being late. As Akin’s 23rd Law of Spacecraft Design states, “[t]he schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it.”
The application of these principle is left as an exercise to the reader.