[patrickmay]

The underlying issue is risk management. Customers want certain features within a certain budget, hence their need to constrain at least two of the variables mentioned in the article. They want the vendor to take the risk of going over budget.

Vendors, obviously, want the customer to take the risk. This is why we see articles like this.

If you want to apply agile methodologies in these situations, you need to keep the scope small and also constrain the time. That keeps the risk for both the customer and vendor manageable.

[kris_lander]

I agree whole heartily, but the risk that is rarely protected by the contract is whether those features will actually give the client any return on their investment. Keeping the investment small (in terms of scope and time) only reduces the exposure in terms of cost/time to the client, yet vendors are making countless decisions that affect the outcome (e.g. ROI) of a project. The "scope" in a contract tends only to specify "what" and not "how well" or "why". At my company been experimenting in trying to solve that problem by contractually committing to outcomes (e.g. a measurable goals connected to the business case - e.g. reduce churn, increase sales, etc.) and tying part of our payment to meeting those goals.

[hvidgaard]

We have a different approach. If the customer wants a fixed scope and price, we make an estimate (considering both our internal cost, and the value of the work for the customer) then double the price.

They usually do not accept and want it cheaper. Then we offer the project at the estimate and to split any difference. So if we use 1 hour less at 200$/h, they get it 100$ cheaper. However, if the project ends up taking 1 hour more it will only be 100$ more for the customer.

I really would wish that the customers would trust us more and accept it at the hourly rate to get the initial work. Then we can iterate on that until they're satisfied.

[dmadden]

Agreed that if we can get 2 sides to 'trust' each other, we can minimize the need for this type of approach.

[ThrustVectoring]

More concretely, your post is a suggestion to do something along the lines of "write a contract for a demo/alpha/MVP, then do a separate contract to improve things, iterate until done", right?

[patrickmay]

That would be ideal, but in my experience it needs to be phrased as a risk mitigation strategy, not as constraining one of three project management aspects.

Customers want business value. Some software systems that deliver that value cannot be broken into components or feature subsets that are sufficiently valuable in and of themselves. In these cases, the value of agile methods to the customer is that they can pull the plug at any time. That's the risk mitigation value that needs to be emphasized.

[dmadden]

Absolutely agree that it's a risk mitigation strategy. Even if we can get to a 'do an MVP' and then iterate, I still see these types of contracts trying to fix more than 1 project aspect.