4 ms·

What's the polite way to tell them "there's not a chance I, or any other reasonable person, would consider this request" and keep the door open to future work?

What's the polite way to tell them "there's not a chance I, or any other reasonable person, would consider this request" and keep the door open to future work? Or is it not worth keeping that door open?

aghast 13y ago
If they're dumb enough to make that request, I bet they're dumb enough to be swindled themselves. I think you could have a lot of fun with that conversation, if you're quick with your wit. It might even be profitable, if they'll stupidly agree to something silly in a legally binding manner. Like: "Hmmm... I dunno... Well, okay. I'll charge you $5,000 to for my consultation on assembling the list. But I have to charge you a fee for each subsequent amendment to list. Once you've paid for my consultation on the list, then we can talk about the actual cost of the work itself, and whether you want to pay me to actually do anything."
acdha 13y ago
I used to give them one attempt at education as to why software development isn't off-the-shelf if it seemed reasonable that they might simply be new to that sort of project. In practice, though, it was almost always the case that they were simply being unrealistic and hoping to find someone new / desperate who would give them more than what they paid for.
- wildgift 13y ago
  How well do those projects go? I've had bids rejected for being too high, even when other developers failed to deliver due to underbidding. Some people never learn.
  - acdha 13y ago
    In a couple of cases, it went well – there are people who genuinely appreciate being educated about what they as a businessperson need to know about approaching software dev. Sadly, it's a definitely not a high success rate: if you don't get an impression that the conversation is going well, there's probably a good reason for that.
A1kmm 13y ago
Many small non-tech businesses don't know much about IT project management, so it can be worth trying to educate them and convince them to have reasonable expectations. I would start by explaining that there are 6 project management variables: benefit, cost, scope, risk, time, and quality, and that you usually can't change one variable while holding all the others fixed. Scope in particular is an important issue to discuss with clients who want a fixed price; explain that unless the scope of the project is fixed, your risk is unlimited but your revenue is fixed. I suggest offering, as an alternative, cost estimates with tolerances; in other words, offer a time and materials contract, with a best estimate of the costs. In addition, agree to a tolerance - if your revised forecasts suggest you will exceed the tolerance at any point, you will contact the client and give them the option of cancelling the project and paying only for costs already incurred or setting a new higher tolerance. If a client really wants a fixed price contract, consider breaking the project down into smaller, lower risk, very well defined tasks, and contracting each one separately (and only quote later tasks when you have more information available from earlier ones, so you can add tasks for things like a second design iteration). Ensure that tasks which are already completed are paid for before new ones are undertaken, and that you have the contractual right to quit and still get paid for the tasks you completed.

aghast 13y ago

If they're dumb enough to make that request, I bet they're dumb enough to be swindled themselves. I think you could have a lot of fun with that conversation, if you're quick with your wit. It might even be profitable, if they'll stupidly agree to something silly in a legally binding manner. Like: "Hmmm... I dunno... Well, okay. I'll charge you $5,000 to for my consultation on assembling the list. But I have to charge you a fee for each subsequent amendment to list. Once you've paid for my consultation on the list, then we can talk about the actual cost of the work itself, and whether you want to pay me to actually do anything."

acdha 13y ago

I used to give them one attempt at education as to why software development isn't off-the-shelf if it seemed reasonable that they might simply be new to that sort of project. In practice, though, it was almost always the case that they were simply being unrealistic and hoping to find someone new / desperate who would give them more than what they paid for.

wildgift 13y ago
How well do those projects go? I've had bids rejected for being too high, even when other developers failed to deliver due to underbidding. Some people never learn.
- acdha 13y ago
  In a couple of cases, it went well – there are people who genuinely appreciate being educated about what they as a businessperson need to know about approaching software dev. Sadly, it's a definitely not a high success rate: if you don't get an impression that the conversation is going well, there's probably a good reason for that.

A1kmm 13y ago

Many small non-tech businesses don't know much about IT project management, so it can be worth trying to educate them and convince them to have reasonable expectations. I would start by explaining that there are 6 project management variables: benefit, cost, scope, risk, time, and quality, and that you usually can't change one variable while holding all the others fixed. Scope in particular is an important issue to discuss with clients who want a fixed price; explain that unless the scope of the project is fixed, your risk is unlimited but your revenue is fixed. I suggest offering, as an alternative, cost estimates with tolerances; in other words, offer a time and materials contract, with a best estimate of the costs. In addition, agree to a tolerance - if your revised forecasts suggest you will exceed the tolerance at any point, you will contact the client and give them the option of cancelling the project and paying only for costs already incurred or setting a new higher tolerance. If a client really wants a fixed price contract, consider breaking the project down into smaller, lower risk, very well defined tasks, and contracting each one separately (and only quote later tasks when you have more information available from earlier ones, so you can add tasks for things like a second design iteration). Ensure that tasks which are already completed are paid for before new ones are undertaken, and that you have the contractual right to quit and still get paid for the tasks you completed.