This is very true.  The best way I have found to combat it is by splitting up the tasks into many smaller pieces.  If you have a task that is scheduled to take a month, then it can easily go out to 10 months in the worst case.  If you have a task that is scheduled to take a day, it can easily go out to 10 days in the worst case.  This allows you to make corrections to your schedule.<p>There are 2 other important issues.  First, you need to update your schedule based on the amount of time tasks are actually taking.  If you only have 10 tasks (each taking a month), the error bars can be quite significant.  But if you have 200 tasks (each taking a day), the mean completion time will have quite small error bars.  So if you keep a rolling average (say over the last 30 tasks), you can have a fairly good estimate for completion time (agile developers will notice that this is &quot;velocity&quot;).<p>The second very important issue is to be completely anal about your definition of &quot;done&quot; and about making sure that the completed tasks actually meet that definition.  Your mean completion time will only be useful if you are measuring the time to completion accurately (obviously).<p>This effect is so powerful that I recommend &quot;same sizing&quot; tasks and planning everything to have a completion time of somewhere between 1 and 2 days.<p>There is actually one last thing you need to do.  Requirements discovery never happens completely before you start development.  As you write the code, you discover new things to do.  It is obviously important to modify your plan to accommodate that new information.  If you don&#x27;t, you will end up building something that nobody needs.  However, the amount of new work seems to be predictable.  I made graphs of new work added to projects over a couple of years and it appears that the growth of new requirements is very similar to some of the defect discovery models (for example Littlewood).  Just making a graph of new stories&#x2F;tasks added over time will give you a decent idea, but I have found that a rule of thumb of adding 30% or so (over the whole project) for new requirements seems to work well.