You don't need to have a deathmarch

When creating project plans make sure that you define some interim milestones for the development phase.  Interim milestones allow the development team to see measurable progress and provide key stakeholders with visibility about the progress of the project.  Interim deliverables are also used to keep bottlenecks to a minimum and to reduce complexity when it comes to things such as testing and regression testing.

Recently I've seen a couple of projects become unstable through a lack of clearly defined interim deliverables. 

In his presentation titled: "21 rules of thumb for shipping Great Software on time", Jim McCarthy talks about how an application is like a big bowl of jelly and how it is important to get to a known point and stay there.  Getting to a known state allows the jelly to stop wobbling and again gives everybody with a clearer vision of measurable progress.  The projects that I've seen go pear shaped were being developed in a fashion whereby it was not possible to get to a known state until the end of the project.

Recently, on one very recent project (which had a particularly low morale and was showing clear signs of being a Colonel Kurtz project) I was able to turn momentum within days by simply laying out some important interim milestones and hitting them early.  These deliverables were designed to get important features to a "complete" stage and into test quickly which had a positive knock-on effect of restarting the communication between stakeholders as feedback trickled back from test into dev and up the chain of command.  Everybody was energized and the juggernaut lurched forward; momentum is good.

Last word... interim milestones should mark important peaks.  Don't set interim milestones around trivial marks.