Billing by the hour is the only effective way I have found to eliminate scope creep. Being able to say "Well, sure, I CAN do that, but it's going to cost an additional 4-6 hours" is simply the easiest (and most well received) method of indicating that they are asking for something not initially agreed to.
Obviously, it helps to have a contract/requirements documentation/specification/etc., to point to, but it's rare that you run into a document detailed enough to cover nuances like whether or not this element should be blue or light blue after clicked upon.
If you billed fixed rate and the client changes the requirements, then you change the fixed rate.
Say you estimate the cost at $10,000 and they want you to make a change, you say, "Okay, but this change wasn't included in the $10,000 so we will have to estimate how much the change will cost and add it to the bill. If you want us to do that, let us know."
This is why you have to outline the requirements before you do a fixed bid.
Instead of saying it's going to take 4-6 more hours, you say it's going to cost $400-600 more dollars, assuming you estimate at $100/hr. If it really takes you 1 hour, then you still make $400-600, but it only takes an hour so your hourly rate just went from $100 an hour to at least $400 an hour.
If you're a highly productive programmer and use the right tools, then a fixed bid can come out in your favor if you estimate projects using the hourly rates and estimates that not so productive programmers use.
'Say you estimate the cost at $10,000 and they want you to make a change, you say, "Okay, but this change wasn't included in the $10,000 so we will have to estimate how much the change will cost and add it to the bill. If you want us to do that, let us know."'
Sometimes it's really that simple. Other times, you end up debating whether something is a 'change', or 'clarification', or some replacement, or whatever.
The upside of fixed bid is that you can do quite well when the process is well-defined and everyone is reasonable. The upside of hourly is that you get to offload assorted issues (i.e. prolonged requirements gathering, change requests, and ad-hoc requirements finessing) and focus on the work.
For every person I hear advocate fixed-bid, I hear another advocation hourly, and each swears experience is on their side.
For my latest contract gig, I decided to try a slightly different approach than tallying and billing hourly or guessing at a fixed-cost. We're going with a "retainer" model which more or less makes me into an unofficial employee, but the idea is that they get X number of hours per week of my time. Deadlines and such are attempted to be met within those constraints.
The upshot of this is that they have a clear and known rate of expense. If the project doesn't appear to be progressing fast enough, they could increase the hours per week they pay for, hire more help, hire someone else, or wait longer. :)
The tricky part is getting into a deal like this without them trying to attach things like, "ok, you work 20 hours a week on our project - but if it's not done by the 3rd, we don't pay you." or whatever. But if you can avoid that and get them to think of you as an employee and not just a code factory, it works out.
I think tools are an important part of the equation.
Say you are paying someone to demolish your concrete driveway. Would you pay someone with a jack hammer who can get the job done in an hour the same rate you'd pay someone with a sledgehammer, which will take 8 hours? The task is the same. The value of the completed project is the same.
But if the jack hammer owner charges a fix bid billed for half the hourly rate of the sledge hammer owner, he spends an hour and gets paid for four.
In a fixed bid contract, the jack hammer could charge 50% more than he would estimate the demolition (originally billed at half the hourly rate of the sledge of 4 hours) at 6 hours and still make more money and spend less time: 6x as much money and spend 1/8th as much time completing the job. If his estimate was way under actuals and it ends up taking him twice as long (2 hours) as he originally thought it would take, which was 1 hour, he still makes triple the hourly rate for two hours of work (6 hour billed estimate, 2 hours of work) than the guy with the sledge hammer!
The use of tools that accelerate task completion, in this case an 8x improvement (jack over sledge) enables the jackhammer operator to underestimate the labor times and still make more money at lower times to completion. Plus, the driveway owner gets his demolished driveway in 25% of the time that it would have taken with a sledgehammer and that is still at a project overrun of 100%!
But the world doesn't understand equations like this or really accept the value of advanced technologies. I use technology to build custom software products that are way more advanced than what typical developers use, so I can build them 10x faster and charge half the rate and still make more money!
I know a local case where a company is paying a guy to use Perl to build a data driven website using files -- instead of an SQL Database. he's been working on the website for over 5 months and it still isn't finished and it has already reached the maximum of its flexibility. It's already going to have to be re-architected to enable the features the client wants now. If the local company had gone with our company, which uses a flexible sql based infrastructure, then the project would have been completed in about 2 weeks and still have lots of flexibility to go! New features would be easy to add.
Now, the programmer is coming to us asking to use our technology to help him complete his project!
So, I love the current state of the software world. Frustrated customers paying too much for projects that typically fail are a great market segment.
Bill by the project. You can use your hourly rate to estimate the fixed cost. The more projects you do, the more accurate your estimate will become. Over time you develop your own time-saving methods, such as pulling code out into reusable libraries you can use on your next project. Say you do a project that takes you 50 hours and you charge $5,000. If you get another similar project but this time you know it will only take 25 hours, are you going to charge $2,500 for it? Hell no! Charge as much as the market will bear, but set some kind of a minimum threshold for yourself. Here's an old article relating to technical writing, but I think it still applies to software development: http://www.writerswrite.com/journal/jan98/kent.htm
"You can use your hourly rate to estimate the fixed cost"
Only if you know how long it will take. Which assumes you know what you are going to build, which assumes the client really knows what they want.
If you are doing a more agile project, you expect new requirements to come up, current requirements to drop out, things to change along the way. But you almost certainly have no solid idea how long it might take.
A mixed approach might be to make a big project into a series of smaller projects (e.g., well-defined and doable in 1-2 weeks), and bill each at a fixed price.
I have never quite gotten billing in hours. The value of a project is utterly uncorrelated with them. The number of hours to accomplish X goes down as the skill of the individual goes up.
What sane model is it that says hiring average people to do unimportant work should cost more than hiring experts to do things that really matter for the business?
That's why as skill increases, the hourly rate should, too. If a company is looking to get something done faster and are willing to pay for it, they can hire the more skilled/faster professional. If that's less important to them, they hire the slower and/or sloppier but cheaper alternatives. You have to be willing to increase your rates if you're getting better/faster.
If you're an employee, that's why you should be able to expect raises and bonuses and the like. The assumption is that you're getting better and better at what you do and therefore becoming more implicitly valuable. If you feel yourself getting more and more skilled but the company refuses to reward you, you should leave for someone else who values that skill - which is basically the same thing as raising your hourly rates if you're independent.
The number of hours to accomplish X goes down as the skill of the individual goes up.
I wouldn't assume that they continue to solve for X - you can solve harder problems as your skill goes up too, so hours can be a good way to judge difficulty.
I think hourly billing is bad for two reasons, even though I do it all the time:
* It just limits the amount of money you can make. People have a strange psychological approach to hourly figures; once you hit a certain rate that they consider alarmingly "high," which is a metric that varies immensely, their eyes just sort of glaze over and they go, "ooof!" But if you give them a fixed bid that assumes x hours and comes out to an equivalent hourly rate that is ${quite high}, they seem to be just fine with that - in my experience, this is often true even if you itemise it and declare the expected hours. Some sort of fixed bid leaves a lot more room for padding in case things don't go as expected, and, if you're lucky, more profitability.
* Programming workflow just isn't linear like that. We've all read Joel Spolsky's "Human Task Switches Considered Harmful." In addition to that, programming problems are often solved in strangely noncontiguous, out-of-band ways, like coming up with solutions to a vexing encumbrance in the shower.
The point is that billing should attempt to reflect the actual workflow as closely as possible, and the workflow of a programmer just doesn't go like an auto shop's. If you have a 20 hour project, doing 5 hours here, going off to do something else, and coming back to it and doing another 5 hours doesn't mean the project is 50% done - at least, from a practical perspective.
Being a very small business myself with no credit facility and no savings or cash buffer whatsoever coupled with relatively high living expenses inherited from my employed days, I face the additional issue of severe cash flow constraints when I attempt to float long projects that pay hourly. I describe this more extensively in this comment: http://news.ycombinator.com/item?id=746517
For me - as for many freelance programmers and contractors - I think the right choice is some sort of flat weekly billing, and splitting up any project of nontrivial size into smaller, manageable and well-defined milestones. If you can get away with it.
I think it's pretty fair to say that you often can't do a linear, 1:1 relationship between time spent toward project and money paid. One caveat is the one I pointed out above. The other, more generally, has to do with the fact that at 100% completion code acquires orders of magnitude more economic utility than when it's 90% complete. At 90%, it's just a useless blob of code as far as most customers are concerned. At 100% it's a finished deliverable that does what they want - or thought they wanted, whatever. So, usually there's a bigger balloon payment at the tail. It's not realistic to expect that when you have 7/8ths of the project done, you'll have 7/8ths of the money in hand. There are other reasons for this as well; see the link to my other comment above. But I think one should strive to get as close to that possible, insofar as it's possible to measure % completion to any degree whatsoever.
Obviously, it helps to have a contract/requirements documentation/specification/etc., to point to, but it's rare that you run into a document detailed enough to cover nuances like whether or not this element should be blue or light blue after clicked upon.