You bring up a specific challenge, how to handle it when you realize a deadline is probably going to be missed. That's one aspect, but you also need to look at why your deadline is going to be missed more broadly.

Here are some challenges that come to mind in software estimation:

1. Estimates are almost always done too quickly, with too little information. If you can wait, spend more time, or reduce the unknowns, do so. If nothing else give it an extra fifteen minutes. If you can say "I'll get back to you with an estimate by ..." (e.g. tomorrow or end of day) that's even better.

2. Estimates are ranges, a probability that the work will be done across a range of time. but are often given as a specific date or amount (e.g. "It will be done tuesday/take 5 working days"). Early or quick estimates may be ranges of 15x or more (e,g, "it will be eight hours to three full work weeks"). Don't be afraid to capture that ambiguity in a range. Others may not understand ranges, so give them the high end if needed, but at least be aware that ranges exist. Often ranges, or high estimates get push back. This is your opportunity to specify what questions need answers, what requirements need refined, and what areas need more design and architecture to reduce ambiguity. These things can reduce ranges of estimates.

3. Know the difference between estimates, targets, goals, and commitments. Confusion between these leads to miscommunication and frustration. Often we'll make a guess like "maybe two weeks" which is a wild instant estimate, and others will see how nicely that lines up with their target date, and believe you have committed to that goal. Commitments should be explicit, and part of your process.

4. Do not negotiate estimates. Managers are trained to negotiate, and a naive manager will almost always reduce estimates through negotiation, which is a distortion of reality. Developers should collect the information they need about the requirements, ask questions, then produce their estimate in isolation, and refuse to change it. The way to change an estimate is to change the requirements, often addressing ambiguity and questions, and re-estimate the work given the new information. This is hard to do, because a "better" timeline can make everyone feel better in the moment, but will lead to problems later.

5. Renegotiate when change happens, or when you are in danger of failing a commitment. This one answers half of the original question, to my mind. If you didn't make a clear commitment, or requirements are changing with out any renegotiation, you have to fix those first. After that, keep a close eye on scope creep, and changes. Change happens, accept that, but make sure that those you have commitments to understand that change has impact on your commitments, and you can either commit to the original work and timeline, or you can commit to the new work, and a new timeline. Holding you to new work on an original timeline is not fair to you, and not a problem to be solved at the developer level. This one can be quite challenging, some people use "change management", itemized / ticket based change requests, even explicit signoffs. If you have trouble here, find what works for you.

6. Learn from history. You won't get it right. A lot. Keep track of how you are doing, improve processes and spend more time refining requirements/acceptance criteria etc. Make sure commitments are negotiated and explicitly agreed to. Keep learning.

7. You will make mistakes. If you uncover new questions, requirements, found work, it was in a certain sense an estimating error, but it has a different fix. If you had a reasonable view of the work to a fair level of detail and spent reasonable time on the estimate, and are still missing your commitment, you have made a mistake. That's OK, especially early on, or in new areas for you, if a team has shifted etc. The answer is, communicate. Let your manager know immediately, as soon as you realize it, that you feel you are at risk of failing a commitment, and you need to revisit. From there, you can investigate the new work, or re-estimate based on your increased understanding of the problem. Perhaps note some data for your historical tracking. Learn. Next time, make a better estimate. It does feel bad to miss a commitment, or even to not make a deadline that someone else set up. That's very human. The way to feel better about it, is to get better at it.

The above is based on my decade of experience as a software developer, and a solid foundation from Software Estimation: Demystifying the Black Art, By Steve McConnell http://www.amazon.com/Software-Estimation-Demystifying-Devel...

I highly recommend the book as a learning resource, and having the whole team, managers included, read at least the first portions of it. It also has specific tools for various estimating challenges.