If you can't change the deadline, there is too much work and you don't wanna go into crunch mode, you have to cut features. I personally use a gant chart and a

If you can't change the deadline, there is too much work and you don't wanna go into crunch mode, you have to cut features. I personally use a gant chart and any other planning docs that make sense when scheduling a project. It helps to make my case for cutting features and convincing management of things that we can delay to a 1.1 update. I find that people respond pretty well when I can show them a visual chart with sensible looking numbers and they can also see how hard everybody will be working. I also have a few tricks for figuring out which things can be delayed without a major impact on a launch. For example if your system will automatically bill customers monthly - then you have 30 days after launch to get the automated billing working and nobody will know the difference! Lot's of little admin things like that can be delayed without customers or management even noticing that you are cutting features. I'm pretty much a stickler for trying to get things done without ever going beyond our standard work week hours. It's usually pretty tough the day or so before a big launch for everybody though - not just the programmers. Somewhat human nature I suppose - some unplanned thing always reveals itself at the last minute.