I’ve never worked on anything large in software where the time it will take can be reasonably deduced at the accuracy some people here seem to assume possible. The amount of unknown-unknowns is always way way too large and the process of discovery itself extremely time consuming. Usually it requires multiple rounds of prototypes, where prototypes usually require a massive amount of data transferred to adequately mine for work discovery.
The best you can do is set reasonable expectations with stakeholders around:
- what level of confidence you have in estimates at any point in time
- what work could uncover and reduce uncertainty (prototypes, experiments, hacks, hiring the right consultant, etc) and whether it is resourced
- what the contingency plans are if new work is discovered (reducing specific scope, moving more people (who are hopefully somewhat ramped up), moving out timelines)
I think this is the most important. You can't just HAVE contingency plans, but you need to be clear in who you need to get approval / sign-off on those contingency plans and who you need to notify. As a developer, knowing that you're going to need to drop Feature B to hit your deadline, but being unable to get the right people to approve dropping Feature B is endlessly frustrating and a massive waste of time on any project.
In my experience this is a really hard conversation and you have to build a lot of relationship/trust (aka politics) within the company to be direct about it. But it saves you and your team from burnout, because it eliminates the expectation of “if you fall behind you’ll work 80hrs/wk until the timeline is caught up” which is what I’ve seen happen too many times.