Is it better to be paid by the project or hourly?

Question

I've recently gotten offers from several clients who are throwing consulting/contract work at me. (this is what we call a high quality problem). The problem is the most interesting ones will take an unknown amount of time and typically clients get upset when stuff doesn't get done FAST.

This goes into the fact that consulting/contract charge by the hour. I am thinking about moving to a pay per project model where I look over a project, look over the specs and give an estimate on the time needed. This way its less stressful on both sides as there is a set price point. Provided I don't get last minute additions for new features the price shouldn't change too much.

I've already read this: http://www.1099.com/c/ar/ta/HowToCharge_t042.html

But I'd like some actual war stories. Maybe I'm being foolishly naive but I think the pay per project model is superior to by the hour. What do you guys think? Is it better to be paid by the hour or by the project?

Answer 1

I like a mixture of both--have an hourly rate, and judge how long the project will take, and base the price off of that. It gets the best of both worlds--no worrying about how much it will cost for the customer, while at the same time ensuring you get a fair rate.

Answer 2

This vary much depends on the nature of the project and how many known knowns, known unknows and unknown unknows there are. If you are certain that the project wont stray and that intergration will not be an issue then per project can work best. However if you are coming into solve an issue or take over from another programmer then by the hour is best as you have no idea what your walking into and ofter end up opening a can of worms :|

Answer 3

Pay by hour is often safer you, but clients tend not to like it. In there mind, it's hard to plan and control costs and there's no incentive for you to finish promptly.

Pay by project is riskier to you, but if you manage expectations and requirements (aka put the kibosh on scope creep), it can be more lucrative for you if you can find ways to be even more efficient.

I tended to prefer hourly because the clients I worked with didn't understand software dev at all. For clients who seem reasonable and understand the process, I would probably try per project.

Answer 4

Only do a fixed bid if the requirements and timelines are extremely clearly defined and you're extremely confident they won't change. Also, if you do a fixed bid, make sure the contract covers what happens if the requirements change, even if you don't think they will. Too many times I've seen people burned by changing requirements on a fixed bid.

Answer 5

There's two skills that are crucial to pay-per-project - estimation and change control. If you don't estimate well, then you'll end up working long hours for free, as the last 20% will inevitably take 80% of the time. If you don't keep an iron grip on the amount of changes you let the client make, you'll end up working long hours for free, as they'll just keep adding "one more thing". Make it absolutely clear that every time they change something, it increases the bill and moves the delivery date back.

Also, for the larger projects, split it into multiple deliverables and charge separately for each. This reassures them, makes hitting deadlines easier, reduces scope creep, and lets you push back change requests to points where you can more easily deal with them.

Answer 6

I divide billing into two phases - research and development

The research phase is billed hourly, and builds a 'comfort-level' with the client as they aren't coughing up wads of cash up-front. During this phase, you work with the client to investigate their problem/needs and reach agreement on the exact nature and scope of the project.

The development phase is a fixed price per project, optionally split up into milestone deliverables.

The rationale behind my approach is this: clients like knowing costs up front, which leans them towards preferring fixed-price bids. However, entering into a project, both you and the client really do not have a solid-enough grasp on the nature and scope of the project, so there's more 'fear of the unknown' attached to a dollar amount (they're uncertain they're going to get what they need for their money).

Pulling clients in the other direction are piecemeal costs, which makes hourly rates attractive. The downside is that there's yet another 'fear of the unknown' here, namely that it's an open-ended invoice.

By using the hourly rate when you are working closest with the client, you give them comfort that they're paying for valuable productivity at a manageable rate. Once you have all agreed on the nature and scope of the project, the fixed price no longer holds the 'fear of the unknown', as they know (and have confidence in) precisely what you're going to do for them. The optional 'milestone deliverables' part increases confidence and client relations - I personally insist upon it to develop good business relationships.

The key (I believe) to the merit of this approach is simply this : you are adopting a proactive role in the management of the client's exposure to risk.

Answer 7

I have very little consulting experience, so I have more to learn from other answers than to share from my own, but it seems to me that scope (creep) is a key factor. Estimating hours and giving a fixed price based on the estimate is a good starting point, as long as there is a clearly-defined relationship between spec changes and additional charges, as you allude to.

If you do find yourself on a project where the scope changes dramatically and there is resistance to compensating you for it because you went with a fixed-price model, that project might not end well for either side, but maybe that is more a reflection of the client's approach to the project than to your pricing model.

Answer 8

Personally, I would prefer hourly. By project, and you're most likely unsalaried, which means you have to worry about things like insurance, taxes, etc yourself, and that can get to be a pain very quickly.

Answer 9

I think it is going to depend on the specification of the project.

If the project you are asked to do is similar to what you've already done (familiar ground), chances are you might be able to apply a similar assessment; and, thus, you might be able to assess how long it would take to finish the project - you would probably go with "Pay-Per-Project" in these cases. Otherwise, "Pay-Per-Hour" might just be a better scheme.

Answer 10

Hourly generally sets better expectations with the client. Unless the client has a firm grasp of the problem being solved and a reliable estimate can be made, no amount of padding is going to protect a project fixed bid, and when the project scope creeps, the client will have to agree in increases, which will increase their dissatisfaction with the project (and with themselves for not properly managing the requirements phase).

If at a certain point, the project achieves a point where it can be estimated, then a fixed bid is feasible, not before then.

Answer 11

• Getting paid by the hour, also called working on a time and materials basis, is better for you because you always get paid for your time. Software estimation is something of a black art, and it is very easy to go awry even with years of experience. I actually use Joel's approach, which is well worth a read: Joel on Estimation

• Getting paid on a project basis is better for the client... Sort of. You can estimate towards the high end to account for your risk, because it's a fact that if you work this way all the time you will eat some hours, and you can let your clients know that if you're going to assume risk you certainly can't be on the super low end all the time. Eating hours might actually be okay for you if you have low overhead and one or two really great clients that you need to take care of, but where I work my time is in very high demand and giving up hours is not considered acceptable.

I have tried many approaches over the years. Whatever you do, communicate a lot. I can't stress that enough. I will give some practical reasons for this below.

Some projects are hard to quantify or exotic and must be time and materials, at least during an initial research phase.

Speaking of which, often on a large project where the requirements are unclear, I will do an "engineering project" on a time and materials basis with a cap of, say, 20 hours, and then use that to generate requirements, a spec, and a quote. Often I am also able to do a database schema here and I sell it the whole idea to the customer as a deliverable that they can take elsewhere if they so choose, and I also let them know that during this planning phase I'm doing actual work on the project.

As for war stories, over the years I have run into a few situations where I did a bunch of hourly work for someone and, because I did not communicate constantly, things got heated. On their end, they were either legitimately surprised because I failed to set their expectations, or they were brutal negotiators and I failed to protect myself. It's really on me in any case, because I didn't communicate enough! Both situations occur, so whatever you do, communicate constantly.

One last thought: Working on a project basis does seem to be the most sure-fire way to avoid problems. Another option is to provide caps (10 hours, 20 hours) or hour ranges that things will take (5 to 8 hours). The downside is that if you constantly hit the cap or approach the high end of your quote, certain types of people will assume that you're taking advantage of them.

Answer 12

At work we offer an hourly rate, but when we write our specs we estimate the time we will spend. The client pays us for the time we actually take, within some upper limit past the estimate. This is incentive to have a very very complete spec.

Answer 13

If the company wants to hire by project than it's a relatively small project for just one person. If it's a big project then you will probably need to hire people to help you and menage them.

In either case, since you will have more risks to manage you can ask for more money. If there are too many risks involved, make sure you have every detail signed and approved to be safe and ask for more money!

Paying by hour can also be safe for the client if they measure your productivity.

If you are that kind of guy that feel comfortable with risks around you go for the 'pay by project' and ask for more money, but be ready for the worst. If you want to be on the safe side, stick with the 'per hour' payment.

Answer 14

customers usually like to have cost certainty and will try to get you to put a fixed price on the project. If you accept a contract like this you had better go through a phase that controls the scope and limits the deliverable. Most customers often try to get away with introducing changes midway to account for business changes or contingencies when discover a need sparked by a partial deliverable. For change orders we bill hourly to discourage this behaviour.

though it depends very much on the industry and nature of the client such as government or private industry.

Answer 15

Hourly. We were just screwed by a client who, all of a sudden after 8 years of working with us "hourly", demanded that this next assignment be paid via the project. They didnt disclose a lot of stuff and, to our acknowledgement we dropped the ball with the analysis, but in the end they cancelled the project after the contract was drawn up. Now're were in the middle of a legal situation with them.

Get paid by the hour because the client WILL ALWAYS change things. Try to keep scope creep to a minimum by explicitly stating there shall be no deviations from the original scope, in the contract, and be specific as to what would happen if the scope changes. By the project means they're going to probably elongate that project forever. Then what are you going to do when you get paid and realize it amounted to $15/hr when it should have been $70/hr?

Answer 16

By the hour!

In my experience projects with fixed price and scope are the most stressful, for the developer as well as for the customer, and will yield the lowest quality software.

In every project everyone learns more about the system as it grows. This knowledge is going to make the customer want to change things, add things, enhance things. And why shouldn't one want and do just that?

But instead the fixed price will make the developer say no which in turn will make the customer angry. Or the developer says yes which will increase the stress.

The closer to the deadline the more stressful will the project be. It turns out you won't even be able to get all the basic stuff done in time, let alone the enhancements you agreed to. The quality of the software will suffer badly.

How do you make software to be proud of while keeping the deadline and the budget? By letting the scope be the flexible factor, and dividing the system into sufficiently small pieces.

Answer 17

By the way, that 1099 site is great. I've used it as a reference for quite some time but too bad they're not updating it anymore.

Answer 18

In addition to everything suggested by previous posters, a few tips, having done both "time and materials" and "project based" work:

1. Accept project based work only and only when you or the organisation you represent is going to fully manage the delivery. If you're required to deliver a piece of work as part of larger effort, your contribution shall be treated as an independent project.

2. Make sure you know what dependencies are. Each dependency is a risk, that needs to be managed.

3. Project based work means that you accept greater risks (financial, budgetary, time, technological etc). Financial, since normally you're going to get paid only on successful completion of a project or stage, with time and materials you my get pay irrespective of project outcome. Hence your hourly rate when you do project based work normally needs to be 20-35% higher.

4. Additionally to hourly rate increase as in point 3, add time contigency into the estimate, normally 10-20%. Explain to the customer that you will seek their approval each time you need to use that contigency.

5. Regardless of whether your efforts are work and materials or project based you still need to provide as accurate estimate as possible, justify any change in time and cost, always keep the customer informed effectively letting them know that they are in control.

In my expirience, even with careful scope planning, good estimation etc, things go wrong because of lack or poor quality planning. Normally, software quality costs the most and takes the longest to attain. Different understanding of acceptable deliverables quality (non-functional requirements) by contractor and customer lead to many disputes.

I believe that putting quality safeguards into the intial plan is slightly off topic hence, I'll raise it as a separate question and post a link here. Cheers for reading.

Answer 19

The promised link:

Including quality into the initial project plan