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.
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.
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.
The last company I was at completely turned around when we stopped begging people to let us do their proposals and instead started charging them for the privilege to have us analyze their business, create actionable guidelines (that they could conceivably have anyone implement) and provide a quote for what our services would cost to implement them ourselves. They were welcome to take that strategy plan elsewhere, but when we started charging people for it, we had more clients than we knew what to do with.
People start to see you differently when you value your time, ideas and strategy and don't just give them away. Yes, there are some cases where it's worth doing one gratis, but the vast majority of time, we got more business by refusing to work with people who didn't run through our proposal process.
I am making a tactical point, and you are making a strategic point.
Strategically: of course you should structure your interactions with clients so that you are paid for your time, ideas, and strategy.
Tactically: avoid being that firm that wants money just to provide a proposal.
We are literally just talking about different ways to word things.
And while I totally believe your firm "turned around" once you started asking people to pay to get proposals, in my universe, the first purchase order you get from a client comes with multiple weeks of legal negotiation over an MSA. Nobody is going to do that casually.
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.
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.
> 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.
I guess this is ultimately what we did (had they turned us down on the main project, they would have walked away with the design spec). That's the standard policy now.
Yeah; I think I sounded pretty pedantic back there, so let me just say I don't think you're suggesting anything wrong. I'm just saying, I've seen fledgling consultants accidentally let themselves be perceived as billing for the proposal work, and I'm pretty sure that's a big mistake, worth calling out.
I've ran into a lot of scenarios where a client doesn't know what they want, and creating a proposal for them involves more of my time than it should. So as a result I'll offer consulting for a fee in order to come up with their ideal solution. This in term gets me most everything I need for a proposal as well as helps them to know what they are actually looking for.
The value add of consulting ends up working way better than directly charging for a proposal.
Based on the rest of this thread it looks like you're main objection is the wording I used (proposal versus some sort of preliminary design). So it boils down to marketing essentially.
I'm just one person and I'm fairly busy so I can't afford to spend the time screwing around with potential customers who are looking for free spec work. There's actually a significant number of people who heard about this web 2.0 social startup awesomeness and want to spec out their amazing idea with no intention of ever paying me.
It usually goes something like; "I think it'll cost around $xxxxx but I can't guarantee that until I've spent a good amount of time breaking it down into it's features with you to reduce risk for both of us and make sure you're getting something you really want."
It's at this point that I require an investment from them. It might not be a huge investment but it's generally a combination of compensation and their time (answering questions etc.).
I guess I just see most projects as more of a partnership to build something great. They bring the domain knowledge and I bring the programming / architecture know how. I won't partner with anyone who hasn't also committed their money, time, and resources. It sets a bad precedent to the relationship and they'll never value my work.
Everyone does things differently though, and I appreciate you're feedback. I don't think we're so far apart based on you're other comments. I stick by my recommendation, but feel free to reject it ;)
My segment of the software market doesn't require that I bill people to develop specs/quotes, but honestly, some types of software involve so much research related to the company, 90% of the project worth is figuring out what needs done, not the doing.
I do suggest that as a general rule for the OP, don't do this is a good idea.
"Cost of doing business" ... which eventually winds up being factored in anyway. I prefer the transparency that comes with listing how much I'm charging for the estimate as a line item w/in it. If they choose not to move forward, then no charge, else I treat it as billable time that lands in an invoice.
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.
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.
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.
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.
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".
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.
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.
Comments
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.
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.
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.
I respectfully disagree.
The last company I was at completely turned around when we stopped begging people to let us do their proposals and instead started charging them for the privilege to have us analyze their business, create actionable guidelines (that they could conceivably have anyone implement) and provide a quote for what our services would cost to implement them ourselves. They were welcome to take that strategy plan elsewhere, but when we started charging people for it, we had more clients than we knew what to do with.
People start to see you differently when you value your time, ideas and strategy and don't just give them away. Yes, there are some cases where it's worth doing one gratis, but the vast majority of time, we got more business by refusing to work with people who didn't run through our proposal process.
We probably don't disagree.
I am making a tactical point, and you are making a strategic point.
Strategically: of course you should structure your interactions with clients so that you are paid for your time, ideas, and strategy.
Tactically: avoid being that firm that wants money just to provide a proposal.
We are literally just talking about different ways to word things.
And while I totally believe your firm "turned around" once you started asking people to pay to get proposals, in my universe, the first purchase order you get from a client comes with multiple weeks of legal negotiation over an MSA. Nobody is going to do that casually.
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.
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.
> 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.
I guess this is ultimately what we did (had they turned us down on the main project, they would have walked away with the design spec). That's the standard policy now.
Yeah; I think I sounded pretty pedantic back there, so let me just say I don't think you're suggesting anything wrong. I'm just saying, I've seen fledgling consultants accidentally let themselves be perceived as billing for the proposal work, and I'm pretty sure that's a big mistake, worth calling out.
I've ran into a lot of scenarios where a client doesn't know what they want, and creating a proposal for them involves more of my time than it should. So as a result I'll offer consulting for a fee in order to come up with their ideal solution. This in term gets me most everything I need for a proposal as well as helps them to know what they are actually looking for.
The value add of consulting ends up working way better than directly charging for a proposal.
Based on the rest of this thread it looks like you're main objection is the wording I used (proposal versus some sort of preliminary design). So it boils down to marketing essentially.
I'm just one person and I'm fairly busy so I can't afford to spend the time screwing around with potential customers who are looking for free spec work. There's actually a significant number of people who heard about this web 2.0 social startup awesomeness and want to spec out their amazing idea with no intention of ever paying me.
It usually goes something like; "I think it'll cost around $xxxxx but I can't guarantee that until I've spent a good amount of time breaking it down into it's features with you to reduce risk for both of us and make sure you're getting something you really want."
It's at this point that I require an investment from them. It might not be a huge investment but it's generally a combination of compensation and their time (answering questions etc.).
I guess I just see most projects as more of a partnership to build something great. They bring the domain knowledge and I bring the programming / architecture know how. I won't partner with anyone who hasn't also committed their money, time, and resources. It sets a bad precedent to the relationship and they'll never value my work.
Everyone does things differently though, and I appreciate you're feedback. I don't think we're so far apart based on you're other comments. I stick by my recommendation, but feel free to reject it ;)
My segment of the software market doesn't require that I bill people to develop specs/quotes, but honestly, some types of software involve so much research related to the company, 90% of the project worth is figuring out what needs done, not the doing.
I do suggest that as a general rule for the OP, don't do this is a good idea.
"Cost of doing business" ... which eventually winds up being factored in anyway. I prefer the transparency that comes with listing how much I'm charging for the estimate as a line item w/in it. If they choose not to move forward, then no charge, else I treat it as billable time that lands in an invoice.
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.
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.
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.
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.
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".
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.
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.
This is brilliant. I'm going to try this on my next freelance gig.