Scope creep is a big one. This is one area where as a PM you've got to take as much a stand as you're capable of making when it starts to happen. I know you've got to pick your battles, but 2-3 "little" additions may cause more trouble than 1 big one.

There is a saying in PM circles, "Pad is bad." This is the idea of building in extra time to ensure you have enough time to meet deadlines. Pad IS bad. If you're just adding time to be adding time, that's not good. You're going to get scrutinized when you come in WAY under estimate or someone notices no one working because the deadline is too far in the future and the work is about done. But it's not unrealistic as a PM to consider the politics, the likelihood someone is going to get pulled off a project, the fact that people are going to take sick days during the wintry months, etc., and adjust times based on that. Sure the developer told you 20 hours, but if said developer is production support, perhaps 24-30 hours is what you give the task because you KNOW said developer is going to get pulled off and he or she is going to lose time trying to switch off to work on production and then switch back on to work on the project then switch off and then back on, etc.

As to the original question, as a PM I sit down with my key people (tech leads, critical stake holders) and I take a look at why we're behind. A lot of people say come up with a plan and here's what I tend to do. We discuss what the main causes were and if they could have been avoided (because managment is always going to ask). We discuss which of these causes could repeat themselves (if John is always calling in sick when a new XBox game releases, don't expect that to change without intervention). We discuss what the critical path items are, what we can do to get them back on-track, what work we can postpone, what work we can cut unless we find time later in the project, where we might gain time back later in the project, etc. You get the idea. For features that aren't critical path, we look at the estimates for them. We rack and stack them. Management may decide that cutting some features that aren't crucial is the best way to save time and money. Give 'em the knowledge to make that decision. And above all, keep a level head. If you're screaming the sky is falling as a PM, everyone else, including management, is going to start getting worried, too. And that always slows things down, making timelines worse.