Possible Duplicate:
What can I do to get better at estimating how long projects are going to take?
Closed for duplication. For googlers and such, some of the dupes that contained good information:
You've got at least 3 red flags in your question there (to a developer's ears):
The traditional software development lifecycle never worked perfectly because it depended way too much on educated guesses about the future, usually assuming ideal conditions. There is much less stress for everyone involved to follow a more iterative, agile methodology if you can get enough devoted business/client time and decision makers to understand why it's better.
If most organizations spent more time/money on joint application development sessions and less time/money on writing instantly obsolete specifications and estimate documents there would be a lot less wasted money and lot more IT projects completing successfully...
In the immediate term at the very least try to keep the development team intact for the duration of the project. Humans take a while to learn how to interact productively with one another. Take a look at Tuckman's work on the psychology of highly effective teams and his 4 stages of group development (forming, storming, norming and performing). The bottom line for you there is that changing a team's composition throws the whole team back to the bottom rung of the ladder because they all need to learn the social rules of the group anew and will be less productive until they do...
I apologize in advance if I don't have a lot of positive suggestions regarding your current situation, but if you can shift your environment to work more intelligently over time you and those around you will be a lot happier in the long run.
Well, to get an accurate delivery time with too little resources you can reduce features or quality. It is easier to get accuracy by reducing features :)
I give an initial size in ideal iterations for the current set of specs as far as I currently understand them. Then I plan the next iteration (two weeks) and look ahead about two iterations. I collect new and changed features in a backlog. That tends to grow, and once in a while I re-estimate in iterations. Managers tend to be bad at understanding the 'as I currently understand them' and 'ideal iteration'. After a while I can tell how much time a real iteration takes (or how many features really get build in a timeboxed one) and I can reestimate. A growth factor of three is not abnormal.