Software Development Project - Early Estimating Help

You can't.

They want an estimate but they don't want to provide the parameters that let you formulate one.

If they really need a quote, go with your dart board idea, it's as good as any.

Your only other option is to try very hard to sell them on the agile approach. Charge time and materials and let them evolve the project as it goes along. This way they can spend as much as they like. They should prioritise the most important features first and they can stop whenever they want.

There are too many open ended questions to give a sensible answer to this, as you realise.

It could be $50,000 or $10,000,000, or anywhere in between, depending on infrastructure choices, technology choices, lead times, regulatory requirements, quality expectations, etc. Without some guidance on these factors, your dartboard estimate is the best one available.

As an aside, a few thousand customers isn't exactly challenging these days, so at least there are lots of options as far as all the technology goes.

I suspect that this is a common case, so it might be worth investigating the possibility of buying a solution "off the shelf" which can be branded, rather than building from scratch, as that would no doubt be quicker, easier and cheaper.

The businessmen have different brains with technical men. They can't live without numbers. It's hard to continue the conversation if no numbers offered.

May I suggest:

1. Try to offer a rough number based on similar projects, or their rough acceptable budget as you know, or rough team size with rough months. It could be a number or a range. And tell them this is only a rough estimation with no solid ground and no responsibility. By getting this number as least they will know it probably be tens of thousands but not thousands.

2. Offer a precise number for initial meetings with all stakeholders. The meetings will discuss viabilities, collect and brainstorm specific requirements, generating user stories, thus provide you solider ground to estimate more precisely. The budget is not big for such meetings and they should be able to accept if serious.

3. The rest would be typical Agile workflow. Estimate stories, define MVP, plan sprints blah blah.

Just my two cents.

This is a difficult position to be in. It is hard to estimate when there is no concrete data. You need to find a way to move this forward and facilitate the conversation.

Here's how I would do it - Create a strawman by assuming what you need to get the estimate - scope, scheduling and quality. State the assumptions clearly. Then present, review and iterate. Everyone ends up with an idea of what the scope is and what is involved in getting the estimate itself.