Problems with charging by the job..

[DevMike]

I've noticed several posts where people recommend charging by the project...I've always charged by the hour, and I know that if I could charge by the project, I would have alot more business(mostly because people like 1 set price, not a range). The problem I find with charging by the project, is that customers dont really know everything they want when they hire you(most people only have a general idea, and think of a million things to add in while the project is being put together)..

What I want to know is how you guys handle this situation? Is this something that just goes along with charging by the project? Do you charge extra for anything not mentioned in the original plan?

[digitalv]

Charging by the hour is always better ... it reminds the customer that they are paying for those "this will only take you a minute" changes. When you charge by the job people typically keep adding or changing stuff. Even when it's outlined, they'll say "well we don't want to do it THAT way anymore, we want to do it THIS way" and expect the price not to change because they removed one and added another.

Unless you come up with some fixed "template style" sites, I would stick to hourly. A way to pitch it to the customer is to estimate how many hours it will take you and quote it as a flat rate estimate. The job is $5,000 and includes X hours of work. If it ends up taking less time, come off of the price. If it takes more, it's either their fault for adding more stuff (and you would charge them an hourly rate beyond that), or its YOURS for being too freakin slow and underestimating how long it will take you so you gotta eat it :P

[johntabita]

If you want to be a contractor, then charging by the hour is fine. The only problem is that, your income is limited by the amount of hours you can physically work.

The other option is to take a consultive approach. In this scenario, you are paid for the expertise you bring to the table, not how long it takes you to complete the job. Determining how long it will take becomes an internal function, so you know the bare minimum you can charge without losing money. It should be the starting point, however, not the ending point, in determining your price.

When you take the consultive approach, part of using your expertise involves helping the client determine "everything they want" and to help them think of all the "million things to add" before the project starts, and not after.

This is a double-edged sword, however, because now you'll have to close business like a consultant, which means that the client commits to doing business with you before you "help him determine everything he wants." If you do not get this commitment beforehand, you'll spend a lot of time "helping" people that do not ending up hiring you, and that's not very wise.

If you want to take it one step further (which I'm working towards; haven't quite gotten there yet), you can also use your expertise to help the client determine what ROI he'd like. All this really means is "sure, he wants a website, but what does he really want?" Typically it's money. If so, I’ll try to find out how much of an increase they want. Suppose it's a 5% increase in sales. How much more dollars of revenue does that represent? Let’s say it would produce a $2,000/month increase in sales. Now I can tell him that “this project will cost around $7,000. Considering the risks involved, are you willing to spend $7,000 to potentially make an additional $24,000 in additional revenue?”

ROI isn't always about money. Once consultant I know had a client whose ROI was, "I want to get home in time for my son's ball games."

The up side to this is that now you can provide some "extras" without it cutting into your costs, and you'll be happy to do so. And the client will be happy as well.

That said, I am very specific when detailing project scope, so that I will have the option of charging extra in the event that a client "extra" is unreasonable. Hope that helps.

[mep00]

Just because you charge by the project, doesn't mean that a client can add to it at will. The trick is to outline at the begining what the project entails and what the client is paying for. That way, any additions or other changes to the project gives you the right to charge extra for it (but you need to get the client to agree to sign off on it).

This doesn't mean you should charge for every change, just that you can. It's generaly in your best interest to allow some minor changes at no additional cost. (Since this always comes up, you should pad your initial estamate before giving it to the client to allow for this.) If the client asks for a large change, or too many small one, charge them for it.

When explaind in a professional maner, most clients won't object (they may decline, but that's something else); they'll understand that extras can cost extra. It's up to you to make sure they understand they are asking for extras.

[paladin]

In regenal it can very depending on you and the client. The formula that works for me is that I give a flat fee for the project, put ALL the details of the project and have them sign it. In the contract that they sign I also state the hourly rate for additional work.

When they want to start making changes as they see the rough draft of your work, which they always do, I then have a choice if to charge them or not. I had one customer wanted me to change the background color of the web site, not a problem as I way using include files for the head and foot - so it was a 2 second change that I did not charge him for. Later he wanted more and more changes, that with his agreement I did and charged by the hour. I ended up earning more with the additional changes then the original project fee.

It is also a good idea to take a down payment and set payment terms based on the project milestones if you can.

[Dudermont]

You have your projects so set out that you know where everything will be on the page, the menu style, the colors, everything? Even when the client wants flash involved too? Finding out what the customer really invisions could take half the projects time. Thats the problem that I am having with a client right now. I don't think I am going to do any more sites based on a set price. Is it really a change if it is not what he had in his head? I am noticing that he is varying some of the things that he said but I also find it hard to charge extra for something that you really can't say if it was what he was asking for when the contract was signed. (I know my writing even confuses me sometimes)

There are no extra pages, all the same things that are in the contract are getting developed, just how picky is your client? If it was by the hour I know that he would not want to make as many changes as he is, but from his point of few...

The price isn't changing, I can afford to be picky.

[King of Bling]

Fixed price vs. Time & Charges is the dilemma in website development, computer app development, and many other such projects. At the *heart of the problem* is the difficulty in estimating how long various tasks may take (how long to perform and how many iterations, minor and major, will occur).At the *heart of the solution* is communication.

If an agreement follows the T&C route, a plan should be developed and regular communication regarding questions and feedback are the order of the day. Stages can have dollar limits, which can lead to the buyer's decision to put the brakes on, change course, or continue. Communication and trust are key. Often, it can be pretty much a win-win environment for performer and buyer.

Fixed Price is not win-win but adversarial to some fair degree. The buyer wants to know ahead of time what it will cost ... sometimes even if they don't know what EXACTLY they want or if they don't want to take the time to develop specifications for the whole project. (Think: break projects into more than one piece.) Also, projects often have uniqueness, so that the performer may be tackling some new tasks and be uncertain of the effort required.

Under Fixed Price, the performer is faced with uncertainties and needs to be paid for risk, while the buyer seeks certainty. What exactly needs to be done and how long might it take? Written project specifications need to be laid out and agreed upon. As the project progresses, ANY change needs to be documented along with the change in cost. Thus additional time is spent by both parties on administrative tasks, and there may even be arguments, despite written specs, regarding if something is a change and what the resulting impact is. (If the performer has not required specs, then the performer may not have grounds to revise the cost.)

Under T&C, the buyer wants an estimate of delivery cost and time, just as he wants it under Fixed Price. In the former, the performer gives her _continued_ best estimate of actual. In Fixed Price, he need to factor in uncertainties and the cost of resolving problems. If the uncertainties occur and are not in the written specs (still quite possible), she _may_ be covered for extra effort, but if smooth sailing, she makes more profit.

Another trouble for Fixed Price is that even the professional performer may be tempted to take short cuts if he starts to run over or into deadlines. The performer is also less likely to suggest improved or added concepts during the project if it seems likely that unpaid time to define and reach agreement is likely.

Of course some purchasing environments may dictate fixed price. If that is not the case, a purchaser may not grasp the viewpoints of both "sides" and will need to be educated. No matter which path is chosen, CONTINUED communication is key. Walk in each other's shoes!

Long ago, I reached two conclusions: 1) No matter how intelligent and sincere the purchaser/user and developer are, it is not until the rubber hits the road (web site is up or computer app is in use) that the flaws in the assumptions and specs emerge. 2) It is a waste to over-specify, or to prohibit any changes to agreed upon specs; step-wise development and use, i.e., evolution, is often key to success.

(courtesy of)
Stacy Rowley

[JohnKelly]

I charge by the project initially (assuming new design), with the specifics laid out beforehand. Changes to the proposal after the fact will affect both timeline and costs, and is specified in te contract.

After site is completed, then it goes to an hourly rate (1/2 hour minimum) for the periodic changes required.

Major changes/upgrades/redesigns are usually again quoted on a per-project basis.

[Stores]

I am a firm believer on pricing based on value rather than cost. Trading time for money, you will always be capped on your earning potential. If you price based on value, you can make a nice profit, and afford to give the customer some of the "extras" that you might have billed them a few hours extra for. You have to accurately track the profitability of your jobs to make sure they are all profitable. Those that are not, avoid unless you have a good reason not to. In your proposal, let them know exactly what they are gettting and what they aren't getting. And also throw a clause in your contract that covers overages outside of the scope. If you do that, you can make a nice profit and still be covered if you have a difficult client.

[Dudermont]

How do you deal with the "Thats not how I wanted it". the site should be about content but this client believes it is ALL about the look of it. Every time that he sees it there is as many changes as the last time he saw it. When he requests a change he says after a minute...unless thats too hard/takes too long. I am pretty sure when I say "yes that is going to take to long" that he very well will not be a satisfied client anymore.

I know if it continues on then I will have to say that, but I am hoping that it is almost finished.

[mep00]

How do you deal with the "Thats not how I wanted it".

One of the advantages of following Web standards and using CSS is that it seperates the content from the presentation. Going that way, it's possible to get them to sign-off on the unstyled content and sample of the presentation without the content. It also makes modifications much simpler.

Also, try to get the client to explain in detail (and writing) what they want.

the site should be about content but this client believes it is ALL about the look of it.

You could try giving an extreem example. Compare a site which looks stunning, but is unusable, to a site which is easy to use, but looks plain. Which is better?

[Dudermont]

Yes separation is good, but unfortunately there is flash too, and described in detail when flash can look and act so many ways...is not that easy of a task. That is where all the time is going.

I think what I should have done is separate out the site and the flash as 2 different things. The site will cost this much. The 3 flash movies you want will be billed by the hour.

Oh well, live and learn.