You don't need software engineering literature. Conceptual probability and statistics, from undergrad, is all you need.
An estimate is just that, an estimate. It is not precise, it is not guaranteed. For any estimate, there is some probability that you will underrun it, or hit it on the nose, and some probability that you will overrun it.
Probability 101: p(underrun or hit exactly) + p(overrun) = 100%.
A schedule based on an estimate has the exact same characteristics.
You cannot eliminate the uncertainty completely. There will ALWAYS be some probability of overrun. It might be small, the probability of Iran nuking your office building, but it is still there. The best you can do is look at EVERYTHING, and reduce the uncertainty as much as you can. Once you have done that, you will, if you are lucky, have a schedule with small uncertainty, and 50% probability on each side.
Now, think about it: If you pull the schedule in, the probability that you will underrun or exactly hit the schedule decreases. The total still has to sum to 100%. Where does that probability go? Answer, it goes into the overrun probability.
General Dynamics / Fort Worth Division learned this one the hard way. They did their initial estimate for F-16C/D development, and sent it up the food chain. Somebody higher up arbitrarily cut a year out of it, and sent that to the Air Force. As a direct result, GD/FW was a year late to flight test, and the Air Force was NOT happy. (Note that "one year late" was according to the revised schedule, meaning that the original schedule was RIGHT ON TARGET.)