One of the most problematic situations that a delivery team can find itself in is when its stakeholders have expectations of a fixed deliverable by a fixed date. Generally speaking if a technical project ties itself to a pass/fail situation then it will fail. This is by no means true all the time, but it’s more true that not. It may even be a self-fulfilling prophesy—if the team thinks it can’t succeed why (its people will be inclined to think) should we bother?
The trick, really, is to avoid binary outcomes. Avoid the pass/fail situation in the first place by structuring the work to build up something of increasing value. This means first understanding what value is, and then creating something that continually evolves to bring more and more of that value over time. The question then is not whether you will succeed, but how much you will succeed.
I was once working with a team delivering to a (genuinely) fixed deadline, and there was great, and justified, concern among the senior stakeholders whether key functionality would be in place by that deadline. In the midst of one rather tense meeting the product manager said “I understand there is concern over whether we will have a marketable product…” He didn’t get any further, as the COO interrupted him, saying “Of course we’ll have a marketable product.” The COO understood precisely that failure was, quite literally, not an option. What was in question was the degree of success. The notable thing about that team was they had structured themselves and the project six months earlier to ensure they they could deliver the value incrementally. Prior to that the COO might indeed have been looking at failure as option.
Even in these kinds of projects milestones are still valuable as checkpoints for review. But structuring the work away from binary outcomes and more towards delivering value incrementally tips the probabilities in favour of more success for everyone.