views:

630

answers:

11

I’m just wondering what strategies you guys have for not being taken advantage of by clients.

This mainly relates to them getting me to do free work.

I do free-lance contracting, building websites for a handful of clients.

I write fee proposals which set out exactly what they are getting for their money and I do have it in my fee proposals "that if it isn’t in the proposal, it isn’t covered by the project fee".

I can be strict and say "that feature is an additional cost" to everything the client says, but can you imagine how that will affect the client-supplier relationship, plus it would result in the project taking forever.

Any tactics guys?

+7  A: 

I personally follow the same idea as you, but there are two distinct additions that I make that has been really good.

1.) If I see any potential scope creep areas, I cover them in depth with the client beforehand, to try and work out additions before we start. Modifying the bid as needed.

2.) I build into all proposal __ extra hours at no cost. I'm doing things project by project, and I know that things are going to come up, so I just cover it by providing the little extra right out of the gate.

I find that with #2, it is easy to get to that value and start charging, and no-one has complained yet!

Mitchel Sellers
I really like the x extra hours idea. Thanks!
Draemon
A: 

Delegate to tougher guys who's used to talking about money with clients.

eed3si9n
+4  A: 

You answered your own question. Be strict and say "that is a costed feature addition" to everything the client says.

In actuality, there is always some give and take. You have to decide where your personal limit is. It is always nice to give a little more than you promised, but I prefer to satisfy a client by delivering a quality product on time and budget, than an app that has more features than originally agreed upon, that will likely compromise quality and timelines.

In practice, my experience has shown that clients will respect you more when you draw the line somewhere. By valuing your own time, they will come to value it more. This is where you have to wear more than one hat as a developer. This is account management, and is something that does not come easily to most developers. But it CAN be learned through practice, and honesty with your client.

RedFilter
I think your first statement is a little too blunt but the rest is very useful
Draemon
I agree, that was really for impact :) That is why I quickly followed up with the give and take bit.
RedFilter
A: 

I'll just add to these previous answers that you also need to show stature before your client.

Experienced clients will keep their suppliers happy, especially if they're outsourcing or contracting a freelancer. A happy supplier is more motivated and ensures a neater and tighter end product. They'll make sure to keep everything clear so that the supplier doesn't go off asking himself questions.

If you keep a straight-up stance with your clients, they'll pick up the signals. It'll make everything clear for that experienced client and the inexperienced one will be put off with asking those sensitive questions ;)!

kRON
+4  A: 

Always be up front and honest with the customer, also, when we provide a fixed-price quote we always let the customer know there could be as much as a 20% overrun. This will be for additional costs they might have to pay. This allows us to allow for change in the project without having to quote every little scope change.

mattruma
+2  A: 

As part of the original contract, include a certain number of hours for extra work / support.

Then as you do the various things they are requesting, take the hours our of this allotment, and when it gets low let them know they need to pay for another block of time.

We have this arrangement with a contracting firm and are quite happy with it.

  • set monthly fee
  • daily/weekly admin tasks
  • certain number of hours for custom work
  • option to pay for more custom work when we exceed the monthly allotment.
Mark Harrison
+1  A: 

Many of the previous comments were good. My own experience suggests a couple of additional steps you might consider.

  1. Be detailed enough in the statement of work that you can do more pay-as-you-go. Schedule frequent reviews with the client to demonstrate progress against the statement of work, and bill for completed tasks.

  2. Make sure that each step in the task list (S.O.W.) reflects actual value-received progress for the client.

  3. Recognize that the client is the client (in other words, take hints from agile practices). If the client asks you to do something outside the statement of work, simply reply, "Sure. Do you want me to do this instead of the next task on our agreed list, or in addition to it?"

joel.neely
+4  A: 

Risk is not free.

When you are newly out of college and have no credit history and want to buy a car, the bank is taking a risk on your ability to pay. That risk is not free, so you pay a higher interest rate.

When you buy that (used) car, and you want to make sure that you aren't out your 8 grand when you accidentally slam it into a fire hydrant and total it, you are taking a risk on yourself. So you find a company who is willing to exchange that risk with you for a monthly price. This risk is not free, so you buy insurance.

When you embark upon a fixed price contract for software development, and your client gives you a spec, you are taking a risk that the client's spec is complete. That risk should not be free either, and your client will have to pay for it by a certain markup in the price of your contract. What that risk is worth is up to you, but it must be baked into the price. The more general the spec, the higher the risk to you. Price that accordingly.

Whatever you do, don't get caught into the naive idea that an estimate for a fixed price contract should be the number of hours you expect times the rate, because you would be the only person I know who is willing to take on risk for nothing.


Actually, if you are willing to price your risk at $0.00, I could really use a 2 grand loan for some christmas shopping. I promise to pay you back... ;-)

Dave Markle
+1  A: 

I'm doing freelance contracting in software development, mostly backend.

I think that due to the complexity of such projects and the difficulties of writing an unambiguos specification, smaller changes are unavoidable and should be part of your calculation right from the start.

Strictly blocking will be seen as rude behaviour by the customer, so that's out of the question. But when you're doing extra work, you should document it (e.g. meeting notes accepted, best signed by the client) so that when you come to the point where you have to ask the customer for extra money, it will give you a much better discussion base if you can show him how much you did already "for free".

Usually I have contracts where I get paid by hour, so changes are annoying for me because I have to throw away previous work or do conceptual changes (or live with unclean additions to the concept), but don't do more serious harm. Maybe it would also be a possibility for you to include an additional hourly rate for later changes and maintanance in the contracts - most probably you'd like a maintainance contract anyway, don't you?-)

mh
A: 

some excellent answers here, ones which will be causing me to change some behaviors in future when tendering work - especially telling the client "this is the documented cost for these features, but you need to account for and ready a small budget for changes which may occur along the way" (thx MattRuma).

a few people have also said here smart clients keep their suppliers happy. so many clients dont do this because they assume its a one way process (i.e. "i pay, you do"). i have one client who pays my invoices within 1-2 days of me sending them - because of this, im like johnny on the spot when he asks me to do work for him. i often start his work on the same day as he requests it.

another thing i have noticed recently is that different development methodologies work better for some clients then others . for instance; i started one project a few weeks back which was more agile, its turned out the client isnt suited to this approach so im shifting towards more of a waterfall model (with a lot more bureaucracy and approvals required before i undertake work). another recent client worked great with an agile model, where i mostly winged it and he was 100% happy.

LM

louism
A: 

My main points about this:

Open communication and clean documentation:
Communicate clearly what are you doing for how much money.
Document everything you do outside of the original contract, and communicate openly about this being outside of the original contract. Of course, document everything you do, too. Give regular feedback about what you have done in and outside of the original contract so far, so there will be no nasty surprises in the end.

In my experience most customers don't want to rip me off. They just want to make sure they are not ripped off by me, and communicating openly can reduce this fear.

Sam