Trust issues with a client

Question

I've been negotiating recently with a client who is... well... a bit difficult to work with, to say the least.

He was the first to contact me and request my services. He wants me to build an enterprise class app for his company but he is very unwilling to divulge information and the requirements regarding the project.

I asked him to tell me more about the project (as I have no idea what we're building) but he claims it's "sensitive information". I even signed an NDA and assured him I had no interest in stealing his idea, but he still won't relent.

He's been giving me very incomplete pieces of information and is expecting me to give him a quote for the project based on what little information he shared. I told him that I can't build something and if I don't have a specification and unless I know what exactly I'm building, but he's still being extremely secretive.

I can't work like this. There's a lot of money in this project but I can't work like this. It's like asking a construction company to build you a house exactly according to your plans but then refusing to give them the plans.

Should I just give up or try to work with the guy? This seems like one of those projects that might become pure hell somewhere down the road.

Answer 1

You could try one technique that is pretty common in the architecture world (as in buildings). Sign an hourly time and materials contract to develop a scope and use that scope as the basis for a real contract. Since the current process is open ended, T&M is about the only way to go. It places the client in the best position, too, but not everyone seems to agree with that.

However, this is not looking so good. Make sure you bill regularly (twice a month) and don't let the odd communication pattern place you in a spot where you could get sued or not paid.

Answer 2

I've had a few of these and unfortunately, they can be extremely stubborn.

After I give up digging for information, what I normally end up doing is:

1. Try to at least get a ROUGH idea of what he wants and walk away if this is not possible.
2. Offer to do the basic stuff (e.g. login, maintenance screens) first for a fee and make sure he is willing to pay for these non value generating stuff.
3. Pray that after he sees the skeletal structure, he's confident enough to tell you more so you can proceed with the next step. He has some "buy in" at this point and your odds are exponentially better.
4. If he gives me some "real" info, do those screens for a fee
5. Demonstrate the product and ask for more input, making sure you are paid.
6. Rinse/repeat steps 4 to 5 if you are lucky, 2 to 3 if you are not :P

If the work is ok and he get's a little more confident in you, things might pick up speed QUICKLY. Once the dam breaks its normally an avalanche. He'll tell you lots of stuff and expect all of it to be done YESTERDAY because every second of delay is causing him extra anxiety (if you leaking info is his primary concern, and it normally is). When that happens, feel free to charge a little extra for refactoring. Once he spills it, he's normally willing to pay. If not, just say you'll think about it, walk away and wait, they normally call back.

Don't go easy on the fees if you get to the 2nd part. These projects are ALWAYS full of spec changes and time pressure. Make sure you bill what you are worth or it's really not worth doing.

Answer 3

Many clients don't know what they want. You're no better off working with them or a client who supposedly knows what they want but won't tell you.

You sound like an honest person who takes pride in their work. Your quuote must be based on the information you have. Your competition isn't any better off. What is the going rate for enterprise apps in this industry and how long does it take to build? If you've never done this before, you're at a disadvantage. A competitor is going to blow smoke and proclaim they build apps like this all the time.

Estmate the number of hours and the rate, but indicate this may change if the specifications change. And they will change. If the client doesn't agree with your new estimates, get paid for time served and move on.

Answer 4

Most of the comments seem to focus on how to ensure you get paid, and if that's your concern then you've already gotten some good advice.

But it sounds like you're as concerned about doing quality work and seeing a finished project deployed as you are about getting paid, in which case you need to get this resolved up-front, BEFORe you do any work.

My suggestion is that lay it out for him, and explain WHY you won't be able to build what he wants unless he's a bit more trusting with info. Use your building/plans example. Spell it out for him - "I can make it do X, but if you want it to do Y also, then I need to know Z. "I can't make it do something if I don't what that something is supposed to be."

You can also use the T&M issue here - explain that there are several ways to pay for something like this, T&M being one of them. But without more information, he's going to pay you build something, then pay you more to modify it once he see's it and it doesn't do exactly what he wants (due to lack of up-front info), and in the end, if he's not more forthcoming, he could end up spending money for something that is ultimately scrapped.

And one last argument - make it clear that ALL (good) programmers are going to want this info, not just you, so he needs to make a decision now as to whether he's going to let go of this info.

Answer 5

(I asked a professional programmer, so not my knowledge but I agree)

Tell him flat out that your(and anybody else's) quote will be widely inaccurate unless enough information is supplied. Try to ensure that the time is flexible in your contract.

If you're not sure of your abilities, then it's better staying away from this... If you later realise that the project is beyond your abilities, you'll be in trouble. Unless you keep a clause in your contract that allows you to withdraw at any time. Though I doubt he'll agree..

Answer 6

There is nothing in your power to solve the problem of his secrecy. But you could make some profit regardless.

Make your guesstimate and be honest that it is guess because of the lack of information. The contract should protect you against the uncertain time length. Have written into the contract that work is charged per-hour. To be fair, give him the ability to back out at any time, but still owe you for the hours you worked.

Once you have the contract.... he'll be forced to give you whatever info you need and then you can make your good estimate.

Answer 7

Without detailed requirements the only way to work with him without taking a huge risk is if you are paid on a time and materials basis. Just offer your skills at $X per hour, if he insists on a fixed price then he is probably trying to rip you off and you should leave it.

Answer 8

I suggest giving him some options:

1. He gives you sufficient information for you to be able to give an informed estimate. (Remind him that everything will be covered by the NDA and that you have no desire to spend the next few years going through the courts.)
2. Give him the option to have a fixed-cost estimate on the insufficient information supplied so far, with the stipulation (to be included in writing) that whatever is delivered on that basis is deemed to be accpetable, regardless of how well it actually meets his requirements.
3. He employs you on a time and materials basis.

Answer 9

I support the other suggestions for Time and Material.

Your potential client is likely to not like this idea and one way to mitigate this is to create rapid delivery cycles. I.E. go to an agile release style. Start with something simple like a part of a user interface he wants, something you think can be done in a week or two at the most.

And then deliver.

And then ask "is this what you wanted?"

From here you end up with two likely courses of action.

1- He'll ask for tweaks and slowly give you more requirements. You'll charge him Time and Materials and eventually build him what he wants.

2- This builds mutual trust and he'll be more open with the project. Then you can do some planning and estimating from there.

With this kind of client, small bites, quickly delivered are your best bet. He's likely to change his direction as you implement and he realizes reality.

Answer 10

The main point is the trust between you and your client. Trust goes in different directions here:

• Does the client trust your capabilities?
• Does the client trust you not to run away with information?
• do you trust your client to pay?
• do you trust your own capabilities?

The way I read you question, the client puts a lot of trust in your capabilites, but he has no way of communicating his idea to someone so that the idea can become a reality.

You, on the other hand, trust your capabilities, but are afraid, rightfully so, of scope creep.

You wrote "i cannot work this way" twice, I think this is very important for you to get this accros to your client. Make it clear that, if he wants his idea to become a reality, he will have to talk details at some point.

If he wants a fixed price project, you need scope and details to plan.

Another posibilty is to build up more trust, while doing the project. In Agile/Scrum you commit to deliver a working increment every XX weeks. Your client will get something working fast, and can add features as he likes, as long as he pays. If one of you backs out at some point, the client will still have some kind of working software, doing at least what he paid for 2 weeks ago.

Talk, try to find out what your client is afraid of, and be honest if you have not enough information to make a fixed price quote.

Answer 11

When I first read your question a quote popped into my mind: "Run away dude, run far, run fast!" (from a Big Bang Theory episode). The thing is that there's a serious trust issue as the others highlighted. Based on the information you shared I don't see a chance that your customer will change its mind in the future.

I was working a little bit in an environment where the customer didn't trust us at all, and I'm just happy that we left that project. I suggest to leave and don't put too much effort into a project which will leave to a nightmare. One example: what happens if you want to use a third party product? I assume, you'll spend some time explaining to your customer that this tool won't share any information about the project. You'll end up working on the customer not on the project. Just a huge waste of time.

I think you can spend your valuable time working with somebody who pays less, but trusts you.