Estimates are interesting and I encourage anybody to play with the statistics to see how it works. There are 2 scenarios you need to consider. First is the scenario where the stake holder asks for something, the thing is possible (i.e. it's a matter of working on it until it's done), they don't change their mind, the team doesn't have some kind of emotional incident (like people refusing to work together, someone having a serious health issue, etc). In that case you can split down the overall task into many sub-tasks and estimate each one. Each sub-task estimate will have a high variance, but the more sub-tasks you break it down into, the less variance the resulting overall estimate will have.
The key thing to understand is that while the overall variance will be small, you don't know what the multiplier will be. For teams that you are familiar with, technology that you are familiar with, etc, etc, in my experience people do tend to come out with about the same overall multiplier. Different teams are vastly different, though. I've had teams that operated anywhere from 0.5x (i.e. they overestimated by a factor of 2) to 4.0x (i.e. they underestimated by a factor of 4). It's always best to keep measuring your team's performance to figure out what the best multiplier to use (this is what's known as "load average" in some "agile" systems -- the inverse is "velocity"). Care must be taken to dissuade people from trying to optimise the load average/velocity because it will undermine your estimations -- usually I don't tell people what it is.
Now the other scenario is also fascinating, but requires much less statistics to understand well. Basically this is when the stake holder constantly inserts urgent requests, or cancels tasks mid-development because they thought of something better. Or when your team sits around for 5 days arguing about whether to indent with spaces or tabs. Or upper management decides to "accelerate" the process by constantly inserting new members into the team. Or someone intentionally tries to sabotage your project because they have a "competing" project in the company (or possibly just because they see you as a threat to their eventually triumphant march to the heights of the org chart). Or your lead developer decides that today is the day to institute a national "bring a firearm to work" day. In those cases your schedule is fiction, no matter what process you used to create it.
BTW, all of those things have happened on teams I was on in my career :-). Incidentally, not having a firing pin in a weapon is not considered evidence that it was "just a joke", strangely enough...