11

One of our junior developers has been assigned a new client (we don't have the client yet, we're still working with him to see if we can meet his needs) and the junior developer said the client will hire us if we can do the work on his project without getting access to his server.

I've had a direct conversation with the client who turned out to have had his code stolen before by some offshore company that he outsourced. This made me more sympathetic but I still have mixed feelings about this.

On one hand I want to prove to the client that we're not all bad apples. Also if we do a good job with him, we get a loyal client who'll hire us for all his projects. I haven't heard of this happen before but I guess it happens more often than we'd all like to admit.

On the other hand I'm hesitant to accept working with him because deployment time is going to be a nightmare and no where in my career or education has anyone taught me how to work with clients like him. I (or the junior developer) would have to write a detailed description of exactly what to do with the source to deploy it and that is an annoying burden when I could deploy and test the whole thing in an hour myself.

As I said, I've never had to deal with this before (we're signing a non-disclosure but apparently so did the offshore company before us). We're not fully fully booked so it's not like I have an immediate replacement, but we're not begging for work either and I wonder if working under such restricted environment is worth the trouble.

Another side is that the experience itself could be rewarding for us, but is it experience worth having, as in what's even the likelihood of getting a similar client anytime soon. Are we even expected to comply with such clients?

So since I don't have any first hand experience with this and it definitely wasn't covered in school, how would those with longer experience working with clients deal with a distrusting client like this? Would you even accept the job?

user5794
  • 151
  • 4

7 Answers7

13

Work with the client, and add hours of extra (billable) time to your quotation for every task, to cover the hassles of deployment without server access.

It's depressing to be limited like that due to (unfounded) trust issues, but really, it shouldn't be that burdensome. I've worked with a number of clients where we had to work this way, not due to them not trusting us, but simply because they were huge companies with blanket IT policies. It just means you need to be more disciplined about your deployments so you're not deploying, fixing a tiny bug and deploying again, realizing you forgot a file and deploying again, etc. etc.

Carson63000
  • 10,500
10

You start working with the client. If there is no need of any other resources for completing your project, then you are through that restricted environment.

And if you feel a need to have something which is restricted to you, then talk to client about this issue. Do the critical stuff in front of him.

And last option but better, since you are not begging for any work, Kick it off! ;)

By critical stuff, I meant access to the clients code.

ivorykoder
  • 321
6

Actually, a detailed description of how to deploy is valuable in itself. Your client may want to be able to control deployment rather than going through you each time. Just include it in your estimates and make sure you get paid for it. Not having access to the client's server is going to make things take longer in general, but that shouldn't itself be a problem. Remember that there also can be perfectly legitimate legal or liability reasons why you don't get access, so you probably want to have some idea how to work without access.

In any relationship where there's a trust issue, I'd pay attention to the payment schedule, and make sure I was never owed more money than I was willing to write off if things went bad. Distrust in one area can spread.

David Thornley
  • 20,270
  • 2
  • 56
  • 83
3

Explain to the client the full implications of their restrictive policy. Charge for extra work during development and deployment. It is for them to decide if the restrictive policy is worthwhile.

The most serious downside is not the extra hassle you will go through in development, but slow turnaround with bug fixes after launch. Unless your system is dead-simple (or your name is Donald Knuth), you will have bugs after deployment, no matter how careful you are.

dbkk
  • 2,136
3

I have worked with a fundamentally distrusting client and it made life exceedingly difficult.

In most countries if you have a contract with a client then you can make explicit what will and will not take place and the contract will be binding. You may be able to reassure your client by pointing out that as a company based in the same territory, their complaint will have full force of law if you do steal their code.

However there is a difference between someone who has had their fingers burnt and someone with a paranoid nature. In the latter case I would avoid the client altogether as they will be difficult and expensive to deal with. Not impossible, but very difficult, very irritating and most likely to be among the 20% of clients who provide 80% of your support load.

glenatron
  • 8,709
3

I have worked in IT and government for many years. In those environments developers NEVER have access to the production system. It should be par for the course to provide installation instructions especially for code being custom developed by the client.

I assume the client will own the code you are writing for them.

Bill Leeper
  • 4,125
  • 16
  • 20
1

Try to differentiate yourselves in the eye of the client away from off-shore outsourced organizations. If you've had bad experiences with off-shore work, share that experience with the new client. Let them know that you and your outfit are completely different to the off-shore businesses. Everyone knows these off-shore developers are often not worth dealing with. Start by communicating in good English and look for ways to demonstrate your honesty. It's not hard to differentiate given the incredibly low standards out there, particularly for work done in poor countries.

Build your trust with this client gradually, and eventually he/she will come round and give you the access you need to do the job.

Pete
  • 21