"Sure I can do this in 3 weeks."
Then shows up once every two weeks and finishes around the four month mark.
"Sure I can do this in 3 weeks."
Then shows up once every two weeks and finishes around the four month mark.
"Yes we can do that in three weeks. We need the API documentation for _those_ two systems, network access to _those_ resources, and credentials to log in to _those_ services first."
2 months later we're still waiting on critical pieces of those prerequisites, while someone's screaming that the deadline they'd committed to with the customer was 5 weeks ago.
The most important part of this process is getting it in writing so that you can slap them with it later.
the problem comes when you didn't know you need Y, Z or W until the work actually starts.
1) You improve your foresight so you can get your manager rolling on getting resources early.
2) You have a concise record of what you think you need. If you notice something else mid-project (which does happen even in otherwise-straightforward implementation projects), you have a concrete point at which to raise a flag to stakeholders.
If you have zero confidence in an estimate from the beginning, then there is no point where its natural to realize “oh hey, this is going to overshoot and I need to communicate about it.”
But was not estimating the actual total time until completion which must include all the lead time, waits and dependencies.