Those that didn't work, started with the management saying (nearly at the end of the plan) "we are late, crunch time". People felt that things were poorly planned, deadlines where imposed from above, and all those things developers think at those times. End result: we made the dates... with a lot of effort, a lot of "burn down", and alot of defects.
Later on the same project but different release, priorities changed, new requirements came, and the deadline was no longer "achievable", We negotiated a new reduced scope, but even the reduced scope was not possible under normal circumstances (scope could not be reduced further because monetary penalties for the client were at stake). Result? We told that to the team, and curiously enough the TEAM declared "cruch time, let's hit that deadline!". High morale, High energy. One month later, we made it. With a lot less errors than the last time.
Yes, crunches work some times. The interesting thing is identifying why those "some times" it works.
When management declares "crunch time", and the team feels that the plan was impossible to begin with and that it was a known fact since the beginning, the crunch will fail (low morale, low productivity, etc,etc,etc). But if the team feels that the plan was achievable, and that what happens is just a roadblock in an otherwise clean road, they will "do their best" to hit the deadline anyway (programmers are stubborn optimistic beasts). Management must just take care that no one burns out due to overwork, the sense of purpose will give the morale and energy needed.
So, at the end, if you manage your project correctly and "crunch time" is due to an unforseen cause the team will help you to hit the deadline. If you mismanaged the project, the team may save you once or twice. After that, they lose trust and will eventually leave.
Good luck, and Happy Blogging!