That is not my understanding of what most large companies do. Over and over I talk to people who have to deal with fixed dates and fixed scopes. The common outcomes seem to be:
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".
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.
I think it depends on the company. I've worked inside organizations where that be entirely unacceptable. The date and feature sets are both fixed in advance and are treated as immutable. Nobody would say what you said, but if they did, they'd be on their way out.
Indeed, there are many wrong ways to go about doing things. That doesn't mean there aren't also correct ways, and companies who do them that way. In many cases, big projects at large companies require a date. This is how you accomplish that goal.
Here we get to what I think of as the heart of the problem. Projects don't require dates. High-status humans in control-oriented systems sometimes choose to require dates as a means of feeling in control.
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".