5 ms·

An hourly rate is easier, because you don't need to worry about scope creep. But your total bill should never surprise a client—you need to communicate at each

by ekidd 15y ago

An hourly rate is easier, because you don't need to worry about scope creep. But your total bill should never surprise a client—you need to communicate at each step of the way. A flat rate, on the other hand, allows you to charge for the value you provide, and gives your clients a predictable budget. By charging a fixed rate, you're saying, "I can do this work quickly and well, and I'm sure enough of my estimates to take on all the schedule risk." On the other hand, fixed-priced projects can explode horribly when the requirements inevitably change. I suspect that somebody usually walks away unhappy. I use a hybrid system: I break the project down into features, and offer a quote for each feature. The quotes are measured in "points" (as in XP or Pivotal Tracker), and I charge a fixed price per point. My clients choose which features they want. And if the spec changes, we just scrap some existing features and draw up new quotes. If you're a highly-productive developer, and you're good at communicating with your clients, you might find that this system offers something for everybody: Your clients get predictability and flexibility, and you get a strong incentive to become a better developer.

nicksergeant 15y ago
This is brilliant. I'm going to try this on my next freelance gig.
nesbot 15y ago
I just see this as fixed price your just exposing your broken down system to the client rather than supplying a larger $x to complete the whole project. You do limit your exposure by using the smaller chunks though. The issue is that if the "spec changes" you still need to work out what happens next, ie. scrapping some features etc. Hourly rate keeps this process smoother, and smooth is the new fast.
- tptacek 15y ago
  Hourly rates get you paid less, because your rate sounds higher in the context of "one hour's work" than it does in the context of "cost for a completed project", plus the fact that the hourly quote comes with the implicit risk that you'll go wildly over budget. The client will mitigate that risk and take the cost of that mitigation out of your hide. You won't realize it until you and your friends start complaining over beers about how jacked up your big competitors rates are; they aren't, though, they're just not getting rolled by their clients. People here really seem obsessed with the risk that the client is going to change their mind a hundred times. That makes sense, because it's the element of risk that developers actually see, care about, and feel entitled to an opinion about. But some important things about that risk: * Unless you're working for tiny clients, it's much less of a real-world risk than it sounds. Major clients don't start projects with the intent of squeezing extra hours out of their devs. The amount of money they save by doing that is less than a rounding error, and, most importantly, they aren't spending their own money to get you. * There are better levers to pull to mitigate project/schedule risk than quoting at your most flexible and least favorable rate by default. * Even if you shoulder the risk of midstream spec changes, in all likelihood a client that pulls the rug out from under you is probably going to be reasonable about buying more of your time, especially when you say "no, I can't get that done in the original schedule; I don't see a way to resolve this without adding time to the project". The middle ground between project and hourly rates has been our default for years: * We break pricing down by person/week * Our proposals loosely attribute milestones to weeks * Any negotiation is conducted over the total project amount * Project price cuts take the form of scope/effort reductions This is a project-based bidding system that leaves you with the ability to say "no" or "you choose, either this new stuff, the original project milestone for the week, or an extra billable week and a new SOW".
  - m0nastic 15y ago
    For what it's worth, my experience also echoes what Thomas is saying here. When he speaks of larger firms pulling shenanigans around doubling up work or other suboptimal practices...yeah, that's my company. The only thing we ever billed at an hourly rate was forensic work, and that was specifically done to make up for the reactive nature of that work. For everything else, it's a fixed rate contract based on the estimated number of person/weeks of work with a clearly defined scope as to what is expected to be done. Our contracting department (which itself is larger than most of the companies we work for) would never want to deal with anything else.
  - nesbot 15y ago
    I have seen scope change been an issue on 10k projects as well on multi-million dollar projects. All of which in my history would have been better off with an hourly billing. The number of bodies were talking about makes a big difference, and the larger that number is the more a fixed rate person/week makes sense. Just like the larger consulting firms its all about placing a lot of people for a long time, +/- 1 week here or there won't matter. You mitigate the risk and it makes sense to take it on spread across the team and only as granular as weeks. Agreed your system works really well with those scenarios. I interpreted the the original post was an individual who provides consulting service where 1 week could make a difference, 20% overage on a 1 month project. The companies aren't necessarily tiny, but maybe the departments within those companies (read budget) he consults with are limited. In this scenario I would favour a good hourly rate over fixed price every time.
dennyabraham 15y ago
This is definitely my favorite system when I can get clients to sign on to it. It manages expectations, defines scope, and ensures communicative development at the same time. I also worked for a firm that sold sprints whose point velocity would automatically adjust to account for point value fluctuations.
- dhalsey 15y ago
  Do clients usually agree to this system? If they're unfamiliar with sw development, it might seem suspicious. I wouldn't be exactly comfortable with a plumber drafting up anything else than a standard work-and-parts contract.
- nickmolnar2 15y ago
  We have tried just about everything at our shop, Thirdi. Fixed rate quotes are dangerous because they make all the pricing decisions at the point where you know the least about the product. They lead to waterfall-esque development, since your only shot at avoiding scope creep is to catch everything up-front. Plus, change requests feel like nickel and diming to the client, slow the project down, and are just generally bad service. Hourly billing is difficult to sell: would you buy a house, knowing that the sale price might increase by 30% after you moved in? Plus, you run into the problem of those hours not being tied to a productivity level. We've started giving high-level estimates of projects up front, but not committing to a specific scope or price. Instead we invoice for each 2-week sprint with set deliverables. This way, the client is paying for features, not time. We start a feature backlog at the beginning of a project, but add in much more detail right before each sprint starts. The client always knows what they're buying, and we can quickly tell if we're running ahead or behind on the project based on whether we are finishing sprints early, and how many features we are knocking off. By not getting married to one feature-set at the beginning of the project, it also allows us to throw in 'nice-to-haves' that might be easier than expected, or scale back less important features if they turn out to be more complicated than we thought. It does add time for communication and managing the backlog, of course. We have a dedicated project manager and a QA lead to keep this stuff away from our development team, otherwise they might have all gone mad by now.
rapind 15y ago
One thing to keep in mind is that it takes time to come up with a detailed quote like this, and you'll want to be paid for that time. I usually throw out a ball-park guesstimate (without signing anything) to see if the client is comfortable with it, and then ask them to pay for a detailed quote like this, which they then own and can shop around with. You can take somewhat of a loss on the scoping since if they've agreed to pay you for it, there's a really good chance you'll be awarded the contract (as long as it doesn't blow them away or they have unrealistic expectations, in which case thank god you scoped it out). This way at least you're still getting paid something.
- tptacek 15y ago
  I would never bill a client for the time it takes me to build a proposal, and I would think way less of any contractor who suggested I pay for their proposals. Don't do this. Research for quotes and proposals is in almost all cases a cost of doing business.
  - bkhughes 15y ago
    I think this might depend on the case. I've had clients with only a vague idea of what they actually needed, meaning that we essentially needed to design the product before we could quote it. We charged a nominal fee, which was discounted from the project if the proposal was accepted.
    - tptacek 15y ago
      It doesn't depend on the case; it's a question of how you frame the project. If you need to design the product before you can estimate it, you propose a design project. You should propose to produce a design deliverable; you can offer your client a price break to skip that deliverable and plow ahead into implementation. Or, you can quote the project "blind" but structure it so that the client bears the risk; for instance, by quoting a fixed number of billable weeks with a "if you tell us by week N, you can get more contiguous weeks at this rate" clause. Or, if the client is really worth having and the project is good, you can do enough design work to do a realistic proposal gratis, which is what we invariably end up doing, because we don't do projects that aren't worth doing that for. But in no circumstances should your proposal itself be perceived as having a price tag. One consultant did that with us once and I had to talk my parters down off the wall against ending communications with them right there.

by ekidd 15y ago

nicksergeant 15y ago

This is brilliant. I'm going to try this on my next freelance gig.

nesbot 15y ago

I just see this as fixed price your just exposing your broken down system to the client rather than supplying a larger $x to complete the whole project. You do limit your exposure by using the smaller chunks though. The issue is that if the "spec changes" you still need to work out what happens next, ie. scrapping some features etc. Hourly rate keeps this process smoother, and smooth is the new fast.

tptacek 15y ago
Hourly rates get you paid less, because your rate sounds higher in the context of "one hour's work" than it does in the context of "cost for a completed project", plus the fact that the hourly quote comes with the implicit risk that you'll go wildly over budget. The client will mitigate that risk and take the cost of that mitigation out of your hide. You won't realize it until you and your friends start complaining over beers about how jacked up your big competitors rates are; they aren't, though, they're just not getting rolled by their clients. People here really seem obsessed with the risk that the client is going to change their mind a hundred times. That makes sense, because it's the element of risk that developers actually see, care about, and feel entitled to an opinion about. But some important things about that risk: * Unless you're working for tiny clients, it's much less of a real-world risk than it sounds. Major clients don't start projects with the intent of squeezing extra hours out of their devs. The amount of money they save by doing that is less than a rounding error, and, most importantly, they aren't spending their own money to get you. * There are better levers to pull to mitigate project/schedule risk than quoting at your most flexible and least favorable rate by default. * Even if you shoulder the risk of midstream spec changes, in all likelihood a client that pulls the rug out from under you is probably going to be reasonable about buying more of your time, especially when you say "no, I can't get that done in the original schedule; I don't see a way to resolve this without adding time to the project". The middle ground between project and hourly rates has been our default for years: * We break pricing down by person/week * Our proposals loosely attribute milestones to weeks * Any negotiation is conducted over the total project amount * Project price cuts take the form of scope/effort reductions This is a project-based bidding system that leaves you with the ability to say "no" or "you choose, either this new stuff, the original project milestone for the week, or an extra billable week and a new SOW".
- m0nastic 15y ago
  For what it's worth, my experience also echoes what Thomas is saying here. When he speaks of larger firms pulling shenanigans around doubling up work or other suboptimal practices...yeah, that's my company. The only thing we ever billed at an hourly rate was forensic work, and that was specifically done to make up for the reactive nature of that work. For everything else, it's a fixed rate contract based on the estimated number of person/weeks of work with a clearly defined scope as to what is expected to be done. Our contracting department (which itself is larger than most of the companies we work for) would never want to deal with anything else.
- nesbot 15y ago
  I have seen scope change been an issue on 10k projects as well on multi-million dollar projects. All of which in my history would have been better off with an hourly billing. The number of bodies were talking about makes a big difference, and the larger that number is the more a fixed rate person/week makes sense. Just like the larger consulting firms its all about placing a lot of people for a long time, +/- 1 week here or there won't matter. You mitigate the risk and it makes sense to take it on spread across the team and only as granular as weeks. Agreed your system works really well with those scenarios. I interpreted the the original post was an individual who provides consulting service where 1 week could make a difference, 20% overage on a 1 month project. The companies aren't necessarily tiny, but maybe the departments within those companies (read budget) he consults with are limited. In this scenario I would favour a good hourly rate over fixed price every time.

dennyabraham 15y ago

This is definitely my favorite system when I can get clients to sign on to it. It manages expectations, defines scope, and ensures communicative development at the same time. I also worked for a firm that sold sprints whose point velocity would automatically adjust to account for point value fluctuations.

dhalsey 15y ago
Do clients usually agree to this system? If they're unfamiliar with sw development, it might seem suspicious. I wouldn't be exactly comfortable with a plumber drafting up anything else than a standard work-and-parts contract.
nickmolnar2 15y ago
We have tried just about everything at our shop, Thirdi. Fixed rate quotes are dangerous because they make all the pricing decisions at the point where you know the least about the product. They lead to waterfall-esque development, since your only shot at avoiding scope creep is to catch everything up-front. Plus, change requests feel like nickel and diming to the client, slow the project down, and are just generally bad service. Hourly billing is difficult to sell: would you buy a house, knowing that the sale price might increase by 30% after you moved in? Plus, you run into the problem of those hours not being tied to a productivity level. We've started giving high-level estimates of projects up front, but not committing to a specific scope or price. Instead we invoice for each 2-week sprint with set deliverables. This way, the client is paying for features, not time. We start a feature backlog at the beginning of a project, but add in much more detail right before each sprint starts. The client always knows what they're buying, and we can quickly tell if we're running ahead or behind on the project based on whether we are finishing sprints early, and how many features we are knocking off. By not getting married to one feature-set at the beginning of the project, it also allows us to throw in 'nice-to-haves' that might be easier than expected, or scale back less important features if they turn out to be more complicated than we thought. It does add time for communication and managing the backlog, of course. We have a dedicated project manager and a QA lead to keep this stuff away from our development team, otherwise they might have all gone mad by now.

rapind 15y ago

One thing to keep in mind is that it takes time to come up with a detailed quote like this, and you'll want to be paid for that time. I usually throw out a ball-park guesstimate (without signing anything) to see if the client is comfortable with it, and then ask them to pay for a detailed quote like this, which they then own and can shop around with. You can take somewhat of a loss on the scoping since if they've agreed to pay you for it, there's a really good chance you'll be awarded the contract (as long as it doesn't blow them away or they have unrealistic expectations, in which case thank god you scoped it out). This way at least you're still getting paid something.

tptacek 15y ago
I would never bill a client for the time it takes me to build a proposal, and I would think way less of any contractor who suggested I pay for their proposals. Don't do this. Research for quotes and proposals is in almost all cases a cost of doing business.
- bkhughes 15y ago
  I think this might depend on the case. I've had clients with only a vague idea of what they actually needed, meaning that we essentially needed to design the product before we could quote it. We charged a nominal fee, which was discounted from the project if the proposal was accepted.
  - tptacek 15y ago
    It doesn't depend on the case; it's a question of how you frame the project. If you need to design the product before you can estimate it, you propose a design project. You should propose to produce a design deliverable; you can offer your client a price break to skip that deliverable and plow ahead into implementation. Or, you can quote the project "blind" but structure it so that the client bears the risk; for instance, by quoting a fixed number of billable weeks with a "if you tell us by week N, you can get more contiguous weeks at this rate" clause. Or, if the client is really worth having and the project is good, you can do enough design work to do a realistic proposal gratis, which is what we invariably end up doing, because we don't do projects that aren't worth doing that for. But in no circumstances should your proposal itself be perceived as having a price tag. One consultant did that with us once and I had to talk my parters down off the wall against ending communications with them right there.