How to explain to a non-technical person why the task will take much longer than they think? [closed]

Question

Almost every developer has to answer questions from business side like:
Why is going to take 2 days to add this simple contact form?

When a developer estimates this task, they may divide it into steps:

• make some changes to the Database
• optimize DB changes for speed
• add front end HTML
• write server side code
• add validation
• add client side javascript
• use unit tests
• make sure SEO set-up is working
• implement email confirmation
• refactor and optimize the code for speed
• ...

These maybe hard to explain to a non-technical person, who basically sees the whole task as just putting together some HTML and creating a table to store the data. To them it could be 2 hours MAX.

So is there a better way to explain why the estimate is high to a non-developer?

Answer 1

You've just done it in your question.

Split the task into the individual steps and give estimates for each one. This will show that you've considered all the options and (hopefully) covered all eventualities.

If the timescales are too great you can then discuss what parts (e.g. e-mail confirmation) aren't needed in this case with concrete data rather than just trying to cram a quart into a pint pot.

Do this often enough and you'll hopefully teach them that there's usually more to a development than meet the eye at first glance.

Answer 2

Listing out tasks is just about perfect, but keep in mind that tasks that make perfect sense to an engineer make very little sense to a non-technical person. For example, in the list above, I know that "optimize DB changes for speed" may be one or several time consuming tasks that include profiling the code, running it an looking for slow points, reviewing it with experts, or throwing it through a set of pre-defined tests specific to the product. And then you probably have several hours if not days of pounding your head on your desk while you try to find a way to fix the areas that are too slow.

But you might have lost your project management on the word "DB" if not the word "optimize".

I generally express this stuff to project management in terms of BIG steps with words that describe risk in terms of the business. Taking your list, I'd boil it down this way if I was talking to my project management:

1. First, there's two parts to this thing - the web page that the user sees, and server that does the heavy lifting. Both parts need to be there for this feature to work.
2. The first part will be to craft a web page that makes sense to the user (add front end HTML, add client side javascript). The key here is that the web page has to look like it's part of this product, it has to operate in all the browsers we support and is has to be slick. This what the user sees, so if it looks bad, the user will will think our product is bad. Developing this and then testing it will take X days.
3. Next, there needs to be stuff underneath the web page doing the work. In this case that means insert description of feature here (maps to - make some changes to Database, write server side code, implement email confirmation, add validation, use unit tests). I can't just throw this together. If the code is developed and then tested, we risk causing damage to the data of ALL the users. That means that a simple new thing could damage the product's reputation across the board - even for users who aren't using this particular feature. Our development practices cover this - we do plenty of testing to make sure that won't happen - but that means I've got to plan in the time to test it properly. That will take me Y days.
4. Speed is a big deal in our product. If stuff doesn't happen fast, users will think that the product is no good. So after I write all this stuff, I need to go through the work and make sure that it's up to par in terms of performance. This is a big deal in web stuff - if people see a site become slow, they will quickly turn to a different product to meet the same need, because it's really hard to see the difference between slow and broken. That kind of work typically takes Z days (optimize DB changes for speed, refactor and optimize the code for speed)

I would avoid any estimate that is less than half a day. They are going to have to trust, at some level, that you know what you are talking about. And if they really think that it'll only be 2 hours, then invite them to sit with you for 2 hours while you walk them through exactly what 2 hours looks like in the life of a SW developer - then do a coding 101 class for about 2 hours, to show exactly what all has to be considered to even begin to solve the problem.

Most important is the following things:

• Buy talking most about customer perception and product usage, you're coming part way to speaking their language - the language of $$ - the point is, if the code is hacked together in a shoddy way, you will eventually loose business - if not on this feature, then on some subsequent feature when poor development practices have rendered it impossible to extend the code.
• Set out a sequence of events. The next non-technical question will be "if we got more developers than you, would this happen faster? If so, if it will take 40 hours to make this, can 40 people make it happen this afternoon?" The answer, of course, is "NO! ARE YOU OUT OF YOUR MIND??". But that's not the best one. The best one is that there's a logical sequence of steps here. Thing B can't be done until thing A is in place (if you haven't written any code, you can't really optimize or test it...). Thing A and A' could be done together though, so if they could spare that smart guy over there you could shave the time down from a week to 4 days, and if they can guarantee the awesome test support, then you could probably get to 3 days. There's usually some space for wheeling and dealing on that - but make sure you bargain for stuff that will actually help.
• Focus on risk and be prepared to be told that some risks are worth it at this time. That's what the business guys get paid the big bucks for - figuring out what risks are worth taking. For example, if speed to market out weighs poor performance because your company has enough cash in hand to stage a ridiculous number of servers in the short term, then you may get told to skip all that stuff in step 4 (the code/database optimization). That's their right - it's just your job to explain the risks inherent in that decision.
• However, if you don't trust these folks, do get a confirmation in writing - it doesn't have to be confrontational, just a quick email saying "here's what I think we discussed, here's what I'm not doing, here's the risk. I'm going to do it now, so let me know if you disagree... if I don't hear from, you I'll assume this is the right way to proceed". Given that product management can be the center for short term memory loss, this is pretty helpful for everyone.

Answer 3

There's a saying, "You can't fit ten pounds of (crap) in a five-pound bag." Your job is to show that the task is ten pounds and they're asking to have it in a five pound timeframe.

The only thing you're missing is the time estimates. Put a time estimate on each task, and show how all these things add up together to the estimate you provide. Don't allow any estimate to be larger than 4 hours. If you have any task where you say "a day" or "10 hours", then break it down into smaller subtasks.

2h make some changes to Database
2h add front end HTML
   write server side code
     4h input validation
     4h database inserts
2h add validation
2h add client side javascript
   use unit tests
     2h client-side tests
     3h server-side tests
2h make sure SEO is setup is working
2h implement email confirmation
2h optimize DB changes for speed
2h refactor and optimize the code for speed

Now you've got an itemized bill of the costs. All told, that totals up to 27 hours of work.

You can now show this to your customer and say "These are the things that must be done, with the cost of each." Use the word "cost", because time IS a cost, and management understands costs. Explain that you could possibly drop the two optimization tasks on the end, but they'll have a negative effect down the road, and they're only 15% of the total estimate.

Also make sure that you explain what your hours/day is, realistically. For example, if you're called on to do tech support, or maintain databases, or whatever, figure that into your estimate. Don't say "Well, I can do 7.5 hours a day of good coding" because you probably can't. It's probably more like 5 or 6.

Then, most importantly, track your progress. Say that you can do 5 hours per day of coding. Then you should be able to knock off the first two tasks (in my example) on Monday, finish the third and start the fourth on Tuesday, and so on. Make a checklist that shows this, so that you can show them on Wednesday when they come by and say "How's it going are you still going to be done by the end of Friday?"

See my slides for my talk Preventing Crisis: Project Estimation and Tracking That Works that I gave at OSCON a few years ago. Look at slide 21, "Planning the week". There's also a sample velocity chart.

Answer 4

Ask them:

How would you do it? Which modules would you change? How many lines of code? What are the security implications? Any changes to the database schema? If you make any change to the DB, how many files are affected? How long did it take to add the last form? What is the average (arithmetic mean) for adding a form? What was the longest? I'll estimate it will take one minute less than the longest. If you don't know how long it took to add the last N forms, then this estimate is only guaranteed to be accurate to one order of magnitude.

Answer 5

I could tell you to explain to them that their software is like a 100 ton machine with 10,000 different parts, much of it connected in complicated ways. Fitting in a 1 inch piece into this machine takes some engineering, so that it won't break the machine, BUT the better answer is:

If you had better code architecture, would it makes tasks like this easy? And the answer is that most software teams are not good architects (because they simply haven't amassed tons of generic, architectual templates or they aren't masters of the problem domain suffiently to anticipate every problem) and they're not always good engineers, so they don't feel confident in giving estimates or making promises.

Just like it took the 20th century to amass good architecture and the engineering for building large buildings, the tools for software engineering just haven't arrived to the mainstream. They are being developed: it takes a new mindset. See Zen Code at wiki.hackerspaces.org/Hacking_with_the_Tao.