So a client comes to me and says it needs some work done. Basically 4 tasks, which I agreed to perform for a certain price. The customer creates the job offer (a fixed time and price job) on ODesk, I accept it, but it took some days and constant reminding for the customer to initiate a contract based on that job.

The problem is that the original task has been completed, the contract is still active, I have not been paid yet, the customer says he will pay when the project is completed, and until then, new tasks occur constantly, or changes to older tasks that require full re-doing of elements. For all of this the client promises payment. No updates from this client on ODesk, no new tasks there. I keep reminding the client about sorting out the administrative issues, but with no results. At the same time, the client pushes on continuing work, since the project is soon to be launched.

I don't know what to do.

If I refuse to perform any work without the bureaucracy, the project will be late. But it's not my fault, is it? I am scared that I might receive a negative feedback in this case, or something even worse.

If I drop out of this project I'm afraid I won't be getting even what I've earned.

If I continue like this, I'll be wasting a lot of time doing stuff similar to the stuff described here, but as a programmer (yes, it has already come to similar requests, for lots of hardcoded content).

How do I communicate with such clients in such situations? How do I avoid a conflict?

P.S. The client is a small company. Different people handle different aspects of this project, and everybody introduces their own changes to the original specs.

After 2 years: Wow! Very question! Much popular!
I decided to let everyone in on the ending of this story. I've confronted the customer, explained that I will not work until I get paid for what I did, and until a hourly contract is open. They paid me the next day and opened a contract. A fruitful, but short collaboration started. Everyone was happy. Except I didn't get any feedback.

This question appears to be off-topic. The users who voted to close gave this specific reason:

"Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – MichaelT, gnat, Martijn Pieters, GlenH7, Kilian Foth

The problem with such contracts is that you can't ever guarantee what the customer will do. Sometimes they downgrade you even if the work is done!
–
Emmad KareemAug 23 '12 at 11:14

You will need to decide if your willing to withhold the product from the client if they refuse to pay. At this point you should not perform any additional work until you are paid. Clearly you should NEVER work for this client. If they give you bad feedback dispute it with ODesk.
–
RamhoundAug 23 '12 at 12:15

1

While possibly too localized... I do not believe it is off topic, Per the FAQ as on topic: freelancing and business concerns
–
maple_shaft♦Aug 23 '12 at 13:34

4 Answers
4

Oh man, I was in this position so many times back when I freelanced I'm feeling your pain right now.

It all changed when I changed my way of thinking about clients: all clients are con artists.

Let me say that again:

ALL CLIENTS ARE CON ARTISTS

When you change to this perspective it is when you realize you actually have the leverage most of the time, even when you don't have a contract that backs you up.

Here is what you do:

If you have delivered already, you are already screwed: At this point you must decide if you want to keep getting screwed and have the client continue making you his b****.

If you have not delivered, there is hope: The launch is your leverage and you can still get paid. Negotiate payment for at least 50% or just drop the whole project and leave him to his luck, this is your leverage. I was in this position at least two times and didn't take the chance when I could, things went bad for me and I paid the price. It sounds cold-hearted, but this is often the point of no return.

If you think this is just a communication problem, you can fix it (if and only if the client wants to): You can use the previous still as a leverage, but the solution is to ask the client to designate a single representative for the project, your best options for this are:

The project owner

A stakeholder designated by the project owner

The owners' "right-hand"

This will effectively make them funnel all requests to a single point where things can be sorted out on their side, not on yours. You are experiencing a mixture of feature creep and lack of expectation management.

In any case and if I were you, I would contact oDesk for assistance with this case. I'm sure there are a lot of clients who behave like this to extort more work out of contractors. If you have evidence that the project is complete according with the contract, use the contract as your weapon.

I'm sure oDesk has contracts for something.

Also, it can also look like being cold-hearted, but when it comes down to getting screwed or not screwed, their launch, their deadlines, and their mind-faps are their problem, not yours.

I made the mistake of caring too much about the client in my days, but you don't have to.

Edit: Last piece of advice, don't make the final delivery until you have the final payment. You can always give a demonstration in your own laptop/premises to assure everything works.

Alternatively and if you have absolutely no choice, and the customer needs the application deployed to pay you (because it is in the contract, otherwise don't give in), deploy it in your own infrastructure and give no access to it to anyone other to those that you would trust with your life (I'm serious about this). This is your last possible leverage where you can say: "you have X days to pay up or the service will be taken down". Pretend that he is renting a house you own, and he might just leave one day unannounced and you will never be able to track him back or give him a reason to pay you.

Assuming all clients are con-artists is not very fair, perhaps just the ones that insist on fixed price with loosely defined requirements with little to no percentage upfront.
–
maple_shaft♦Aug 23 '12 at 13:38

1

The role of the service provider (contractor in this case) is to provide as little of the service as possible for the greatest amount of money. The role of the consumer (client in this case) is to use the service as much as possible for the least amount of money. I consider "con artists" to be in the service provider group.
–
zzzzBovAug 23 '12 at 14:05

Thank you for an experienced insight. I don't think it's appropriate to differentiate clients from providers and saying that one is a always a con artist, but your advice really helped. I confronted the customer with this problem in the "will go no further" way, and it got solved immediately. They were either testing me, it was a big misunderstanding, or some vast internal lags in their company.
–
TheLonelyCoderAug 23 '12 at 15:56

1

@maple_shaft I know I'm being cynic and unfair, but it is something that can help you anticipate, well... cons
–
dukeofgamingAug 24 '12 at 3:46

@TheLonelyCoder I'm very glad it worked for you. A little cynicism is healthy and you can negotiate better when you don't fear losing what you might think you have.
–
dukeofgamingAug 24 '12 at 3:51

Typically when you have to hound your client for updates that's a bad sign.

I also work on oDesk; and going forward you might want to consider working exclusively on hourly contracts and estimating up front how many hours give or take a task would take you.

On hourly contracts you can correctly mark what you've worked on and how much you're owed. It's much easier to get oDesk to force the client to pay up.

On fixed price contracts, there is no chance. Your client and only your client decides when and how much to pay. oDesk even says so in their documentation/support site. I'm sorry to say, if your project is fixed price; I'd say hold the work for ransom and demand whatever you can get - then bail.

What does 'complete' mean? Does it mean 'All the tasks in the contract are done'? If it does then your client is clearly in breach of contract and you should consider getting a lawyer to write him a 'friendly' letter to remind him of his obligations. You should keep that as a last resort though, and try to take a more diplomatic approach, such as trying to renegotiate the contract to include the tasks he's adding on on contingent that a) you get paid for the work you've already done as per the terms of the original contract, and b) you'll also be paid for the extra work done.

If the contract stipulates that you'll be paid when the project is 'complete', however, then you might be in trouble. Ask any good developer and they'll tell you that software is never complete, it's either under maintenance or it's abandoned. If you agreed that the client can pay on completion and it goes to court, his defence will probably be that the project is not complete because there's a huge list of requirements he added to the project that you've not done.

I hope your contract states that you'll be paid on fulfilment of the requirements defined in the contract. If it is, and if it's clear that your client is deliberately jerking you around and trying to extract work from you that you never agreed to, then you have options. If it says "payment on completion" then you may have considerably fewer options. You could try renegotiating the contract but if he's not willing to budge then I'm not sure where you can go from there.

EDIT TO ADD: The "everyone keeps adding requirements" comment at the end of your question is ringing serious alarm bells with me. I hope you've not accepted any of the requirements anyone other than the person you negotiated with to the work list! You should accept requirements and change requests from only one person, otherwise chaos can ensue. Person A might think it would be neat if you added feature X to a project, but if it's person B who's paying and they don't know person A added a feature to the project, they could get the impression you're adding stuff they didn't ask for to the project just to get more money out of them. That's bound to result in bad blood. Worse, you could end up with a total mess of a project with a load of conflicting requirements and code that doesn't fulfil its original purpose because it's trying to please a load of other stakeholders as well. There needs to be a well defined process for adding requirements, and the person who pays the bills has to be fully aware of any requirements that get added.