On a small task, everything is small. The percent error can be totally gross (not precise at all) and not have a meaningful impact overall. A large error on small is just a multiplier of small. It's all small.
When you decompose a larger task into smaller ones, that's all still true for each of the smaller ones, right?
But you must remember to add the errors! And that is precisely why overall confidence may not likely improve with decomposition vs. an aggregate, or coarse, high level estimate of the whole thing.
And this is true for more than software. Why?
New tasks can be broken down into two coarse buckets: done before and novel.
Novel things really are novel! It's important to recognize this case and qualify it. Progress might look like:
Because it's novel, there are new dynamics in play, and even the best planning may not account for, and actually usually does not account for, things that just come up and that must be dealt with.
For the done before case, it's better as a lot is known, but there are still many factors out of the team control. Updates, changes, regressions, unfound bugs, all contribute to variance. The more the organization completely owns, the less this may be true, but it's always somewhat true.
The pragmatic person might classify everything as having some percentage of novel, and break it down into known novel and unknown, "it just hit us!" type novel and go from there and likely be better off when having to manage expectations.
Another way to think of this, depending on it being software or something else, is production vs "R&D" and the research and development part just isn't cog / production like. Time and materials estimates, if they are even given, must be considered accordingly.
If they are not, expectations do not match realities, and now there is a management and potentially a funding problem in addition to the primary problem needing a solution.
When you decompose a larger task into smaller ones, that's all still true for each of the smaller ones, right?
But you must remember to add the errors! And that is precisely why overall confidence may not likely improve with decomposition vs. an aggregate, or coarse, high level estimate of the whole thing.
And this is true for more than software. Why?
New tasks can be broken down into two coarse buckets: done before and novel.
Novel things really are novel! It's important to recognize this case and qualify it. Progress might look like:
week 1 - 10 percent done, week 2 - 10 percent done, week 3 - 15 percent done, week 4 - 50 percent done! Yes!, week 5 - 5 percent done... everybody take a drink, week 6 - 40 percent done,
etc...
Because it's novel, there are new dynamics in play, and even the best planning may not account for, and actually usually does not account for, things that just come up and that must be dealt with.
For the done before case, it's better as a lot is known, but there are still many factors out of the team control. Updates, changes, regressions, unfound bugs, all contribute to variance. The more the organization completely owns, the less this may be true, but it's always somewhat true.
The pragmatic person might classify everything as having some percentage of novel, and break it down into known novel and unknown, "it just hit us!" type novel and go from there and likely be better off when having to manage expectations.
Another way to think of this, depending on it being software or something else, is production vs "R&D" and the research and development part just isn't cog / production like. Time and materials estimates, if they are even given, must be considered accordingly.
If they are not, expectations do not match realities, and now there is a management and potentially a funding problem in addition to the primary problem needing a solution.