It is good for a developer to work on a per-hour basis, but it's hard to explain the advantages of hourly rate to the customer.
What are your arguments on the hourly rate for the customer? How do you explain him his benefits and how do you argue on "I want to know the exact cost of the project"?
Old Joke: Assembly line breaks down and a repairman is brought in. After looking over the machine, he pulls out a hammer, strikes the machine and it begins to run. The shop foreman is amazed until the repairman says, "That will be $500." Caught off-guard the forman replys, "You want to charge $500 for hitting the machine with a hammer? My CFO is going to need an itemized invoice."
The invoice comes in the mail:
In a way, an hourly rate is the way to control the costs. What is an application worth that saves a company from having to hire a full-time minimum wage employee? Total annual costs for this person including salary, benefits, vacation, sick leave could reach $20,000. It has to be worth 15,000. If the solutiion turns out to be an import into a database that can be created in 30 hours or less, I doubt the going rate is $500/hour.
The client can control the cost throughout the life of the project.
Many projects that have a fixed fee ususally ask for half up front. The client can pay as they go with an hourly rate.
Charging by the hour just seems wrong to me. I want to be valued for knowing where to swing the hammer.
An hourly rate doesn't benefit the customer. It benefits the developer, because it doesn't matter how many changes are requested by the customer.
Just as a fixed price contract doesn't benefit the developer. At least, not without change orders. :-)
In construction, there's a clear separation between analysis and design (architecture) and implementation (construction). Even with that separation, and a century or more of implementation cost information, construction projects can and do go over budget.
In computer development, there isn't as clear a separation between analysis, design, and implementation. The customer doesn't realize what it costs to change a screen after the coding is complete, as compared with knocking down a wall.
The developer has a responsibility to educate his customer, and to make sure the customer understands value, as opposed to price.
The main difference between fixed-price and hourly is who assumes the risk. Particularly in this field, project estimates are only approximate, and can have a large amount of uncertainty in them.
Therefore, on a fixed price, the developer has to make sure to estimate high to cover unforeseen difficulties. This is reasonable, as in most business activities having to cover the risk is worth money (that's how the insurance business works).
If the customer trusts the developer sufficiently, an hourly rate will allow the customer to save money if the project finishes earlier than said high estimate, although if it goes over that the customer loses money. In this case, the customer covers the risk, and on the average will save money.
Particularly if the customer is a large company and the developer is an individual, the customer is likely to be in a better position to assume risks. Having to pay out an additional 160 hours' rates is likely to hurt a larger company less than having to work an extra month for free is going to hurt a lone developer.
It also makes negotiating spec changes easier when the developer doesn't have to do a thorough re-estimation for each change.
An hourly rate benefits the customer in cases where there’s a high likelihood that they will want to add additional features above the ones initially identified. It will also benefit the customer where the development process includes working with third parties, and where the developer’s role might have to include other tasks that are only tangentially related to the programming task.
An hourly rate lets the developer say “I’ll take care of that.” Rather than “That’s not covered in the price we agreed upon. That will be an additional X dollars.”
In these cases, an hourly rate eliminates the need for continual negotiations and can help prevent misunderstandings arising from differing views of what was initially agreed upon.
On an hourly rate, the customer has to make sure you work efficiently. In a fixed price contract, the customer has to describe exactly what he wants. If the customer wants to know the exact cost of the project, you have to know exactly what needs to be build. Usually the customer does not know, or think he knows but changes his mind later.
In both situations a sales drone will find a way to overcharge the customer: bid low on the fixed part of a project, and make up for it later with huge bills for every minor change or addition, or let the most competent people win the bid and replace them with crap programmers (at the same hourly rate) later.
If I were a customer, I would prefer to:
That way I'm free to make up my mind as I go along, and know what I am paying for.
Consider asking your customer the question like this:
How confident are they about their specification? Have they really thought of everything? What might change between now, and when the product goes live? Explain that with a fixed price, comes a fixed specification. any changes, and the price will change.
I'd then offer a alternative. Quote a price, and a specification change allowance, of perhaps 20%. That way, the customer has already budgeted in some room for changes, and if they did manage to get the specification correct in the first place they will bring the project in under budget!
If the customer wants to direct and control the development process, and/or make frequent changes to the product, then they can do that, but they have to agree to an hourly/daily rate.
