(Other than blaming the developers)
Rule number 1. The estimate is never wrong. If you even think the estimate is wrong, re-read this rule and get enlightenment.
Rule number 2. The developers who will actually do the work are NEVER the right people to make the estimate. Estimates must always be done by the same person to make sure that they are consistent. Consistency is the key to ensuing that the estimate is right.
Rule number 3. Analysts should NEVER be allowed to estimate their own projects. The analysts have too much self-interest involved in the project gong ahead so will always produce over-optimistic estimates.
Rule number 4. Estimates must be made well in advance of assigning staff to a project. After all it is impossible to assign staff to a project until it has a budget, and a budget cannot be assigned until there is a good estimate.
Rule number 5. Senior project managers are the best people to create the estimates because they can easily create an estimate that is within 25%. The very best project mangers can create even better estimates given only a vague description of what is needed.
Rule number 6. Developers and analysts who complain about inaccurate estimates just do not understand the process and need to be told about rules 1 through 5.
Q: What bozo came up with those rules?
A: I'm not sure, but that bozo sure works for a lot of companies. He (invariably a male) even manages to get promoted to even higher levels of incompetence based on the promised land created by these fairy tale estimates.
Q: But what happens when the inevitable happens and the project misses the due date?
A: Not much. There is usually someone else to blame. The best tricks to shift the blame are to talk about "scope creep", new requirements, being let down by vendors, incompetent developers, bad luck, unforeseen circumstances, other projects impacting delivery, etc. It is amazing how far projects can overrun and still nobody is held accountable. The record I have seen so far is over 6 years late, but even more amusingly I have seen lots of "that should only take them 2 weeks" projects take more than a year to complete (assuming they they ever delivered anything useful).
Q: But surely something happens.
A: Sure does, the project team gets stressed out delivering crappy software, and then get stuck trying to support an unmaintainable heap of garbage. But that is not a problem for the person who made the estimage, it just means that the project was staffed by a bunch of worthless losers.
The traditional way of estimateing and running projects is broken. I support the Agile Software Development approach because it allows projects to be successful without imposing undue stress on the team members.
Software development is meant to be fun, if it isn't the process is wrong.