Sometimes the numbers just don't add up
I was working with some folks today on the feasibility of completing a project by a hard deadline with an immovable scope. We really really wanted to do the project, everyone was emotionally invested because we had a genuine interest in helping the client and honestly, the artwork kicked butt. (Hmm....funny how creative work gets people jazzed). I took the estimate numbers and plugged them into MS Project to see what story it told us. 
At first, the story looked horrible--2 months longer than the client needed. Then I took snapshots of what it looked like with 1 developers, 2 developers and 3 developers. It cut the timeline down somewhat, but still looked bad.
I have learned something very important over the years when building a schedule: you have to think of the tasks in a schedule like variables in a formula. X +Y = Z, where X & Y are predecessors--what needs to happen before a particular task can start. Without a developer sitting next to you, sometimes it's foolish to make assumptions--and sometimes you just have to do it. So, I did some stacking based on timelines. Developer 1 couldn't start on skinning a single blog until the site skin was complete, because resources can't do two things at once. In the meantime, Developer 2 could start on a custom module and shouldn't impact developer 1.
Anywho, even when I did some fancy stacking and added 3 developer resources, the numbers just didn't add up--there was no way we could meet the deadline. If we went forward with the project, we were setting ourselves up to fail.
One of my PM mentors, Steve Weidner, taught me that sometimes the story that the schedule tells you isn't what you want. And that's OK.