Earlier quoted context omitted.
>> They set a project delivery date and you just have to hit it. > Do you find that this really works out, in practice? Of course it works. You just redefine the project (or parts of the project) as you go, shrinking (or occasionally growing) the scope. There's nothing wrong with a fixed delivery date, provided you can adjust scope and/or resources (to some extent) to compensate.
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 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.