How do you help a non-technical client or boss understand why something takes so long?

Question

I want to know specifically how you deal with explaining a timeline to a non-technical boss or client, and why it takes so long to do something they feel should take a lot less longer. I hear "Why can't you just..." a lot, and I have trouble without getting into the deep technical details explaining why something might take a few days or a week when on the surface it looks like it should only take a few hours.

Answer 1

Ask him why it should take less time and what he is basing that on.

Maybe that will make them realize that they are basing their opinion on something they don't understand, or at least give you an idea of how he is judging what is going on. From that you can work on building an explanation. Break up what you are doing into parts so that he and everyone (including you) can see whats going on and give people an idea of what has to be completed. Pinning a date down might be hard, but at least you will know the order of things. Over time everyone will gain an understanding of how long things take and start applying date more practically.

Answer 2

Sometimes it helps to actually explain why you can't do something using technical terms. If they know what you're talking about, they'll get off your back. If they don't know what you're talking about, they'll also get off your back.

Answer 3

Use analogies to describe the underlying tasks that take time. The more you practice the "explain technical things to grandma in a language she understands" the easier it will get.

Answer 4

Maybe if you do go into deep technical details they'll stop asking so much? ;)

Break the individual components of the task into a list, tell them the list then perhaps give a simple explanation of each of the individual parts, rather than attempting to explain the whole thing together.

Answer 5

There is a relevant discussion between Spolsky and Atwood in Podcast 16 at [48:33]. However, it's more about discussion why estimates can be so bad!

Answer 6

Perhaps you can talk in terms that they do understand. Talk in terms of risk. How when you are dealing with the unknown it increases the risk that what seems easy may not even be possible. The more you do not know the exact details of how something works, the greater the risk that a work around needs to be done.

This is a hard thing to do and takes time and effort to get good at it. Metaphor helps people to understand computers.

Be honest. If delays occured because of the lack of knowledge about something, explain that. If delays occured because something was not written correctly in another library, try not to blame, but explain that what seemed obvious was not possible due to some programing oversight earlier.

To communicate to someone it really is a must to understand them quite well. Spend a bit of time asking them what they know about computers when possible so you can pick up and serious misunderstandings that may be holding you back.

It is a lot hard to communicate to someone you don't like, so it is quite good to be able to find something in other people that interest you, to help with this.

At the end of the day, you are the expert. Stick to your guns and don't back down to pressure. "It takes what it takes." is a great quote a previous project manager used to defend me as a developer when things took longer than we planned for or expected.

Answer 7

Sometimes the best thing is to write down all of the things that you have to do and see what can be translated to user-features or things that the product owners understand. A simple example I recently had to deal with (changed slightly, but not significantly) -- "Can we add a phone# to the registration page in the installer" -- this seems simple -- here are the steps:

1. Update UI (by the way, there really isn't room -- do we make window bigger, resize others)

2. Is it required? if so, add logic to check for that

3. Update web service to add method that collects registration (and deploy)

4. Write method to put phone# in SalesForce account

5. Call the new web service from registration page

6. Need translations for "Phone Number" in all languages we support

7. Test -- means more than one configuration, and languages

8. Update installer help video with new screen (optional)

9. Update web page that has help for installer with new screen shot

I think even non-techies would understand most of this. Sometimes, they decide not to do some of the steps, which is ok. Mainly they need to understand how skipping something will affect the user.

Answer 8

One way to deal with this is to build a good reputation of delivering things on time. If you consistently make accurate estimates, then people will learn to respect your professional judgment and won't second-guess you. Of course this does not apply to all people - some non-technical people do not have respect for techies and never will.

Other important communication tools are project documentation - business analysis, systems analysis, project timelines, etc. Even if your audience does not understand all the technical details of what you are doing, if you can break it down into a lot of small parts then they will intuitively have a better understanding of the scope of the task.

Answer 9

My initial take on this would be to try to explain the idea that software has to handle ALL cases and that this means a lot of code will be written to handle invalid input that can happen from users, databases, or wherever the source of the data is.

If you have to give an example to illustrate this, just take something as simple as writing a temperature converter, e.g. convert x from Celsius to Farenheit, and noting that there are the cases of entering nothing, some letters, special characters, and other oddities that make the program much more than just the formula that one may think that the program is just.

Answer 10

Tell him if you develop it faster then:

• that the cost will be larger, because many more fixes and patches need created and distributed
• that the cost will be larger because many more support people are needed
• that the image of the company will be bad if they ship bad software

Answer 11

I find that usually when a task takes longer than what someone would expect, there are either unresolved issues with "how" it should be finished, or there are several smaller sub-tasks that comprise the given task. Either way, there is usually a communication issue.

If there is an issue with "how" it should be finished (new language/technology) then that should be communicated to the client/boss.

If the task is comprised of many sub-tasks, then outlining the sub-tasks and giving a time break down for each usually helps with explaining the total time needed to complete the given task. It also helps the non-technical understand the scope of the request. Even if the sub-tasks are technical, or can only be explained in technical detail, having a list of thirty sub-tasks for the "small" change request that the client/boss made helps make it clear that the request itself was larger in scope than what he/she/they understood it to be.

Answer 12

I've found that one of the most common reasons why this dialog happens is that there is some deep-seated distrust in the relationship, whether that's between you and your non-technical boss or between your company and your client. Depending on how comfortable you are in either case, it might be most productive to approach the issue directly. You need to find a way to develop trust in this working relationship because ultimately there is no way you'll be able to explain the problem in sufficient detail to allay their suspicions.

Ask yourself: does the other party have a reason to distrust you/your company? If so, you might need to deal with that reason or simply learn from it and make sure it doesn't happen again.

Of course that's not to say you don't owe them a boiled-down, non-technical explanation. They don't want technical details, so you'll have to explain the underlying reasons why change is difficult to do well. Sure, it may just be a checkbox on this form, but there's a lot of back-end work to save the check and put them into these reports, etc.

The chief concern here is do not under any circumstances fabricate or lie about the reasons something is going to take as long as it does. This will back-fire if you do it enough times and you'll damage that trust relationship that is fundamental to the whole problem.

When it comes to creating your estimate for the work: it might help if you itemize the task. Maybe you're doing this already, but I like to say things like "database updates: 2 hours, unit tests: 1 hour, source code: 2 hours, quality software: priceless". (Okay I would punch myself if I said the last bit...)

Also, good luck: this isn't something that's easy. :)

Answer 13

Take the process and break it down into a few steps. Then pick the simplest of those steps and break that down into a few steps. Keep going until you've got a single step that takes less than an hour, then show him a tree chart with a simple depiction of how many steps of that magnitude would be involved if you broke the whole task down all the way. You don't have to label the whole thing, just the first breakdown and the branch that you followed all the way to the bottom.

Answer 14

Don't be defensive and don't take it personal. Remain calm, explain in layman terms, try an analogy. Get yourself into the same mindset as Peter in Office Space when he first meets with the Bobs.

If that doesn't work you can try sharp, dry, cutting sarcasm :)

Answer 15

Tell him "let's write down my estimate, your (lower) estimate, do it, and see which one is closer."