Actually, this is all stuff known to project managers.
When a project is initiated, the Project Manager first creates a Project Charter. This is done by identifying stakeholders (people doing the work, people affected by the work, people receiving deliverables... any individual or group who affects, is affected by, or perceives itself to be affected by any activity or outcome of the project) and gathering preliminary project requirements. Essentially, the project manager talks to the stakeholders to roughly determine what we're trying to accomplish, how we're going to accomplish it, how much we want to spend, and how much time we're willing to take. That's written up as the charter.
After this, real requirements are gathered. Work is broken down in a Work Breakdown Structure, a hierarchical decomposition of deliverables in which each level is fully broken out into lower levels. The entire project is level 1; level 2 is the major deliverables (Including project management itself, as well as phases or components, testing, validation, documentation, hand-off, and final project closing); and those are broken out into the deliverables which make them up. The final level of deliverables is the Work Package, a complete unit of work which can be understood and managed. Work Packages are broken out into Tasks and Activities--things to do which can be assigned, and which are required to produce the Work Package.
To do all of this, the Project Manager must consult the Project Team. The Project Team will know what components go into building the deliverable output as requested. The project team will be able to estimate their competency and experience with the various components. The Project Manager will use historical information to come up with rough scheduling and budget numbers for each Work Package and Task; but the Project Team will raise issues such as that the historical information was in a wildly different context, that the people who did the work are not on this project, and so on, which means that the work may take more or less time. These factor into the baseline schedule and into the management and contingency reserves (the extra time allotted based on how likely a task should take--in theory, a programmer can write a decompression module in 4 hours, but it's 90% likely to take less than 5 hours, and a 90% success rate is targeted, so we budget 4h with a contingency reserve of 1h).
In the end, the engineers will inform the project manager of what can and can't be done, what effort goes into it, how long it may take, and so on. The Project Manager will have stakeholders prioritize deliverables, and then have them select which deliverables to cut from the project if they can't make time or budget. If the engineers tell you they simply can't build this in 5 months, you either give them 7 months or you give up enough requirements to shave 2 months off the project. You could also identify underutilization of resources in non-critical paths, and crash or fast-track the schedule by assigning more people to those tasks which may be done in parallel rather than in serial.
That's what managers are for.