How can I work with a client who gives ambiguous directions but refuses to clarify--and is just more adamant that I follow his instructions?

Question

I'm working on an assignment that my client thinks should have taken me twenty minutes... for one day and counting.

He gave me ambiguous instructions, and when I said, "What do you mean by saying that I should put one button "at" another button? Do you mean [just] before, or after, or overwriting it?" I got a more forceful and angry email insisting that I do what I was told. And I've spent at least half my time on this iteration trying to understand his instructions, and so far he has been insistent that I have not added two buttons that I should add to the link--even if I copied and pasted them from staging. He insists that they're not there.

How can I use professionalism to make sure I know what he wants, and wrap things up, preferably to his satisfaction?

Answer 1

Part of your responsibility as a consultant (I presume) is managing your client and his expectations. As a professional developer, the onus is on you to set the standard operating procedure when relating with clients. When I relate with a client I set the following minimum

1. A project scope
2. A document defining a project scope
3. Delivery timelines
4. An agreed communication route
5. Use of Change request document

The last two, I believe apply to you in this case. Your means of communication with your client as it is now, can be construed as unprofessional. I can't think of a situation that will afford a client the opportunity to bark requests at me; Be it email or in person. This is the situation that informal communication channels will breed.

A Change request document that we'll both sign off on is mandatory, before I go back to my keyboard. It appears to me, that with your client, that ship has sailed. It appears to me that you've lost political capital with your client, and they might be less inclined to adhere to further communication guidelines set forth by yourself. You've set a precedent of being unnecessarily flexible, and now, it's haunting you

In an ideal situation, there should be a Change Request Document that states exactly what the requirements are. This document will

1. Itemise what your client expects of you
2. Cause your client to think deeper and better about what exactly they want
3. Cause your client to express himself better, in a structured, concise manner
4. Cause you both to dialogue on the change request and come to an agreement before pressing forward.

Only when you've obtained a signoff on the Change Request should you proceed.

Try this article on for your next engagement.

Look at a sample change request document

Answer 2

I agree with the others about setting up the scope of the project, communication channels, the use of change requests, management of expectations, etc.

But your problem is that "the cat is already out of the bag". It is probably too late to set-up proper change request ground rules at this point.

The best thing you can do now is to humanize the communication and try to re-establish some rapport with the client. It seems like you are using email to communicate. In situations like this where anger becomes an issue having a conversation on the phone or in person might be more helpful. Email has a way of making people more rude and dismissive and this is particularly acute if you're dealing with a stubborn person who can't imagine that what he wrote could have an ambiguous interpretation.

If you talk with him, preferably with a drawing in hand, you are going to be more able to make him appreciate the nuances of what you're saying, and he will be able to see that you're not trying to give him a hard time.

Answer 3

You need to find better way to communicate different types of development requests. Simple logic could be addressed in a short emailed paragraph, but design and layout requests need diagrams.

If time is an issue, you could setup a Skype meeting and use some type of drawing app to make sure you understand what the client wants. Of course this can be handled by sending files back and forth, but that is not as efficient.

Also, you need to arrange some sort of minimum billing for ad hoc change requests. There is no such thing as a 20 minute change. Reviewing the request, making changes, testing, putting into source control, documentation, approval and billing will take much more time. I'd suggest a 2 hr minimum. Anything that can be done in less time is not important.

Answer 4

I think the best way to deal with this is to write up what you think he meant, send it to him, and let him know that if it's wrong he has to get back to you and say what should be different.

If he doesn't get back to you, give him what your write-up said, and if it doesn't match his expectations, it's his fault, not yours.

If this doesn't fix it, and you can't bill him for extra time spent (or he rants about it), you may have to dump him as a client.