Fog Creek Software
Discussion Board

does fog creek charge by the hour or project?

In general, how does Fog Creek bill clients for consulting

I am assuming by the hour, but Joel and Co. seem have scheduling and spec writing down to a science. And, perhaps clients come to Fog Creek when they know exactly what they want.

Just curious.

Monday, May 6, 2002

Since I hope Fog Creek (and therefore Joel On Software) will be around for many years, I sure hope they charge by the hour.  In my experience, fixed price contracts are only used by companies that don't know any better or can't get clients in any other way. It produces nothing but headaches, long hours and (a lot of the time) lawsuits.

Jeff Pleimling
Monday, May 6, 2002

The company I work for usually charges by the job, not by the hour, for contract development. We have been around for 20 years and are profitable. How do we do it? We charge fixed HIGH prices. Do we get burned on some contracts where we underestimated the complexity and have a senior engineer working on a $60,000 contract for nine months? Yes, it happens. But it also happens that occasionally we can charge $60,000 for something that ends up taking one DAY of an engineer's time. Not always, of course, but sometimes.

It helps that our typical projects are modifications to our standard "shrink-wrap" software.  We generally feel that if a customer wants a feature added to our software so badly that they are willing to pay us well to do the development, then it is probably a feature worth adding.

Tuesday, May 7, 2002

Nonconsultant -- Your description of what happens with job pricing is a perfect example to show why it's bad.  Sometimes the job price might turn out to be close to what it would have been with a per hour rate, but sometimes (often) either the customer gets screwed (job would have been much less on a per hour basis) or the contractor gets screwed (job would have been much more on a per hour basis).

It boggles my mind why it would be regularly used, unless the person in favor of it thinks they've somehow pulled the wool over the eyes of the other party and are certain that they're going to be getting the long end of the stick more often than not.  But that's a bad way to do business, in my view.

Much better just to charge hourly rates.  That way the client pays for the amount of work that gets done and the contractor gets paid for the amount of work he does.  If you're a hotshot contractor, just charge more per hour, and tell them that you're worth it because you can do a better job than others in less time.

The job rate is not bad only in software consulting, applies to just about anything I can think of:  plumbers, electricians, just about any manual labor jobs; as well as most professional services.

Herbert Sitz
Tuesday, May 7, 2002

(Wish I could edit my last message.)

Another reason why job rates are bad:

They tend to encourage shoddy work.  When a contractor is being paid a fixed price, it's to his advantage to get the job done as quickly as possible, since he won't get paid more by spending more time on the job.  This tends to encourage the contractor  to do "just enough" (and maybe not even that) to get the job done.  To easy for disputes to arise regarding the job is done or has been done right.  If you're on an hourly basis, the contractor can just say, "Well if you're happy with what I've given you so far, I can stop.  If you want things refined a bit more I'm happy to keep going."  That option isn't available to the job rate contractor.

In my opinion, the only time when job rate contracting may be appropriate is when the client is very concerned about cost overruns, but at the same time has plenty of cash for a project.  The contractor can then give them a job rate, with the explicit warning that the job rate is higher than what they would probably end up with on hourly rates, because the contractor then bears all the risk of the job taking longer than expected. 

Herbert Sitz
Tuesday, May 7, 2002

So charging by the job encourages shoddy work. I guesscharging by the hour encourages "working" more hours than necessary. In either case bad service is being given.

To clarify things, I think one reason we charge by the job is that we do the work at our plant without any supervision by the customer. It's impossible for the customer to verify that we spent X hours on the project. But it is possible for the customer to evaluate what we give them and either accept it or turn around and tell us there's a problem and we have to fix X.

As a consumer, I prefer using professionals who charge by the job. Why else would auto mechanics consult books that show how many hours a particular job "should" take? They charge you based on what's in the book. If their guy gets the work done faster, good for them. The customer gets their car fixed faster for the agreed-upon price. If their guy works too slowly, it's their problem. Except that you don't get your car back quickly enough.

I don't think the customer gets screwed when the stars are in alignment and a job takes less time than predicted. The customer wouldn't have contracted for the work unless they thought it had more value to them than they were paying. And if the stars had lined up the other way the customer wouldn't be paying less.

The bottom line is that the place I work has been doing this consistently for 20 years and making money at it. We don't do shoddy work because we have a reputation. Most of our customers are repeat customers and they simply wouldn't buy from us any more if we gave them shit.

Tuesday, May 7, 2002

I generally charge by the job. The reason: code re-use. A while back a built a website for a client with a nested menu system with dynamically generated menu items. When I wrote the code, I created a new menu class and wrote the recursive functions to fetch an arbitrary number of levels of menu. When I was finished, I debugged the code given a number of different possible values in the database.

After that project was over, I had a nice tidy working class for nested menus. Cool. I've used it again for other clients, and I still charge them the same amount. They get the same cool nested menus as that first client. They are paying for the final product. They don't need to know that I'm modifying old code for them.

And that's what software development is all about.

Benji Smith
Tuesday, May 7, 2002

Fixed price in my experience has always created an adversarial relationship between the client and the service provider. Either the consultant (ME) is trying to do $10,000 worth of work in 1 day (which is rarely honest, unless you are selling diamonds) or else the client is trying to squeeze a $100,000 piece of work out of me for $10,000.

Certainly if your business has been doing this for 20 years with no problems, you've figured out the right way to do fixed price.

Regarding car mechanics, most techs I have seen indeed do charge a fixed price rate for common tasks, like an oil change, or checking over a used car before a sale. However, most do not charge a fixed price for anything more complicated than that. They have a standard hourly rate.

Some sysadmin style tasks could be priced this way (install sendmail for $400, etc) but I don't see it making sense for most software. If you know how to do something that's easy to put a price tag on, why not just productize that bit of code, and sell a license?

Tuesday, May 7, 2002

I agree with Consultatron about auto mechanics.  They have a manual that tells them (and you) how many hours a job should take.  But I've never taken my car to a mechanic who does non-routine work at a job rate, always hourly.

I didn't mean to imply that to use a job rate is some morally bad thing to do.  I just think that it does tend to encourage shoddy work (not I only say "tend to encourage") more than hourly rates do (and I recognize that there's room for abuse of hourly rates too). 

It appears some people like to charge job rates because they feel like they have a leg up on their competitors, perhaps with a highly developed tool set that helps them get things done more quickly. 

All this seems to me to be tied somewhat to the discussion in the "Five Worlds" thread in an interesting way.  Consultants charge for their services and typically don't deliver software that is as polished as shrink wrap software, which is purchased as a product.  I think the consultants who charge job rates because of superior toolsets and reusable code are mixing together the sale of their services and the purchase of their product.  It's best to keep the two separate, in my opinion.  Consultants, as consultants, have only their time to sell (which they apply with varying levels of expertise).  If they're mixing up some pre-existing code in the price, then they're really charging partly for a product they already have.  That's fine, but however it's done, I think it should be made clear to the customer what's going on.  The client relationship is an important one and you want to avoid misunderstandings.

Herbert Sitz
Tuesday, May 7, 2002

Fixed price is deadly for inexperienced consulting firms. To make it work,  you need to charge about ten times the predicted real cost. This gives you plenty of margin for unexpected things, lets you make a profit and, most importantly, lets you stay bright and happy with the customer.

For the customer, reliably delivery of high quality product is usually more important than the budgeted cost. This is because, presuming the deal is done, the budgeted cost has been approved by the customer's financial systems and everyone's OK.

Where a consulting firm starts thrashing on development, or fails to deliver, there are big non-monetary costs to the customer and career costs to the people who selected the consulting firm.

High Wells
Tuesday, May 7, 2002

*  Recent Topics

*  Fog Creek Home