A rule for failure:

David Gristwood has published an essay on the 21
Rules of Thumb – How Microsoft develops its Software . One of these
rules is “Never trade a bad date for an equally bad date”, and what he
means is this: if you have to slip, make sure you’re successful hitting
the new deadline, else credibility and morale will suffer. I was
expecting a different reason for this rule. Here’s a problem that even
affects non-programmers.

When a project has an impossible deadline, people working on it will say so, be depressed, and grumble. But they will keep working on the project (do they have a choice?) and in their minds they will think opposite, success-oriented thoughts like this:
“They really want to finish the project in a month, so they must assume we will take horrible risky shortcuts.” “They really want to finish the project in a month, so they don’t mind if we use inferior materials and leave stuff out. "Maybe it IS possible to finish in a month if we skip testing for defects.” After a few of these attempts to meet the impossible deadline, the work is so messed up that it will not meet subsequent deadlines either. Bad dates make the work regress.