How detailed is the estimate you show your customers?

Question

For custom software, when you are giving your customer an estimate, how much detail do you tend to include?

Do you:

• break it down into small tasks that can be done in a few hours and give them the full list?
• give them one big number and work towards that? And if so does that come from a more detailed estimate that you don't need to show them?
• Do you break it up into big "phases" and give them a number of hours for each phase?

This isn't for fixed bid contracts or anything, just more of a "We think this will cost you X hours at $Y an hour" kind of situation.

Answer 1

You don't want to be too detailed or too vague - both will give you problems.

Too vague and you won't have a clear idea of what's involved yourself either and that will cause problems when something unforeseen crops up.

Too detailed and you run the very real risk of information overload. You might also get someone questioning every single thing you do.

What is "just right" will depend on the client, but you need to have enough detail such that they are confident that you know what you are doing and aren't trying to rip them off. Splitting the work into phases is a good way of achieving this. Each phase should be a self contained set of work that can be delivered. (You can split the phase into smaller chunks for your development processes).

This also gives the client the chance to review progress and re-prioritise the remaining work as necessary.

Answer 2

In your scenario I think the way to go is providing estimate per Use Case or Feature. If the customer complains about the estimate for concrete Use case you can further explain what part of Use Case is the most difficult and will consume the most time / money. The customer can decide to change the Use case little bit to reduce the complexity but get the most of functionality.

This of works for projects which are already running - some releases are done and you know the product. If you start a new project you have very big amount of uncertainties and because of that you need to do it in bigger blocks - set of features / use cases, milestones etc.

The minimal unit of estimated time should be based on size of the project. If you are creating some quick web apps which are done within few weeks you can probably use estimates in hours but for bigger apps with a lot of features you should use estimates in man days, man weeks or man months. The art is to be accurate just enough. Being too accurate in initial estimates will bring you just problems when you don't fulfil them.

I recommend reading Software Estimation: Demystifying the Black Art (by Steve McConnell).

Another way is using agile approach where you build the software incrementally by adding most important features first and receiving the feedback as fast as possible. Estimates in agile are usually done more abstractly.

For reading about agile estimating I recommend Agile Estimating and Planning (by Mike Cohn).

Answer 3

You need a good enough estimate to be confident in it, and it needs to match the risk of the investment. Yeah, that's vague. What I mean is that I would not itemize my trip to the store for some milk. I do want an itemization for the $10,000 it took to fix my front porch!

First, have an organization that lets the reader drill down. Give 5 or less big picture areas, and then give clusters of details. No one can read anything well if they are inundated by 7 or more pieces of equal-seeming information.

Also - plan to divide cost of labor and cost of parts (software purchased, hardware purchased). And parts should include a listing of said parts. The customer may be able to decrease the bill there by providing things like site licenses that would dramatically decrease costs, so it's a useful bargaining point.

To answer specific questions:

• break it down into small tasks that can be done in a few hours and give them the full list?

Hours would be too small, IMO. Days/weeks minimum. If you really have a job that is only 8-20 hours long, this is the go to the store and get milk job. It costs what it costs.

• give them one big number and work towards that? And if so does that come from a more detailed estimate that you don't need to show them?

Give some sense of what features cost. A customer may want to change scope when they see the price tag, and they can't choose less stuff for less money if they don't have a break down to work with. I consider this division more important than tasks, because it's a tool for discussion. The customer wants a bunch of features, you want money. If they don't have all the money you need, then some money is better than none, but you can't define how much less to do without some break down of what the various features cost.

I've been in situations where some baseline was needed to do just about anything, or at least to do some massive collection of subfeatures. In that case, I've defined the work for the baseline, and then mentioned in each feature write up - "also requires baseline", to show the work of building the base, plus each unique feature.

• Do you break it up into big "phases" and give them a number of hours for each phase?

I've seen it done this way, but personally, I don't find that useful. If you're working a waterfall type project, you may need this breakdown internally, so you know you scheduled out the work appropriately. But my preference is always to look at the features. I may group the features into phases to give some sense of schedule at a best shot at efficiency, but I prefer not to tie myself to hours per phase if I can help it.

NOTE: As you said, this isn't a contract bid, which often has customer defined formality. This is my shot at the perfect schedule format if I get to sit down with the customer and actually have a debate about what they want to pay for. In that spirit - good feature descriptions are easily as important as numbers, since you want to make very clear what they are getting.

Answer 4

I'll usually break it into two sections:

• Overview
• Detailed

I generally make sure that the overview is a kind of executive summary (brief and understandable by all). The detailed section will then break down atomic tasks with estimates.

Even though I don't know a ton about vehicles, I wouldn't just want Fixed Car: $900 in my cost breakdown ;)

Answer 5

Rule 1: Estimates are a Game.

Consequence: Don't give an estimate until you know what it's being used for.

There's little real meaning in an estimate. Yet, everyone thinks they're very important. They change daily, yet, somehow there's management magic in having a number or a schedule that's based on utter nonsense.

An estimate might be used to make a go/no-go decision. A single big number is probably more helpful.

An estimate might be used to track ongoing progress. A sequence of releases with budget for each release is probably more helpful.

An estimate might be used to force you to ask for a lower billable rate. Doesn't matter what estimate you provide, you'll still wind up discussing your billable rate.

An estimate might be used to embarrass a manager in the future. It doesn't matter what you provide here, the project will break down in a few months and people will be moved around, and you'll be left wondering what happened.

You need to know what purpose the estimate serves.

What's funny is that a low-bid estimate might get a project started. Once you're rolling, you can raise the estimate and no one will care.

Sometimes, the estimate must be very high to make the project look big and important. Once you're rolling you find that the first few releases solve the business problem and the rest of the project gets cancelled because the later releases where a bad idea.

break it down into small tasks that can be done in a few hours and give them the full list?

Usually a bad idea. Depends on what the customer needs.

Your original guess at the small tasks must have errors, omissions and mis-estimates in it. You can't predict the future.

Tracking all of your errors will bother most customers, so it's rarely helpful to reveal this level of detail.

give them one big number and work towards that?

Usually a bad idea. Depends on what the customer needs. Sometimes they only need a big number of justify the budget vs. the cost of the problem you're going to solve.

Changing this estimate as your move through the project will bother some customers. A few are comfortable with change.

Some, however, will be bothered by the discrepancies between your original estimate and any revisions. Some can bury you with change-control paperwork to track the changes in the big number.

And if so does that come from a more detailed estimate that you don't need to show them?

Not a bad idea. It doesn't help in general, but it's not a bad idea.

Remember. It's a game. You can't predict the future. Working up from details is about the only way to "justify" the random number at the end of the process.

Do you break it up into big "phases" and give them a number of hours for each phase?

This is about the best you can do.

You can't win this game. You can't break even. You can't even get out.

Your estimates have errors and some customers will be upset when you correct those errors and revise your estimate.

The "phases" should be in order of importance. They should match user stories. They should be releasable (in principle) as incremental pieces of functionality.

What's most important is finding out what the estimate will be used for and providing something that fits the use case.

Answer 6

In my humble opinion -

[a] Detailed breakdown is just asking for the guy to shop elsewhere and try to haggle on each or every point. If you get 100,000 for building a house, do you really want 50,000 for putting in the foundation?

[b] He can get a price estimate for every step that ends in a deliverable. If there's no deliverable then it's none of his business whether you say it's done or when you say it's done. Deliverables are reality; everything else is hot air.

[c] Beware of the difference between a price and a schedule. For example, bill for one month's labor but allow two months schedule. You may be underpaid on some parts, and overpaid on others, but you can still keep the schedule which makes everyone, including you, happy.

Answer 7

Usually I provide an estimate for every item that the customer could order or not; for example, if he wants three changes in the program, my offer says "change A costs xxx, change B costs xxx, change C costs xxx". This way, he could decide that B is not worth the money and just order A and C. Going further into detail, like "analysis xxx hours, design xxx hours, implementation xxx hours, test xxx hours, documentation xxx hours" for each part of the program only leads to unproductive discussions, and frankly, I don't think the client needs that level of detail to make business decissions.