Trying to prove the impossibility of something that is never going to go away as a requirement isn't very useful.<p>An alternative would be to describe potential break-points and conditionals in the planning process. For instance, if a third party library can help you with some core functionality, it takes a few hours to investigate and an hour to implement.<p>But if it's not going to work for whatever reason, then you know you have to make your own, and the initial implementation could range from 4-6 weeks.<p>If you say "this will take either 4 hours or 4-6 weeks", that's far more useful and acceptable to management than saying "this will take somewhere between 4 hours and 6 weeks.<p>No one sane is asking for exact estimates, and no one smart is promising a hard deadline based on the assumption that nothing goes wrong. A good engineer will pad their estimate slightly for the same reason that airplanes carry more fuel than the exact amount they need to reach their destination. It's not a deceptive or inefficient practice, it's managing uncertainty.