The one line answer
There is probably nothing you can do now, but you can plan to improve over time.
Ask your business partners how long it will take them as a team to mow the grass surrounding one of the hotels in your town. Most likely they won't be able to do it, because they've never mowed the lawn of a hotel before. However, if they mow that lawn, and then you ask them to estimate how much to mow the yard of another hotel, they will be able to give you a slightly better estimate.
Keep doing this over the course of the whole summer, and after a few months they can probably tell you with a fairly high level of accuracy how long it will take for any hotel, once they've seen and measured the hotel in person. Even though every hotel is different, they will be able to break the job down into pieces ("mow around the pool", "mow around the entrance", etc), estimate each piece reasonably accurately, and thus estimate the entire job.
Plan to do better
There is no way to look at a specification or idea and estimate how long it will take. However, if you are able to break a project down into a set of stories and accurately estimate the amount of time it will take to do each story, you can then use the historical velocity of your team(s) to predict when those stories will be done. With a mature team this can yield fairly accurate results. You still won't be 100% correct, but the probability is high that you will be pretty close.
The trick here is that this only works well for experienced, mature teams. There are two variables in play that are hard to stabilize. First, your team needs a stabile velocity. That is, they need to be able to regularly produce X units of work in a fixed period of time. Once they are able to do that, then it becomes much, much easier to estimate new stories because they have a frame of reference ("we spent Y time on feature A last month, and feature B is about as hard as feature A, so we expect to spend Y time on feature B, too").
When you have that stable velocity, you need to use what you've learned to estimate stories. This means that stories need to be small, no more than few days worth of work. Once you are able to accurately size your stories, the deadlines largely become an exercise in mathematics.
All that being said, even the best of teams can't predict what will happen over the course of several months. Make sure your releases (even if only internal milestones) are relatively short. Work on a couple months worth. Hit that goal, then use the data to figure out how much you can do in the next month or two. Hit that goall, then lather, rinse, repeat.
- Giving accurate estimates is hard, because for many teams every project is like doing something new.
- Giving accurate estimates is a skill. Like other skills, it takes practice.
- Giving accurate estimates requires team maturity.
- Giving accurate estimates requires that the feature to be built is well defined (ie: broken down into estimable chunks).
- Giving accurate estimates requires commitment. When your team gives an estimate, they need to commit to doing what they said they would do. This will force them to take estimation much more seriously.
One final thought
This isn't a software engineering problem, and this isn't a business team problem. This is an organizational problem. The organization needs to learn to work together to determine how much can be done by what date. It's not you versus them, it's us.
nothing. For any other answer they would have to change the question or you would have to start to lie to them.