Here's an article that explains the phenomenon much better than I can. It made its rounds in HN a week or two ago: https://erikbern.com/2019/04/15/why-software-

Here's an article that explains the phenomenon much better than I can. It made its rounds in HN a week or two ago: https://erikbern.com/2019/04/15/why-software-projects-take-longer-than-you-think-a-statistical-model.html https://erikbern.com/2019/04/15/why-software-projects-take-l... I haven't seen a good way to turn the concept of "it should almost never take longer than that" into a concrete process. I've always seen it as a gut check, often implemented as "take your initial estimate and double/triple it." What I actually see is that a lot of teams implement that but walk back the doubling when the business/PM delegation persistently asks for more in less time. Only in really engineer driven cultures have I seen engineering teams successfully push back.