I would say an approach closer to the Heisenberg uncertainty principle would make more sense. The more information specified that can't be changed about the expected product the less information is available about the deadline, ans vice versa. Thus, the desired balance could be used depending on the situation, goals, budget, etc.

That was briliant and is already added to my quotes list.

Should I attribute it to xvilka or did you get it from somewhere else?

I think, it's my own idea but you never can be 100% sure, some kind of uncertainty always persist.

I'm not all to familiar with this kind of thing so I could be missing something, but what is a deadline without a deliverable? Surely "We will do something (literally "something", not a stand-in for X) and it will take a month" is worth nothing?

I worked for several years on an extremely large and popular sports news/results website, meaning all our deadlines were absolutely set in stone by the outside world – sporting events start on specific dates. The Tour de France sure as hell ain't gonna postpone a few days until we've finished our team profile pages.

So we committed to a deadline, but not a single deliverable. Scope would shrink and grow as delivery of each component progressed. Well in advance, for each major sporting event in each country where we operated, we would scope out literally every single thing we'd like to deliver, and then start work on the components in priority order. In each planning session as the event approaches we'd appraise whether we still have time to realistically deliver the next priority thing, and if not we'd skip it and move to the next - those that got missed out could wait until the following year (when the major features already delivered would need to evolve, not be implemented from scratch).

I learnt a lot from working on sports. Having third party deadlines that no-one could bitch about made us an extremely effective team at planning, estimating, and ruthless scope reduction.

You can have a fixed scope with a flexible timeline, or a flexible scope with a fixed timeline. If you try to have both, you'll incur an additional cost, which most companies avoid. It's a well known law of project management and software development.

“Ok awesome! Glad to hear you’ve committed to deliver widget, when do you think it will be done? We have four business units that were going to use wedgie but that’s getting decommed next year and they’d much rather avoid a pivot.

Oh and change restrictions start in six weeks, don’t forget that. BTW what’s your team’s vacation schedule looking like? We only get to roll over 7 days this year, hopefully they took some this summer haha!

Ok so anyway really would like some estimate that i can take back to product, you thinking January? Maybe get something up in test that they can kick around in what, a month?”

Etc etc.

"No."

It's remarkably powerful.