How Much Information is Enough Information?

Question

I've dealt with a few clients over the years who have wanted, understandably, to stick with the project at every turn. For the most part I haven't had any issues with that, but when I start hitting a bug, I often find it difficult to explain what's going on to them. I could go into detail and write out paragraph upon paragraph of everything I know as a developer and everything that's ever happened in my life that might apply here, but that's just a waste of my time and theirs. Generally I explain at a super top-level, knowing that if they don't really understand it but think they do, it'll all be resolved in a day or two and it won't have made any difference.

That works in most cases, but sometimes I find an email in my inbox from them saying something along the lines of:

So we know you've been having some trouble with this one problem so we spoke with a developer friend of ours and told him you've been facing this, and he suggested you try this.

Except the explanation I gave them was, while not untrue, a fairly dumbed-down form of what was actually a legitimate problem worthy of actual thought.

How much time should be spent explaining problems to clients, versus actually solving the problems?

Answer 1

Now, how much information is too much?! Ideally, clients should be aware of all good things happening in the project and be unaware of all bad things like bugs or bottlenecks.

You can achieve this with some clients, but you cannot with others. I go into the same situation as yourself, and the more I talk about the bugs and involve the client into bug details, the more they don't rate me as an expert. Let's say, I am rated 4 out of 5.

So, if you can, avoid details about bugs or other bad things. If you need more time, just tell them why, and use neutral words like "optimization" or "refactoring" or "speed up the things".

There are however, rare cases when the client is a developer as well. And in such cases, you can talk to him about the issues because that person will understand you, and that person may be able to help as well by googling and sending you good links. You do need help from a programmer when solving problems, but you do not need help from non-programmer.

Answer 2

Don't try to explain anymore than the customer is fully able to comprehend, otherwise the discussion will never end.

At the end of the day, what the customer should care about is impact:

• how long will this delay the project
• what are the trade-offs for the possible solutions
• what are the alternative solutions if the issue can't be fixed

In your discussions with the customer, you should spend more time explaining the impacts and less about the specific details of the problem.

Answer 3

Don't engage non technical clients in technical subjects, unless you're being paid to train on technical subjects.

Invariably you will get the non-technical client with a little knowledge and a lot of ego. THIS client will wear you down trying to show how much he or she knows. This client is a technical wanna-be, but you can never say that because the client's helping to get your bills paid. He/she will talk, and talk, and talk in order to seek your acknowledgement (i.e. to feel smarter) --- and you'll waste a LOT of time.

It's okay to explain that such-and-such isn't working correctly. But leave out technical terms as much as possible so that the non-technical person doesn't latch on to jargon and end up suggesting that you allow the client's son/daughter, the "HTML expert because he took a class in high school", become an unwanted contributor to your work product.