[johan_larson]

I agree with you that it is not possible to both fix the feature set and fix the delivery date and expect to consistently succeed. But it is also not possibly to tell upper management, who are dealing with a whole other set of difficulties, that they have to pick a feature set or a delivery date and that's all there is to it. If you do that, they'll reject your advice, and find someone else who'll give them a more palatable message.

The best I can come up with is the notion of a double contingency plan. Engineering agrees to a set of functionality to be delivered and a delivery date. This is inevitably going to be a bit optimistic, because people consistently overestimate themselves.

To deal with that, the first contingency plan addresses the question of what should be done if things are not converging to the ship date. The plan here is to keep the ship date, but ask hard questions about what bits of functionality actually need to be kept. What are the actual P0 - MUST HAVE features?

The second contingency plan addresses what is to be done if the first one fails. At this point engineering has already done all they can. They have pushed as hard as they can, and they have deferred every feature that is deferrable. They are down to the actual MUST HAVEs. Now the rest of the organization has to figure out what to do with a product that is inevitably going to be late. What is the alternate ship date? What customers are going to be really unhappy. And so on.

It seems to me any large engineering project should think out these contingency plans in advance. What will they do if making the deadline starts to look daunting? And what will they do if making the deadline turns out to be impossible?