[samwgoldman]

This is bound to be a controversial opinion, but I fall down strongly on the side of time and materials billing, as opposed to fixed budget (FB). I don't hold this opinion as a way to cover my own ass, but I actually think it's the best deal for my clients as well.

1. Fixed budget projects are also fixed scope (unless you're a masochist), but in literally 100% of projects I've worked on, we refined the idea as we developed it. In a FB project, now you get to do the change request dance. In a T&M project, you can adjust priorities fluidly.

2. FB projects are a weak guarantee in practice. Once your consultant's billable rate drops to $0, what do you think happens? You are the lowest possible priority. Either your changes/fixes never happen, or they're made hastily. If you're working with a larger firm, your project is now in the hands of the most junior employees.

3. FB projects are an excuse for poor communication. Clients will take the simple dollar value as an excuse to check out until the money runs out, then be disappointed when the end result isn't exactly what they had in mind. You need to show your work as you build it, gather feedback as you go, and adjust priorities.

4. T&M puts both parties on the same team, working together to build the best product. FB is too adversarial. The client tries to get as much possible stuff, because their cost is fixed. You are constantly pushing back, defending a hopefully well-defined concept of "the scope." Guess which kind of relationship gets more accomplished?

I could go on. But TL;DR, you should charge for maintenance and it should be the same way you charge for the rest of it: by the hour/day/week.

[agopaul]

This is very interesting and I'm convinced. But the problem the companies I worked for in the past faced is that sometimes the client has a tight budget and have to share it with other projects too. So they need to have a precise view of the cost of the project not only short-term (initial development) but also long-term (maintenance).

The solution would be finding the clients willing to go down the road of non-FB projects, but hey, sometimes the market is what it is.

[samwgoldman]

My approach to tight budgets is simple. There are just two rules: 1. Get to something that works ASAP 2. Always work on the most important thing

Once you have something that works, you can run out of money and still have created value. I don't tend to call this a MVP, but the idea is the same.

Working on the most important thing is hard, because it requires that you and the client/stakeholders communicate often and well.

If you can get this right, you shouldn't need to worry about the budget other than wholesale feasibility. (You still need to evaluate whether you can do the project at all.) Once you have something working, you just keep improving it until the cost outweighs the benefit of more work, then you're done.

[pjungwir]

You might enjoy this article from Dr. Dobb's: Is Fixed-Price Software Development Unethical?:

http://www.drdobbs.com/is-fixed-price-software-development-u...

Although I think you make the case just as well and more succinctly. :-)

[aggieben]

I don't think this is controversial at all. I wouldn't even give a second thought to a FB deal (unless it was for my own mother, I suppose) - the incentives are all completely misaligned. It starts off adversarial and is extremely likely to end in a failed project and/or hostile client (as you explained very ably).