Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Possible Duplicate:
Explaining technical things to non-technical people

Working with stakeholders who don't know the first thing about technology can be interesting. On one hand, I sometimes get requests like "I need you fix this misspelled word- that should take about a month, right?"

On the other hand, I sometimes get requests that would require fundamental breakthroughs in several fields of computer science. The problem is that to explain why a problem is impossible (or at least, an order of magnitude larger than they think) often requires explaining a whole pile of background knowledge first, which in turn requires its own CS degree to make much sense.

For example, it seems simple to some users to just add a voice interface to an application. That shouldn't take more than a week, tops! But explaining the state of the current voice-recognition field and the problems associated with natural-language processing usually goes right over their heads.

Anyway, I'm curious if you have any good approaches for explaining the difficulty of certain tasks to certain people with minimal technical background. Do you try to explain the technical details? Use analogies? Just tell them that it can't be done?

share|improve this question

marked as duplicate by Josh K, Wizard79, Pierre 303, Walter, Tech Jerk Oct 18 '10 at 9:00

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

While I would say this is a duplicate, it has some unique points. I would explain absurd requests (voice controls) simply by asking for other examples of this request that have already been done. Either they will have an example which doesn't fit what they are asking for (and thus explainable) or they won't (and thus you can point out that it hasn't been done because it can't be done). – Josh K Oct 17 '10 at 1:37
just because it hasnt been done, doesnt mean it cant be done. Before we sent someone to the moon, it couldnt be done. – Muad'Dib Oct 17 '10 at 1:51
Sending someone to the moon definitely didn't take a week :) – aufather Oct 17 '10 at 5:21

Sometimes I find myself in meetings with customers who keep saying "...and could you ... " , or " ... and could it also ... " over and over. At some point I smile sweetly and say "I'm a consultant. Whenever you ask me if something can be done, I am always going to say yes. But for a lot of these, I also have to add: you did bring your chequebook, right?" They laugh but they also get the point. It's not just about what can be done, it's about what it will cost, and if it's worth it for them.

So to take your example, voice recognition is actually three problems - one is the actual noticing that people said something and recognizing the sounds, second is having your UI and business logic sufficiently pulled apart that you can build a verbal ui in place of a visual one, and third is natural language processing. NLP is super hard, but did the client say and none of that File, Save nonsense with pauses between menu commands, we want the system to understand "ok please save that for me in case I lose my work?" I bet they didn't. When they ask for the moon, be sure to find out if they would be ok with a reflecting pond that shows them the image of the moon every night. After a while it becomes second nature to rephrase requests into things that are humanly possible, and to ballpark estimates (whether you share them aloud or not) so that you know how much they are asking for.

Clients ask me to re-invent Excel, Project, and Crystal Reports all the time. For those folks I say "A copy of Excel only costs a few hundred dollars, but it represents hundreds of developer-years of effort. You aren't going to fund that and I wouldn't want to do it even if you did." You may want to keep a sentence like that in your pocket for the people who reject the reflecting pond and demand the actual moon.

share|improve this answer
So much this. Managing up is important. – Lightness Races in Orbit Dec 26 '15 at 17:06

Triple Constraints.

Mostly know as "Do you want it good, fast or cheap".

I also recommend PM Simplicity e-book for all projects. There are a chapter for stakeholder analysis.

For explain how certain things are hard to made, I prefer analogies.

I have been used one that I call "Cerberus challenge".

There are a 3-head monster named Cerberus that you´ll face when you start a project. Heads are: Bad, Expensive and Slow. It is impossible to kill the monster, but you can cut one head, run and try to escape from hell. :O)

share|improve this answer

In this case I wouldn't get bogged down with the technical details. If you think that the requested solution isn't the correct solution explain why while pointing out the extra hours and cost implications, because that's something that clients can understand.

Always give an applicable alternative.

If you feel that it is not the right solution because the current software is too limited, you need say that quite simply. Again, you can always expand on something, but there are timing and cost implications.

share|improve this answer

Providing a ball park cost and delay in providing other requested features is the quickest and easiest to make the client reconsider their request.

It is important to tell your clients not to make assumptions how long a request may or may not take; that's your job.

It is good practice to encourage lines of communications with your client. The vast majority of requests from clients are a good idea and they should be praise for them. Then just be honest and say that will take at least X hours to implement. It should be rare that you have to explain why.

share|improve this answer

Technologies that require the frontiers of science should be easy to explain: no company has succeeded in doing the same. This should tell something about the difficulty of the subject.

Technologies that a few companies have started offering, means that they are within human's reach. In this case, it might be possible to estimate the cost needed to acquire / license that technology, and if licensing is not possible, then it can be understood as a business barrier, not entirely a technological barrier.

Technologies that can be added to the product today, but would be unable to meet the customer's expectation because of its imperfection. In this case, one has to build the product and integration first, and then demonstrate it, in order to convince anyone that it is doable, but is not useful.

To explain why technologies that sounds cool but fails commercially, it is useful to study the History of Science, especially on technology adoption. Sometimes the explanation is simply that their primetime has not come yet.

To explain why it might be a bad idea to automate a manually-performed task or to eliminate human involvement (approval, confirmation) in a certain step, use a scenario-based story or ask the customer to join a simple role-play game. These are good ways to explain the potential risks.

share|improve this answer

If your client has trouble understanding why a given small task may take a long time and be quite expensive, then perhaps it is time for an analogy:

  • On the moon the astronauts put a mirror to reflect laser beams to Earth. What is the cost of adjusting that mirror slightly?
  • I have a very complex Lego construction. What is the cost of changing that brick in the middle to a yellow one?

Can't take long, can it?

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.