|
|
|
|
|
by psyklic
4097 days ago
|
|
Many of the responses seem to misconstrue "value-based pricing" with "fixed-bid pricing". If the project's fixed bid is approximately your actual estimate (hours estimated x price/hr), then definitely do not propose a fixed bid. There is a lot of risk and ambiguity in lowball fixed bids that will cost you in the end. We all know that engineering estimates underestimate ... and that clients will always add/revise. So, why are you putting all of the risk on yourself for exactly what you would normally estimate? These situations are where freelancers get in big trouble with fixed-bid contracts. On the other hand, suppose that your work is a huge value-add to the client. Suppose the client cares mostly about high quality, wants a good reliable consultant, and wants you. In this case, you can price your fixed bid in line with the value it will bring to the client. Meaning that now the risk is negligible -- even if your estimates are off and the client revises things, you will still be happy with the outcome. Now that you can relax, you can spend more time on delivering quality work and even give freebies if everything is on track! Let me emphasize -- the only successful fixed price bids I've seen are where you know that even if everything goes wrong a developer still is happy with the outcome. After all, in most real-world pricing situations, the cost of the risk is part of the price (e.g. shoplifting losses), so why not for software engineering too? |
|