The key is to over communicate. When I'm managing a project like that in a situation like that I send an email similar to this:
As it currently stands our team will not make the deadline. In order to meet our priorities, I would like to redefine "feature A" to exclude "component Z". This means we will have to do manual work around X. The following alternatives are available: (A) change the deadline, (B) move feature A to next release, (C) remove some other feature". In the absence of any other guidance I'll direct the team to follow the plan above. Happy to discuss further.
I've always found this is a pretty effective strategy. Big companies aren't often dumb, you just need to know how to operate in them.
The outcomes I describe above aren't some strange, rare occurrence. They are the normal outcome for projects formed around arbitrary scope/date choices. But people keep doing it. Indeed, they often can't even conceive of alternatives. Why is why, as here, people speak of the choice as an intrinsic property of the project rather than a consciously made decision among a variety of approaches.
This isn't a human universal, by the way. All of this is an outgrowth of western 20th century business culture and management techniques. But it is so much the dominant culture now that alternatives are literally unthinkable for a lot of people.
1. Wait until the date is close. Redefine scope in a panic so that success can be declared.
2. Wait until the date has arrived or is past. Have rounds of tears and/or shouting; pick a new date and scope, often as illusory as the first.
3. When the date arrives, ship whatever terrible garbage you happen to have and declare victory. Spend the next N months "fixing bugs", which mostly means "finishing half finished features".