This is actually a good answer.  If we knew how long it would take to finish this project, we would also know how long it would take a given horse to finish a race, or when a stock would hit a certain price point on the market.  We wouldn&#x27;t need to be working on the project because we&#x27;d be inordinately wealthy.<p>All this talk of medians and means assumes that you&#x27;ve done the same thing many times before (otherwise you wouldn&#x27;t have those statistics).  In software, if you&#x27;ve done it before, then it&#x27;s already done so the estimate is zero.<p>Projects always involve doing new things, new requirements, using new technology, techniques, or tools; targeting a new system, and&#x2F;or using new processes and people.  New requirements, constraints, market situations, priorities, and discoveries rise up during the project.  Sometimes all of the above.  Past performance is not a predictor of future results.<p>It&#x27;s more realistic to flip it around.  Prioritize the most-important requirements and set an initial deadline.  Then you&#x27;ll get something (the most important stuff, or at least some progress towards it) by the deadline and can decide whether to add the less important stuff afterward.<p>When doing that, quality and other intangibles need no longer be overlooked but become part of the prioritization.  Do you want high quality, or more stuff by the deadline?  Do you want the team functioning well for the long haul or is it worth burning them out to rush this, then having downtime afterward?<p>To get more control, shorten the deadlines to the minimal point where you&#x27;re still getting deployable chunks of acceptable quality.  That acknowledges the inherent uncertainty and gives better control and visibility than just making up a random number (or 3).