6 ms·
Uniqueness Bias: Why it matters, how to curb it
- reportgunner 2y agoVery cool, I have been looking for the name of this for some time.
- ozgune 2y agoI read this book called "How Big Things Get Done." I've seen my fair share of projects going haywire and I wanted to understand if we could do better. The book identifies uniqueness bias as an important reason for why most big projects overrun. (*) In short, this bias leads planners to view their projects as unique, thereby disregarding valuable lessons from previous similar projects. (*) The book compiles 16,000 big projects across different domains. 99.5% of those projects overrun their timeline or budget. Others reasons for slipping include optimism bias, not relying on the right anchor, and strategic misrepresentation.
- jakobloekke 2y agoCannot recommend that book enough
- kqr 2y agoThis goes beyond project estimations. The Metaculus tournaments have questions like > Will YouTube be banned in Russia before October 1? These are the kinds of questions most people I meet would claim are impossible to forecast accurately on because of their supposed uniqueness, yet the Metaculus community does it again and again. I believe the problem is a lack of statistical literacy. Back in the 1500s shipping insurance was priced under the assumption that if you just learned enough about the voyage you could tell for certain whether it would be successful or not. It took a revolution in mindset to ignore everything that makes a shipment unique and instead focus on what a primitive reference class of them have in common, and infer general success propensities from that. Most people I meet still don't understand this, and I think it will be a few more generations until statistical literacy is as widespread as the literal one.
- tomlue 2y agoI know you're coming from a good place, but the 'most people I meet don't understand this' line about statistics is quite arrogant. Most people you meet are fully capable of understanding statistics; you should do a better job of explaining it when it comes up, or maybe you are the one who misunderstands. After all, most statisticians thought Marilyn vos Savant was wrong about the goats too...
- robwwilliams 2y agoNot my experience at all. Just one example: try talking to physicians about false discovery rates; even those who do not profit from state-of-the art screening methods. Incorporating Bayesian methods is even a struggle for statisticians. It is a stuggle for me. John Ioannidis has much to say on this topic: https://en.wikipedia.org/wiki/John_Ioannidis https://en.wikipedia.org/wiki/John_Ioannidis
- joebob42 2y agoMy experience is that most people don't understand statistics and can be pretty easily mislead. That includes myself, with my only defense being that I'm at least aware statistics don't intuitively make sense and either ignore arguments based on them or if absolutely necessary invest the extra time to properly understand. Most people either don't realize this is necessary or don't have the background to do it even if they did, in my experience.
- lordnacho 2y agoYou don't have to be on the internet for long to see: - "Polls are useless, they only sampled a few thousand people" - "Why do we need the crime figures adjusted for the age/income/etc groups? Just gimme the raw truth!" Have to say, I think stats are the least well taught area in the math curriculum. Most people by far have no clue what Simpson's or Berkson's paradoxes are. Most people do not have the critical sense when presented with stats to ask questions like "how was the data collected" or "does it show what we think it shows". I just don't see it, tough ironically I don't have stats to back it up.
- pif 2y ago> 99.5% of those projects overrun their timeline or budget. This does not shock me. In the corporate world, plans are not there to be adhered to, but only to give upper management a feeling of having tightened the rope for those pesky engineers who wanted to work at a lazy pace. Such feeling usually vanishes as soon as reality kicks in.
- zerodensity 2y agoI dunno, upper management normally move onto greener pastures long before reality comes crashing down. That does not happen until two managers over. But that's okay the new plan will fix everything.
- bux93 2y agoThis is why your project shouldn't be too small. If a project is projected to be finished in 6 months, the current manager will still be there, and the success or failure will reflect on their record. It can only go wrong and reflect badly on them. If a project will take 3 years, the manager can already collect their points for initiating a project with an incredible business case and innovative approach, leave after 18 months, and after a further six month, the new manager can say 'wow, my predecessor left a big mess, I'll clean it up/kill it'.
- steveBK123 2y agoI think a lot of modern US public works fall prey to politicians who think the objective of the project is the spending of the money. That is - they push for spending on transit so they can talk about how much, in dollars, they got passed in transit funding. The actual outcomes for many of them are, at best, inconsequential. Further cynicism could be layered in if you consider some of the blocks of donors (infrastructure contractors / RE devs / etc) and blocks of voters (union transit workers & construction workers) who are recipients again of the spending but not the outcomes. Finally a lot of the problems come from a long gap of not doing capital projects and so hollowing out of state capacity which has been outsourced. If you outsource your planning, they are less incentivized to re-use existing cookie-cutter plans for subway stations. If you outsource your project management, they are less incentivized to keep costs down. ETc.
- pessimizer 2y ago> Further cynicism could be layered in if you consider some of the blocks of donors (infrastructure contractors / RE devs / etc) and blocks of voters (union transit workers & construction workers) who are recipients again of the spending but not the outcomes. It's probably best to think of an initial budget as a foothold, and that its ideal amount is low enough to be approved, but high enough to prevent the organization from changing direction after realizing that it's not going to be nearly enough i.e. to think in terms of "pot-commitment."
- nitwit005 2y agoPersonal suspicion is that real leadership is dull and thankless (like so many things in life). Announcing a big new transit project is exciting. Actually running the program well requires a lot of boring study, meetings, and management of details. Why bother, if the voters don't punish them for not doing it? You can find endless internet posts by people complaining their manager doesn't want to do the scheduling of employees, which is the most basic part of their job. It's too tedious, so they try to avoid it.
- bryananderson 2y agoThis book is by Bent Flyvbjerg, the lead author of the paper being discussed here. He’s done a lot of great scholarship on how megaprojects go haywire, and uniqueness bias is definitely a big piece of it. You especially see this bias with North American public transit. Most of our transit is greatly deficient compared to much of the rest of the world, and vastly more expensive to build (even controlling for wages). But most NA transit leadership is almost aggressively incurious about learning from other countries, because we are very unique and special and exceptional, so their far better engineering and project management solutions just wouldn’t work here and aren’t even worth considering.
- bsder 2y ago> Others reasons for slipping include optimism bias, not relying on the right anchor, and strategic misrepresentation. Optimisim and misrepresentation are WAY more important. Most engineers I know of were a bit optimistic to other engineers. This leads to slippage because subtasks have a finite amount they can come in early but an almost infinite amount of time they can come in late. In addition, most engineers are acutely aware of what they think the project would take vs. what number management was willing to hear to launch the project. Combine both of these and your project will never come in even remotely close to the estimates.
- atoav 2y agoAnd sometimes the reality is that the realistic answer to a time estimate is "If we are lucky it takes me 30 minutes, if we are unlucky 30 days". E.g. when it turns out to your surprise, that a part you had in your hardware design was replaced with a part that was 5 cents cheaper, but uses a undocumented protocol that someone has to re-implement, so a goal that was trivial in theory has suddenly involves hardcore reverse-engineering in a high pressure environment. A thing all engineers love. The only time someone can give you reasonably accurate estimates is when they do something that down to the tiniest detail they have done before. The problem with that is, that in software things change constantly. A thing that was trivial to do with library X and Component Y of version 0.9 might be a total pain in the rear with Library Z and Component Y of version 1.0. But yeah, unexperienced engineers are going to be optimistic that it is possible, because in theory it should be trivial.
- dspillett 2y ago> And sometimes the reality is that the realistic answer to a time estimate is "If we are lucky it takes me 30 minutes, if we are unlucky 30 days". “I'll put that in Project as 60 minutes, then if you are luck you've got double time for contingency.” -- the external consultant acting as project manager. Been there before… Never give a best case estimate, or anything close to, even when quoting a range. Some will judge you, or worse make plans around you, based on that and little else, and it *ahem* isn't their fault if things overrun.
- carlmr 2y ago>In short, this bias leads planners to view their projects as unique, thereby disregarding valuable lessons from previous similar projects. I once had a discussion. We had some managers that would systematically over or underestimate their projects, mostly underestimate. I suggested that we take into account the estimation accuracy of previous projects for that manager and adjust their estimate. They said that each project is too unique to do this. But I saw the same optimism or pessimism playing out repeatedly for the same managers when looking at the numbers. Although tbf I think accurate estimation can be bad if the person managing the project knows about the estimation. Since if they have more time, there's less pressure, and they'll have overruns again, making the estimation inaccurate again. Hofstadter's law, to me, is less about accurate estimation and more about human psychology. If you know you have more time, you waste more time. This is also a failure-mode in agile project management. If you don't have strict deadlines, it's easy to fall into infinite iteration, because there's always something that could be done better.
- deleted 2y ago[deleted]
- roenxi 2y agoUniqueness bias is definitely a problem (see also: This time is different!) and this paper's conclusions make a lot of intuitive sense. Less competent planners are more likely to see their situation as unique. However, the measures to establish that perceived uniqueness != uniqueness seem a little bit limited to me. I've seen projects go belly-up because senior management refused to accept that the situation on the ground at one location was different to the usual situation in most other locations, leading to cost blow outs and project failures. I don't think the treatment in this article would pick that dynamic up. So while it is true that exceptional engineering projects (paper's example - the Apollo project) are much more mundane than they might seem, it is also true that seemingly mundane projects can be unique and therefore it is difficult to compare with other projects of a similar nature.
- toss1 2y ago>>management refused to accept ... that the situation was different Yes! Seems that the compliment of Uniqueness Bias is Normalcy Bias. Two cliffs to fall off of on opposite sides of the path. Makes me wonder how a similar study on projects failing due to Normalcy Bias (failing to recognize the uniqueness of a situation) would turn out, and in particular, which bias produces more and bigger cost and/or time overruns. I.e., which is the least-bad side on which to err?
- inopinatus 2y agoThat’s why it’s a bias, not a fallacy.
- sebstefan 2y ago"We are facing unique challenges with our very sophisticated CRUD app. It is distributed and must maintain high reliability."
- sdenton4 2y agoOnce we overcome uniqueness bias, we'll need to overcome '...but it might work for us' bias. Lindsay: Well, did it work for those people? Tobias: No, it never does. I mean, these people somehow delude themselves into thinking it might, but ... But it might work for us.
- nemomarx 2y agoIsn't it socially healthy to have that bias though? Like working at a start up is statistically unlikely to pay off in a huge way, but ideally you want most founders to think they can do that so they'll make the attempt?
- Vecr 2y agoThat means you need to pawn off startup ideas onto people with bad risk management and invest in a bunch of them to spread out your risk.
- JohnCClarke 2y agoIf only there was some kind of social media devoted to gathering all those folks in one place. Oh, wait
- SiempreViernes 2y agoThis sounds quite a lot like "trick people into taking risks I don't want to take myself", not sure that's bound to produce socially good outcomes...
- yobbo 2y agoIt seems based on questionnaires sent out about projects, and they've found some correlation between "uniqueness of a project" (unclearly defined) and cost overruns. Because "uniqueness" is unmeasurable, they can provide various examples in prose where both arguments and counterarguments for uniqueness seem reasonable. So this isn't really science. But the overall argument; that uniqueness bias (in so far it exists) causes managers to be less critical, seems reasonable.
- Jensson 2y ago> perceived uniqueness is indeed highly statistically significantly associated with underperformance Isn't it possible that perceived unique projects are unique and therefore are harder and underperform? Did they control for that?
- Nasrudith 2y agoOr that people who don't know many scenarios of the past cannot draw upon similarities or see the connection without experience and thus conclude their situation is unique.
- aniviacat 2y agoThey did. Under "Perceived v. Actual Uniqueness" it says: > we conclude from the available data that [...] perceived and actual uniqueness are uncorrelated (Though as other comments suggest, their method of arriving at this conclusion might be flawed.)
- bobosha 2y agoPerhaps a good way of thinking about this is: "history doesn't repeat itself, but it rhymes" - (supposedly) Mark Twain
- pjdesno 2y agoI found the textbook example interesting, where the co-author with experience thought it would take 7+ years, and everyone else thought it would take about 2. That makes a lot of sense to me, because I wrote a textbook in about 2 years. But... There are textbooks and there are textbooks. My book covers exactly what I need for my class, has no publisher (students download it from the class website), and doesn't have a lot of the bells and whistles that a publisher would demand. I can easily see how a "real" textbook would take over 3x as long. So part of the lesson of the authors' textbook is a standard software development lesson - there's a huge gap between a working prototype and a shipping product, and even if that prototype does everything you think the product needs to do, (a) you're wrong, and (b) you may be less than halfway to the point where you can ship.
- aniviacat 2y ago> Sanbonmatsu et al. (1991) studied consumer choice between multiple brands and products. Experiments demonstrated that when deciding what to buy, consumers search for unique features instead of common ones among alternatives before making their choice. Bolton (2003) further found that even when decision makers are forced to consider more alternatives, including counterfactuals, decisions are still biased towards the initial scenario, which is typically based on availability bias and the inside view. Again, this supports our interpretation that uniqueness bias is likely the outcome of information processing by decision makers rather than an expression of hindsight bias. This seems like a far-fetched conclusion to me. Neither of these two studies seem to suggest that people do not significantly overestimate uniqueness of projects in hindsight. The 2003 study seems completely unrelated. How does bias torwards the inital scenario imply a uniqueness bias? That would require uniqueness to be the initial scenario. If anything, I would claim the opposite. The 1991 study may imply that people tend to focus on unique aspects. Claiming that this tendency in product choice carries over to project management is a strecht imo. And even if it did, that would still not be a strong argument for the conclusion.
- ConradKilroy 2y agoRelated: At the national scale, 'American Exceptionalism'. See https://en.wikipedia.org/wiki/American_exceptionalism https://en.wikipedia.org/wiki/American_exceptionalism