The below is a joke, but sadly it is representative of most teams I have worked on.
If it's like anything that most managers do, you have the team come up with estimates, have some meetings to see if you missed anything, discover that you did, then create a schedule, remembering to add slack time for unforeseen interruptions due to people getting sick, customer issues, etc.
Then you see that the schedule is too long. Slowly but surely browbeat the team into saying "yes" to the question "do you think this can be done faster" on every task. Do this some more when someone from sales asks if something can be delivered in a particular quarter.
Get very stressed out when the real project deliverable dates align much more closely with the original estimate than the unrealistic one. Micromanage your people and stress them out. Keep freaking out as you miss every deadline in the "pipe dream" plan.
Deliver the project with a mild slip compared to the original plan (because you missed something major in the original planning as it is impossible to foresee everything). Use the twice-too-short plan as your metric though. Still, the product is awesome, so give your people a pat on the back.
Hold a "lessons learned" presentation swearing to never do this again. Speak at length about how critical good estimation is. Go on to repeat the very same exercise for your next project.
Just had an idea: maybe keep the version of the timeline from before you haggle down the dates and keep checking which one matches reality better? You don't have to tell the developers that you are doing it if you believe us programmers need some flogging to keep us coding.
I remember one of Akin's Laws of Spacecraft Design being something like: take your original estimates, multiply the time by π and shift the decimal on cost one place to the right.
What happens is that the difference between the estimate that management will psychologically accept to begin the project (and then commit to due to sunk cost fallacy) and the actual schedule is about a factor of 3.
There's a paper that gives an exact number: 1.7x. This is the average time it goes over estimates, for code and writing tasks. The other numbers seem better, but you should not go below 1.7.
I think the only thing you missed was that the original estimate also included more FTEs, but then they cut those too. This whole chain of reality was a big part of why I eventually decided I had to get out of tech. The people doing the work can often articulate the work and provide solid estimates to the work, but they will get chewed up by people with other agendas.
Or a variation on the theme: "we know this schedule is aggressive, but we have open reqs to hire another 3 engineers"... who of course never materialize.
If it's like anything that most managers do, you have the team come up with estimates, have some meetings to see if you missed anything, discover that you did, then create a schedule, remembering to add slack time for unforeseen interruptions due to people getting sick, customer issues, etc.
Then you see that the schedule is too long. Slowly but surely browbeat the team into saying "yes" to the question "do you think this can be done faster" on every task. Do this some more when someone from sales asks if something can be delivered in a particular quarter.
Get very stressed out when the real project deliverable dates align much more closely with the original estimate than the unrealistic one. Micromanage your people and stress them out. Keep freaking out as you miss every deadline in the "pipe dream" plan.
Deliver the project with a mild slip compared to the original plan (because you missed something major in the original planning as it is impossible to foresee everything). Use the twice-too-short plan as your metric though. Still, the product is awesome, so give your people a pat on the back.
Hold a "lessons learned" presentation swearing to never do this again. Speak at length about how critical good estimation is. Go on to repeat the very same exercise for your next project.
Just had an idea: maybe keep the version of the timeline from before you haggle down the dates and keep checking which one matches reality better? You don't have to tell the developers that you are doing it if you believe us programmers need some flogging to keep us coding.