The problem with fixed price work is you create a conflict of interests from the start. It's in your interest to do as little as possible for the price and it's in your customers interest to get as much as possible for the price.
That and all the issues of requirements gathering up front.
Isn't it also true that hourly or daily billing creates a conflict of interests from the start, because it's in the customer's interests for you to finish as fast as possible and in your interests to finish as slowly as possible?
Yes, but those are smaller than the converse, where the conversation is about whether something ambiguous/new is in or out of scope (strictly adversarial discussion), rather than whether such ambiguous items are worth it or not to the client (simply a resource allocation discussion).
I have a hard time believing that the potential conflict of interest situation that emerges from a fixed-price engagement, where the customer ultimately can accept or reject the work, would be worse than the elemental conflict of interest that emerges from hourly billing, where customers have little control or even insight into hours billed.
It's not about likes and dislikes, both are workeable systems. But they're very different. Some obvious and not so obvious ways:
1. The obvious way - in one you get paid no matter what, and your entire job is to keep the customer happy enough with you that they'll happily continue paying you. With fixed-price, you have a "semi-conflict-of-interests" as others mentioned.
2. These different incentives cause a lot more work up-front for requirement gathering, a lot more work on contracts that are well specified, etc. Btw, that also means billing at much, much higher margins to cover the uncertainty.
3. Not so obvious - doing fixed-price projects requires a lot of focus around managing multiple projects at the same time. When managing X employees on multiple projects, this gets tricky. Why? Because fixed-price projects tend to have lots of waiting: build some infrastructure, wait for design, build and deliver first milestone, wait for feedback, deliver final project, wait for bugs, fix bugs, wait for final confirmation.
So you're basically learning to juggle multiple projects at the same time. And all projects have points where their schedules shift - I've had clients who are completely desperate to get things off the ground, where I would've put 90% chance of their e.g. graphical designs being ready for us, who suddenly had business emergencies that required them to slow down. This happens ALL THE TIME, as does the converse (10 designs arrive at the same time and now you have 10 clients waiting eagerly for updates).
4. Another non-obvious difference - the kind of clients you can take on tend to be very different for these two methods. You'll tend to get more non-technical clients looking to work project-based, and more technical clients looking for time and material, especially when what you are doing is augmenting their own technical staff with expert knowledge.
To summarise, each style of billing or more correctly each type of project you can take on has its own challenges, they're not better/worse, they're just different.
Very good points. I would add that one's relationship with customers is much more unpleasant when doing project pricing. The "out-of-scope" discussions are difficult and can make collaboration strained.
That and all the issues of requirements gathering up front.