What are some ways to handle the complexity mismatch with clients?

Question

"It's really simple, I just want one screen."

"Wow, that [shiny thing] must have taken a lot of work."

I find that non-technical clients are very bad at estimating how simple or complex the functionality they are asking for is. Their estimates of how hard things are seem to revolve mainly around how much of the UI they can see, and they think of the computer as a person that can answer open ended questions.

As programmers we know this is not the case. Often complex interfaces are just a matter of doing more wiring, and it is often the 'magic button' that knows the correct answer that requires the most work (or can not actually be implemented on a computer today because it requires strong AI).

We also know that this causes problems, particularly when estimating and delivering work, or when 'small changes' require a lot of back end work, and it costs more money or takes more time to get them done.

What are some ways to gracefully handle the complexity mismatch and keep your clients happy?

Answer 1

"What are some ways to gracefully handle the complexity mismatch and keep your clients happy?"

Accurate and honest estimates of cost and time and sticking to agreed functionality and timing.

To address the rest of your question, the best way is to organise your estimates of effort in the same way that they think about the problem. When they see "shiny button = 128 man days" or "10 new screens = 0.5 man days" then they will either ask why, which gives you a chance to explain the difference between their perceived complexity and your reality, or they will not ask, in which case you have disclosed the costs and they can make a judgement about how important the relevant features are against their budget priorities.

What I have found is that the relationship with a non-technical client works fine so long as you have their trust and the only way to consistently earn and retain their trust is by delivering on quality on time on budget.

HTH and good luck.

Answer 2

I make it a point to never say "that's easy to do" to a client.

No programming is easy for the client, that's why they hire us. While we know some stuff is easy for us, saying so makes them start to think they can judge feature complexity.

Simon nailed it, lay it all out on the table. The challenge is that most geeks don't really communicate with people as well as they do with computers >.<

Answer 3

If the client doubts that something is complex (or at least requires a lot of work), a bucket of technical terms and acronyms should silence him quickly.

If the client doubts that somethings is easy, say "Oh yes, you are right, thanks for pointing that out. It will take twice as much time and cost twice as much."