how ethically is to bill such extra premium to customers that do not want to understand the statistics?

Totally and perfectly ethical. Even necessary.

You have to learn that you ultimately are not billing by working hours. You are billing for features. How long you take to build them means nothing. How well they work in the end and satisfy the user’s requirements means everything.

Otherwise, a superb programmer that codes everything in 1/5 the time of a standard market programmer will make 1/5 of the money of the standard one. Totally unfair. If any, the superb programmer should earn even more.

And always tell the client: Fast, Cheap, Good, pick any two.

First of all, dropping features is not a quality reduction, it’s a change in the amount of work. And is pretty valid to me, actually this is exactly what’s done during iterative development.

Next, the issue of inadequate performance is solved by tight iterations. If you, as customer, see the product improvement at least weekly and at the end of the week don’t see the expected progress – just stop collaborating with such developer. That’s simple. All you risk is weekly budget and never more.

And the last, but not the least. What legal protection I have if I’ve agreed to a fixed price and spec interpretation is twisted by a customer? I see very little negotiation tools for a developer in a fixed price contract, especially if whole payment is done at the end and the budget is not that big to afford to go to court.

Yes, the combination of T&M and fixed price is good. But the best one I can think of is a weekly plans with fixed price per feature. And then the math above becomes actual: should I advise my customer to overpay for the insurance or play a roulette with my own expenses?

The truth is always somewhere in between, it is never ultimate. And best case approach has always been to keep client aware of the 3D money/time/quality model. There are times when client would agree for quality to be reduced (usually dropping features, not getting a buggy release) — normally when time is more important for him. And there are cases when they would reneg money or have some flexibility in time.

As a client, I would never give a free hand (T&M) to a vendor I have not tried in FPC case. I’ve seen where T&M projects may go. A combination of T&M analysis and FPC development project may be the better compromise, at least from my experience.

I’ve found the book ‘Software Estimation’ by Steve Mc Connell to be of great help.

Best regards from Santiago, Chile

Exactly.

And know what such customer does next after his project fails? He toughens conditions even more: micromanaging, full payment only after completion, more upfront developer screening. And, as a result, only young, brave and inexperienced decide to risk working on such conditions.

Yes, milestone bonus is an interesting project setup. I’ll try to suggest it to my client

@Stephen

I’d be happy to lower the bar, but the model presented is far too crude. I’m developing a more elaborated one that would be useful in a business planning now.

I’m still concerned that these models underestimate the magnitude of low-probability big failures. Just like most financial models do.

To my experience (and I’ve done a lot of fixed price projects), the bidding itself is an expensive process. And it’s way too easy for both parties to start argue about next milestone price, instead of doing development.

Re customer got fixed budget.. All he has to do is to say that. Developers are rational people mostly and may structure iterative process in a fashion that maximizes the chances to get a working product within the budget.

Agreeing upfront on both fixed functionality and budget also frequently leads to feature squeeze, even if it is directly prohibited by a signed agreement.

There games are way too familiar