[tsimionescu]

Deadlines and delivery dates are the same concept.

The alternative the article proposes is entirely different - it proposes a work queue system, where the team is always working on the most important current task(s), and where every task that is taking longer than some pre-determined number of days is re-evaluated to make sure it is still as important as believed.

> Sales team needs that thing by December 1st? Don't ask for it on November 29th. Put leeway into the model by giving time for the delivery date to be missed. It's called contingency.

That's not how the article thinks. Instead, it views it as "sales team needs some task done by some date? move it to the top of the work queue as soon as you know about it and the team will finish it as fast as possible anyway". Will that be before or after December 1st? No one knows, no one cares: it will be done as soon as possible.

For inherently fixed scoped tasks (say, "our product must ask users for consent before collecting data"), this can work fairly well. But I don't think it is realistic for the vast majority of work, which is far more vague in terms of scope.

[hef19898]

Heck, sounds a lot like my current place! A lot of talk about "critical path", agile and sprints everywhere, even on the hardware development side, a lot or reprioritization going on. And guess what, all prmosed dates and schedules are constantly missed. Mind you, that the whole place is living of investor money and needs more that rather soon.