Some unplanned problems, unrelated to the architecture, occur, which slow down the project more. No server access for some time, again. Milestones come and go. They're missed, but the end date of the new ones remain the same. You're stressed, that you won't complete the project in time. You are slow because this is your first project in this language. Not all the features are assigned to people, so you cannot plan ahead (do things that will slow down at first, but then speed up afterwards). You cannot work well because of this stress. The project slows down even more. You cannot take a vacation to free from stress, because that will slow down the project even more.
Here is another opinion about deadlines: blog.jayway.com/2010/08/12/no-deadlines/
Whole project deadlines may not work even if they are 100% accurate. The problem is, that a programmer does not know in how much time can he do a task that he has never done before. Deadlines are helpful only in repetitive tasks. And even then, only when they are very close to the achievability level. A factory worker who makes shirts and knows that he made 38 in the first 4 hours of the day, and he has to cut 80 that day, is motivated to achieve that target, by speeding up for the next hour and making 11 that hour, and having a feedback that he is now closer to the target.
Too aggressive deadlines are bad because of the stress of thinking what will happen to me because I miss the deadline, plus the fact that I try to take shortcuts (making the program less testable) that prove to be wrong (more debugging time, because the bugs are much harder to find).