0

and you're basically saying that I (as the client) have to accept your solution as final even if it's your fault that the solution is worthless. How many clients do you think would pay if you tried to pull that?

If the solution fits the requirements as laid out in the requirements document the customer signed off on as part of their contract, then yes he has to pay for it.

I'd (if I found out that the actual technical needs are different from what the customer stated) notify the customer that the requirements (and thus the contract) had better be ammended (possibly introducing extra cost for the customer, depending on the extra effort or investment needed on our part) or the software wouldn't meet his needs (rather than his stated requirements), but I would need to have some idea of the actual use he was going to make of the stuff beforehand.

0

If the solution fits the requirements as laid out in the requirements document the customer signed off on as part of their contract, then yes he has to pay for it.

I'd (if I found out that the actual technical needs are different from what the customer stated) notify the customer that the requirements (and thus the contract) had better be ammended (possibly introducing extra cost for the customer, depending on the extra effort or investment needed on our part) or the software wouldn't meet his needs (rather than his stated requirements), but I would need to have some idea of the actual use he was going to make of the stuff beforehand.

i've worked with clients in which they never knew what they wanted, so matter how much questioning and work we did he always wanted "more" he always wanted a new expensive feature added, which i was fine with :)

my only gripe was that i was ready to go public and begin versioning the product we had a solid peice of software that he was ready to begin pushing, just sucks we had to part ways because his funding ran dry with all his new idea / features he wanted to add.

0

If the solution fits the requirements as laid out in the requirements document the customer signed off on as part of their contract, then yes he has to pay for it.

I'd (if I found out that the actual technical needs are different from what the customer stated) notify the customer that the requirements (and thus the contract) had better be ammended (possibly introducing extra cost for the customer, depending on the extra effort or investment needed on our part) or the software wouldn't meet his needs (rather than his stated requirements), but I would need to have some idea of the actual use he was going to make of the stuff beforehand.

This is why project managers and systems analysts exist - its their job to understand the requirements of the client before anything gets set in stone.
Chances are that the client isn't entirely aware of all the details of their problem(s) which need solving, so these people also have the job of explaining to the clients what the problem is, and, if done responsibly, the end result should be that the client will sign off on a document that fits their problem

Or, maybe in reality, a document outlining something else, which they've been talked into believing fits their problem, until a later date when the reality hits them that they've signed up for something they didn't want.

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.