You're completely right about this. You either have to overprice yourself in case of extra work or unforeseen consequences (taking the client to the cleaners), or pricing fairly but again unforeseen consequences occur (and YOU get taken to the cleaners). It's happened to me previously where I've drawn a spec out with a client, and hammered down exact content and sections, then received a phone call a few days later saying they forgot something critical, and would I be able to "sort it out"!
Best Wishes,
Anthony
Anthony Broad-Crawford
· 1 year ago
How do prospective clients typically react to this? I ask, as it makes total sense from your perspective. Additionally, it makes sense from your clients perspective. Curious to know the typical reaction from prospective client X upon hearing your pricing model.
albertG
· 1 year ago
Uhuh, you've got it all worked out haven't you? Unfortunately, in reality clients still expect an estimate of some kind. If you don't give them a fixed price they want an estimate of hours and if you don't give them either they walk. No sane customer will give you an open ended commitment to paying your hourly rate until the project is complete.
The client simply multiplies your hourly rate by the expected time to determine the expected price, which becomes your defacto fixed bid and you're right back where you started. Go over your time estimate and you have to deal with all the same issues you would have to otherwise, go under and you're losing money with respect to a fixed price.
The heart of the matter is this type of work is for fools. Developers aren't happy because they can't afford to do a good job, and are at the mercy of the irrational dictates of the client. The client might occassionally be happy, but only because they're ignorant of the pile of shit that's been delivered to them.
In other words: consulting work is bullshit, build products and sell them instead. But that might require learning something of economics and re-evaluating your attitude to open source.
Rick
· 10 months ago
Since when did clients become the enemy? Clients are the life's blood of my business and I am grateful for them. Perhaps you should find a career where you don't resent people so much.
Donald
· 1 year ago
I agree with Albert G. The client will simply multiply your rate by the number of hours you estimate.
Venkat
· 1 year ago
While what AlbertG says makes sense, most customers today are willing to see some reason. We work exclusively on hourly billing and this is the same argument we put forward to our client. While I worked with PeopleSoft and Oracle, I have had a similar experience while bidding for fixed bids. It's just not right to do fixed bids anymore. I tell my customers, happily, to choose another vendor who will do fixed bid if they wish. I also tell them that once they are done with them, I will be happy to do this for them from scratch.
Sid Savara
· 1 year ago
I think this depends on the job, and the level of trust the client has in your abilities. If you're talking about multiple man month projects in particular, I agree it's flat out irresponsible to claim you'll do it for X dollars in Y days with Z vague requirements.
Rick Bradley
· 1 year ago
I agree in part, and I disagree in part (with the original article and most of the comments).
A fixed bid job that spans anything more than a single agile iteration runs into the problems of rigidity, working against agility, lack of mobility wrt "critical" change requirements. It's not, in my experience, workable to fix a bid for anything past a single iteration.
On the other hand, customers do want to contain risk (basically ALWAYS), and uncontained price growth is one of the most significant risks.
One further issue that's not been mentioned is efficiency. If developers are working at an hourly rate the incentive is present to take as much time as possible in order to maximize pay. This runs counter to what one would want as a professional, as a craftsman: an incentive to learn one's craft so well that one becomes increasingly more efficient at it.
I would counter that the contention that a fixed bid ends up with clients getting taken to the cleaners is actually worse with the hourly rate: hourly developers, unless they continually practice discipline, tend to bill clients for time spent doing mundane things that would be automated away under a fixed-price structure.
I recommend a middle ground that addresses most of the risks:
* Jobs are estimated on a per-iteration basis, documented with a Statement of Work. An iteration is something like 1 or 2 weeks of work on a well-defined list of stories. * The work for the iteration is estimated and given a fixed cost. * Work that is "emergency" work, changes to scope, unforeseen but critical, etc., is billed at an hourly rate high enough to justify doing it, high enough to discourage thoughtlessness, but low enough that the client can see paying it.
In my personal experience, some deviations apply:
* If the work is on a system (and/or with other developers) that is such a mess that even single-iteration estimation is not possible, then the work is to be done hourly, at a high rate. But it becomes our responsibility to show the client why this is so. The majority of our clients don't have this problem, but the few who do are pretty aware of the mess they're already in.
* Some clients want a long-range estimate (say 6+ months). In that case we do more story work with them, do very rough estimates, explain to them why Agile works, and give them an estimate on the high side and provide documentation to the effect that this is in no way accurate, binding, or even in the realm of reality. If they insist on pinning down some effort/cost structure for a pie in the sky project we either multiply the estimate by a non-trivial factor, or we refer the client to someone else.
The short-term fixed bid has a number of advantages: * it actually limits some of the client-side risk by fixing price * it limits some developer-side risk by fixing the scope being tackled, and forces developer-client communication as developers are shouldering the risk of implementation * it limits longer-term risk by refusing to include risks that can't be studied or addressed in the current iteration * it forces developers to produce deliverable software on a per-iteration basis, as the customer can (and should be able to) go somewhere else for the next phase of the project * it forces developers to become more efficient at their jobs, as inefficient developers end up with a low effective hourly rate * it allows developers to potentially raise their effective hourly rates if they deliver valuable work to the client in a short time frame
If a client is willing to pay (say) $8K for a two-week iteration of working software that covers the 20 stories that end up in the iteration, and there's noone else in the market who can beat that price, I would contend that the iteration is worth $8K. If the developers end up spending $10K worth of time to deliver it they're not doing well, but have an incentive to improve. If they end up spending $6K worth of time implementing then they're doing better than the market average. Are they ripping off the customer? I would say no: they're shouldering the risk, charging what the market will bear, and being paid for becoming efficient at what they do. If they do shoddy work or if the market won't bear the price then their price must come down, otherwise I see this as a fair market transaction.
All that said, I've seen this in personal practice. My company has been the "back-end" (or "guest stars" in the client's parlance) for a couple of HashRocket "3-2-1 Launch" releases. Basically this means that for a fixed bid we come in and produce a working application *in 3 days*. We have been comfortable with doing that, everyone has found the results (both software and money) great, and it's single-iteration fixed bid work that requires us to be highly efficient at what we do.
Best, Rick
Kevin
· 1 year ago
Plenty of other professions (e.g. lawyers) bill by the hour, and somehow manage to survive... the concept isn't revolutionary. It's a matter of honestly setting expectations and not over-promising.
As to the argument that clients will just multiply rate by hours to derive a de-facto fixed bid - it's your job to clarify the nature of the beast: it's at least partially a subjective endeavor, and since changes have a cost to you, they have a cost to them.
Truthfully, there's a bit of a Catch-22 baked in: it's much easier to convince clients that you won't go wildly over the estimate if you have a body of existing work (and satisfied customers) to point to, but of course you need to land some contracts first. But that's common to starting out in general, and not endemic to the issue of how to price your work.
toolhater
· 1 year ago
albertg is gay. if you are worth a shit and better than just run of the mill, companies will ask for an estimate AND give you and hourly rate.
the other way around is simply the way cheap companies deal with shitty programmers.
kevins
· 1 year ago
The whole point of software is to leverage the ability get paid multiple times for doing something once -- you can sell lots of copies, charge recurring fees for hosting/support/etc or, ideally, both.
If you're writing code and getting paid for it exactly once, you're either a chump, or that's all you're worth.
Chris Tingom
· 1 year ago
Really great post. We've been tracking time and billing hourly for about 2 years now. I've really enjoyed it and it has made us and our customers more efficient.
What software do you use to track your time?
cak
· 1 year ago
You are completely wrong about this. Basically you are saying that you can't estimate how long a project will take, so you are not taking responsibility about this. This is a very important part of the process, judging how long a project will take and the amount of resources you need to throw at it, and you are saying that you CAN NOT do this. How any of your customers take you on is testimony to the ignorance or stupidity of your customers.
So you say you can still work with a company who has a budget for your project, but in reality you would use up there money, have half the project done, and therefore nothing to show for the money they have spent. They would either have to write of the money they have spend, or get money to finish the project. Rather than have a guarantee of deliverables. Once again, this is ridiculous.
I can't believe you are proud of the fact, and seem to brag about the fact that you can't estimate a projects time. If you can't estimate how long a project is going to take, how can you estimate how many resources to throw at it, or even if it can be done?
Thibaut Barrère
· 1 year ago
I do fixed bid if and only if the "project uncertainty" is very low. Known customers, with a relationship of quality, when the project has little technical risk and when the project or the iteration size is under 20 days of work.
Otherwise I bill by the day, where the day as a fixed amount of hours, for the reasons you gave.
Will
· 1 year ago
Nice article Chris.
@cak - We all have experience estimating how long it will take to complete a project. Remember, this is an _estimate_. The accuracy of the estimate depends on a number of things including the level of detail at requirements gathering and how much things change before the final delivery.
Just because you are Agile doesn't mean you do not estimate. From a long-term planning perspective you can still provide the customer with a time estimate. However, it is generally recommended to broaden the estimate the larger a project becomes. If it is a one year project, estimate that it will be completed Q3 2009. As you get closer to the end of the project, you can refine the target, like Sept 2009 or as you get even closer, a real date like Sept 26, 2009.
With a high-level time estimate, the customer can still budget for the project. You can give the customer a rate and a time estimate. Let them do the math. They will see that the project will cost them between $150,000 and $200,000.
One of the purposes of Agile is to give the customer what he wants, not what he wanted. A waterfall approach without communication with the customer during development will lead to delivering a product the customer will not use. With Agile, because you are in constant contact with the customer, providing regular updates on the product, you will be able to adapt to the customers changing needs.
The beauty of an Agile project is that the customer is able to provide feedback continuously. Many times this means delivering a better product in less time. The customer gets exactly what he wants and saves money at the same time.
All that said, if you are a company without a lot of credibility (like a start-up), many times you don't get to call all of the shots. If the customer demands a fixed bid, perhaps you take it because you need the revenue. However, you can still apply Agile principles within a fixed bid project. Change management just becomes harder with a fixed bid.
All Comments
You're completely right about this. You either have to overprice yourself in case of extra work or unforeseen consequences (taking the client to the cleaners), or pricing fairly but again unforeseen consequences occur (and YOU get taken to the cleaners). It's happened to me previously where I've drawn a spec out with a client, and hammered down exact content and sections, then received a phone call a few days later saying they forgot something critical, and would I be able to "sort it out"!
Best Wishes,
Anthony
The client simply multiplies your hourly rate by the expected time to determine the expected price, which becomes your defacto fixed bid and you're right back where you started. Go over your time estimate and you have to deal with all the same issues you would have to otherwise, go under and you're losing money with respect to a fixed price.
The heart of the matter is this type of work is for fools. Developers aren't happy because they can't afford to do a good job, and are at the mercy of the irrational dictates of the client. The client might occassionally be happy, but only because they're ignorant of the pile of shit that's been delivered to them.
In other words: consulting work is bullshit, build products and sell them instead. But that might require learning something of economics and re-evaluating your attitude to open source.
A fixed bid job that spans anything more than a single agile iteration runs into the problems of rigidity, working against agility, lack of mobility wrt "critical" change requirements. It's not, in my experience, workable to fix a bid for anything past a single iteration.
On the other hand, customers do want to contain risk (basically ALWAYS), and uncontained price growth is one of the most significant risks.
One further issue that's not been mentioned is efficiency. If developers are working at an hourly rate the incentive is present to take as much time as possible in order to maximize pay. This runs counter to what one would want as a professional, as a craftsman: an incentive to learn one's craft so well that one becomes increasingly more efficient at it.
I would counter that the contention that a fixed bid ends up with clients getting taken to the cleaners is actually worse with the hourly rate: hourly developers, unless they continually practice discipline, tend to bill clients for time spent doing mundane things that would be automated away under a fixed-price structure.
I recommend a middle ground that addresses most of the risks:
* Jobs are estimated on a per-iteration basis, documented with a Statement of Work. An iteration is something like 1 or 2 weeks of work on a well-defined list of stories.
* The work for the iteration is estimated and given a fixed cost.
* Work that is "emergency" work, changes to scope, unforeseen but critical, etc., is billed at an hourly rate high enough to justify doing it, high enough to discourage thoughtlessness, but low enough that the client can see paying it.
In my personal experience, some deviations apply:
* If the work is on a system (and/or with other developers) that is such a mess that even single-iteration estimation is not possible, then the work is to be done hourly, at a high rate. But it becomes our responsibility to show the client why this is so. The majority of our clients don't have this problem, but the few who do are pretty aware of the mess they're already in.
* Some clients want a long-range estimate (say 6+ months). In that case we do more story work with them, do very rough estimates, explain to them why Agile works, and give them an estimate on the high side and provide documentation to the effect that this is in no way accurate, binding, or even in the realm of reality. If they insist on pinning down some effort/cost structure for a pie in the sky project we either multiply the estimate by a non-trivial factor, or we refer the client to someone else.
The short-term fixed bid has a number of advantages:
* it actually limits some of the client-side risk by fixing price
* it limits some developer-side risk by fixing the scope being tackled, and forces developer-client communication as developers are shouldering the risk of implementation
* it limits longer-term risk by refusing to include risks that can't be studied or addressed in the current iteration
* it forces developers to produce deliverable software on a per-iteration basis, as the customer can (and should be able to) go somewhere else for the next phase of the project
* it forces developers to become more efficient at their jobs, as inefficient developers end up with a low effective hourly rate
* it allows developers to potentially raise their effective hourly rates if they deliver valuable work to the client in a short time frame
If a client is willing to pay (say) $8K for a two-week iteration of working software that covers the 20 stories that end up in the iteration, and there's noone else in the market who can beat that price, I would contend that the iteration is worth $8K. If the developers end up spending $10K worth of time to deliver it they're not doing well, but have an incentive to improve. If they end up spending $6K worth of time implementing then they're doing better than the market average. Are they ripping off the customer? I would say no: they're shouldering the risk, charging what the market will bear, and being paid for becoming efficient at what they do. If they do shoddy work or if the market won't bear the price then their price must come down, otherwise I see this as a fair market transaction.
All that said, I've seen this in personal practice. My company has been the "back-end" (or "guest stars" in the client's parlance) for a couple of HashRocket "3-2-1 Launch" releases. Basically this means that for a fixed bid we come in and produce a working application *in 3 days*. We have been comfortable with doing that, everyone has found the results (both software and money) great, and it's single-iteration fixed bid work that requires us to be highly efficient at what we do.
Best,
Rick
As to the argument that clients will just multiply rate by hours to derive a de-facto fixed bid - it's your job to clarify the nature of the beast: it's at least partially a subjective endeavor, and since changes have a cost to you, they have a cost to them.
Truthfully, there's a bit of a Catch-22 baked in: it's much easier to convince clients that you won't go wildly over the estimate if you have a body of existing work (and satisfied customers) to point to, but of course you need to land some contracts first. But that's common to starting out in general, and not endemic to the issue of how to price your work.
the other way around is simply the way cheap companies deal with shitty programmers.
If you're writing code and getting paid for it exactly once, you're either a chump, or that's all you're worth.
What software do you use to track your time?
So you say you can still work with a company who has a budget for your project, but in reality you would use up there money, have half the project done, and therefore nothing to show for the money they have spent. They would either have to write of the money they have spend, or get money to finish the project. Rather than have a guarantee of deliverables. Once again, this is ridiculous.
I can't believe you are proud of the fact, and seem to brag about the fact that you can't estimate a projects time. If you can't estimate how long a project is going to take, how can you estimate how many resources to throw at it, or even if it can be done?
Otherwise I bill by the day, where the day as a fixed amount of hours, for the reasons you gave.
@cak -
We all have experience estimating how long it will take to complete a project. Remember, this is an _estimate_. The accuracy of the estimate depends on a number of things including the level of detail at requirements gathering and how much things change before the final delivery.
Just because you are Agile doesn't mean you do not estimate. From a long-term planning perspective you can still provide the customer with a time estimate. However, it is generally recommended to broaden the estimate the larger a project becomes. If it is a one year project, estimate that it will be completed Q3 2009. As you get closer to the end of the project, you can refine the target, like Sept 2009 or as you get even closer, a real date like Sept 26, 2009.
With a high-level time estimate, the customer can still budget for the project. You can give the customer a rate and a time estimate. Let them do the math. They will see that the project will cost them between $150,000 and $200,000.
One of the purposes of Agile is to give the customer what he wants, not what he wanted. A waterfall approach without communication with the customer during development will lead to delivering a product the customer will not use. With Agile, because you are in constant contact with the customer, providing regular updates on the product, you will be able to adapt to the customers changing needs.
The beauty of an Agile project is that the customer is able to provide feedback continuously. Many times this means delivering a better product in less time. The customer gets exactly what he wants and saves money at the same time.
All that said, if you are a company without a lot of credibility (like a start-up), many times you don't get to call all of the shots. If the customer demands a fixed bid, perhaps you take it because you need the revenue. However, you can still apply Agile principles within a fixed bid project. Change management just becomes harder with a fixed bid.