What I've found most effective is Robert L. Read's recommendation on how to fight schedule pressure. Here's what Read writes:

The key to fighting schedule pressure is simply to turn it into time-to-market pressure. The way to do this to give visibility into the relationship between the available labor and the product. Producing an honest, detailed, and most of all, understandable estimate of all the labor involved is the best way to do this. It has the added advantage of allowing good management decisions to be made about possible functionality tradeoffs. The key insight that the estimate must make plain is that labor is an almost incompressible fluid. You can't pack more into a span of time anymore than you can pack more water into a container over and above that container's volume. In a sense, a programmer should never say ‘no’, but rather to say ‘What will you give up to get that thing you want?’ The effect of producing clear estimates will be to increase the respect for programmers. This is how other professionals behave. Programmers' hard work will be visible. Setting an unrealistic schedule will also be painfully obvious to everyone. Programmers cannot be hoodwinked. It is disrespectful and demoralizing to ask them to do something unrealistic.

When you say that the project is "headed for failure," that's based on your assessment of what tasks need to be done and how much effort each one of them will require. Make that assessment explicit, understandable, and detailed. Separate tasks into their component parts; explain in as much detail as you can how development time will be spent.

Once you do that, you have a solid foundation for discussing concerns with management. In all probability, once you've broken down your assessment into all the specific tasks that need to be completed, you will be able to demonstrate that the job takes more time than you have - possibly much, much more.

Once you're discussing this detailed schedule with your manager, be prepared to be flexible. Your manager might say "Task X won't take a month; it'll take a week at most," or "Task Y is entirely unnecessary, cut that from the schedule." You can certainly discuss these points, but what's far more important is to reach an understanding between you and your manager on some realistic version of a schedule. That way, if you're not being allocated time for, say, testing, then you've got an explicit directive not to test, rather than just running out of time "unexpectedly". And it's definitely possible that your manager is legitimately willing to explicitly cut certain corners in order to ship on time - there's plenty of cases where that's a perfectly reasonable call!

The estimate gives you concrete substance to debate and discuss. It puts you on the same page; it helps you feel confident that your manager has taken your concerns into account. And it brings you to the point where if your manager is plainly asking the impossible, it will be perfectly evident to both of you. If the project is well and truly doomed, you will have made that clear, and it will be up to your manager to decide precisely how he wants you to spend your time.