If a project must have a deadline then I think there needs to be flexibility on what features are included.
For some features you can only know how long they will take once you get started on them. The overall business requirement has a deadline, but individual features may not.
The worst kind of deadlines I've experienced are we must have X by Y date, where the Y date is imposed by someone outside of the team without really thinking it through, and the only way to achieve it is via overtime and cutting corners.
This can also happen when you the dev says "10 days" then they get haggled down to "2 days" by their boss. Having split the thing up into 100 pieces and have those pieces individually negotiated, you end up with a hack solution. That kind of project, one way or another is going to go to shit. It may be delivered on time but it'll be a turd. Or it will just be late.
Absolutely. I’m in the midst of a project like this right now. PMs and Devs suggested a launch date of August/September but the Execs arbitrarily mandated mid-April. So, design gets rushed, Devs have to work overtime and half bake everything, and what should have been a great new venture for the company is probably going to be dead on arrival.
> where the Y date is imposed by someone outside of the team without really thinking it through
From my experience this is arguably the biggest factor I have seen for a project to fail. Not all realistically planned projects are successful but unrealistically planned projects become woolly very quickly.
> when you the dev says "10 days" then they get haggled down to "2 days" by their boss.
Devs are typically optimistic in their estimates. Having someone who won't do the work put any kind of downward pressure on an estimate is a great way of getting uninformative estimates.
In my experience this is largely a function of environment.
If you give a realistic estimate and constantly get "stop padding your estimates" or "this needs to be done quicker" in response, after a while you start giving hopelessly optimistic estimates.
You might be right, however what I've often observed is that people will estimate a task based on how long it would take them to do it if that were their only responsibility. They often ignore the fact that they don't get a full days worth of solid, productive coding due to meetings, build problems, releasing, code review, recruitment, fire alarms, sickness, status reporting...
As I recall, at IBM they used to give 3 estimates, best / expected / worst case, and then weight them something like 1/3/5 to get the planning estimate.
One person I worked with recorded estimate vs actual for multiple years. They were frequently an order of magnitude out.
For some features you can only know how long they will take once you get started on them. The overall business requirement has a deadline, but individual features may not.
The worst kind of deadlines I've experienced are we must have X by Y date, where the Y date is imposed by someone outside of the team without really thinking it through, and the only way to achieve it is via overtime and cutting corners.
This can also happen when you the dev says "10 days" then they get haggled down to "2 days" by their boss. Having split the thing up into 100 pieces and have those pieces individually negotiated, you end up with a hack solution. That kind of project, one way or another is going to go to shit. It may be delivered on time but it'll be a turd. Or it will just be late.