Underestimate and therefore undercharge your clients-- what would you do?

Question

I know this is quite a subjective question ( and is likely to be closed), but I think it would be useful if I ( and the rest of SO!) know how other developers are handling this situation, so I make it a community wiki and hope that it won't be closed.

As a software consultant, one must be able to accurately estimate the amount of time needed for a software project, because the clients demand it anyway. But we all know how complex software development is, and we all know the tendency of software developers to underestimate the amount of effort needed, and overestimate their abilities to deliver the solution just-in-time.

So, if you were a software consultant who is billing your client on complete project basis( but you have to come up with an estimate and then bill based on that), what would you do, if you found that the initial quote you delivered were way too optimistic, and that you needed twice the amount of time (or more) you estimated in order to deliver the solution?

Answer 1

Eat it. It's the only thing you can do. You can't expect your client to pay for your mistake.

Answer 2

next time, use this formula to calculate the project duration:

[Amount of time you expect]*2

Answer 3

Talk to your client. There are numerous variables in estimating and if there were honest reasons for the misculation then they're not going to want you to do a slapdash job just to not lose too much money.

@Jay Riggs is probably right though, especially if you won the contract against other higher bidders, you will probably have to eat it.

Answer 4

Drink a lot of coffee, and learn from your mistakes.

Answer 5

Divide your project into small sub-projects, which can be managed better. For example, do the specifications for the software on an hourly basis, and make a fix-price quote for the implementation phase, with some overhead added for risks, you haven't anticipated. If the impelementation phase is long, try to agree to deliver it (and make separate offers) for each phase.

Answer 6

Take your best guess, double it, and raise it one unit of measure. If you think it will take 2 weeks, assume that actually means 4 months.

Answer 7

There is are several difficulties when estimating work, but a good general rule of thumb (as noted) is to double any estimate you make, and to make sure that you split the job down as much as possible and compose your estimate by adding all the sub-parts.

If you mis-estimate, then you're probably going to have absorb the extra cost yourself. However - If you do a good job, and the customer wants you back, then you can make up some of the lost time by adding it on to future projects.

Answer 8

If you provided a quote for a given deliverable and you're est. was low (sometimes people go in low to get the job and then pay for it), then you have to suck it up...if the client changes the scope you can charge more. providing an est. and beginning work is basically committing to a contract that if you don't deliver on the client can get their $ back as well as look for damages...

Answer 9

If you are billing based upon a completed project basis, there really isn't much you can do if you underestimate how long the project will take. You might try discussing it with the client to see if they would be willing to renegotiate the cost, but they are under no obligation to actually pay you more and it might in fact hurt your future chances for business if they talk with others about it.

Your best bet for the future is to work on improving your project estimation skills that you use when estimating how long the project will take. While it applies a bit more to larger projects with teams, Software Estimation: Demystifying the Black Art might be a book worth picking up.

Answer 10

Solutions I have used so far:

• taken it on me and learned from it
• talked to the client, explained the difficulties I had and asked, if he agrees to pay my additional effort
• waited until the client had additional wishes and made higher estimates for those to partly compensate my loss (especially in the case where the additional effort was partly cause by the client)

What did I learn from it?

I don't do whole project estimates anymore. I do iterative estimates. For example by feature. I only estimate the cost of the second feature after completing the first. This also ensures that you will be able to adapt to changes in the client wish after he has seen the first feature working. You say 'spec freeze'? Oh well, the clients reality looks different.

Answer 11

What I learned after some painful situations is that underestimating seemed to come from a different understanding of what the final product would be between my company and our client. To mitigate this we implemented a design phase that we charged for to get the project to the point where we had fairly decent high level requirements fleshed out and storyboards created. From this we moved on to estimate the actual implementation.

We found some clients weren't willing to try and flesh out more fully what they wanted and let some projects pass on this basis. We also had projects where after fleshing things out further, allowing for a better common understanding of what was to be built, the client opted out deciding it would cost too much, but they paid us for our design efforts.

We still run into issues where work is underestimated but it is much less severe than in the past. Also we've avoided projects that had such poor definition that they would definitely have been problematic down the line. In short, the better you and the client understand what you are going to build the better chance a fixed price will be fair.

The best solution is a hybrid approach where the client participates in some manner for cost overruns so they also have an incentive in minimizing them. This is often not possible, especially today.