Why Software Projects Take Longer Than You Thnk

If you've worked in IT, you've seen it happen. A software project that seems straightforward ends up taking longer than originally estimated, sometimes a lot longer. Of course, the same is true for writing projects—sometimes the delay is because the overarching project runs into problems, other times the estimates for the writing project are just way off.

It's possible to apply statistical modelling to project planning and there may be a mathematical basis to some project delays. My university stats are pretty rusty, but the math in this article isn't that complex and seems reasonable.

Again, one single misbehaving task basically ends up dominating the calculation, at least for the 99% case. Even for mean though, the one freak project ends up taking over roughly half the time spend on these tasks, despite all of these tasks having a similar median time to completion. To make it simple, I assumed that all tasks have the same estimated size, but different uncertainties. The same math applies if we vary the size as well.

Funny thing is I’ve had this gut feeling for a while. Adding up estimates rarely work when you end up with more than a few tasks. Instead, figure out which tasks have the highest uncertainty – those tasks are basically going to dominate the mean time to completion.