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

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( i.e., 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?

You should check Out Joel Spolsky's article on Evidenced Based Scheduling. It is a personal favourite of mine. Any software development shop that needs to do estimating should be training themselves in how to do better estimation.

Another key thing, I think, is controlling the scope of what you promise. If a user requests a change, estimate that change and immediately quote them for the difference between what you previously agreed to and what you are now agreeing to.

I agree with Oleg about eating the costs of your own mistakes, but hold a clear retrospective to understand what your mistakes were, why you made them, and how you will avoid repeating it.

Creating an accurate quote and being able to fit into time and money estimated is one of the most important things in the software development services. If the underestimation occured once, eat the costs and learn your lesson. It will make you stronger. If it repeatedly happens, then you are doing something wrong, and you won't last on the market.

It is reasonable to try to negotiate with the client only if the underestimation happened because of some new information, like some new functional or non-functional requirements.

When you make a quote or proposal ALWAYS leave some room for maneuvering. If you think you will use 100 hours, quote for 120 hours (20% is just an example, of course).

This margin is always needed because:

1. one tends to underestimate complexity
2. the customer always makes some small additional requirements
3. unexpected technical or domain problems may arouse

This security margin depends on your own expertise regarding:

1. the language / tools / software and hardware platforms to use
2. the application domain

If you have made a lot of similar projects you can bid very tight (low security margin). When you are new to the technologies to use AND the domain area, better charge by the hour or just let the business pass.

Once on the project, keep control of invested hours. When the customer asks for small changes, and you are under your time budget, just give it to them. They will always remember it and will be happy to do business with you again.

If the changes or new requirements are big, the better way is to finish the current project as initially contracted, and make a proposal for a second stage of the project. Accepting important changes in the middle of a project is a sure-fire way to end with trouble both for you and your customer.

I know of a company (its a US based company who has setup its shop in my city) - won't name it - which realised that its estimation was off by $200K for a $1.2M project.
This was after it had started work on the project and had hit 1 milestone.

They simply asked the client to cough up the money (which they didn't) or take a reduced feature set project for which they were paying (which they ended up doing). Needless to say, this definitely soured the relationship. I would have borne the cost myself.

But the simple answer to this is:
Depends on how much leverage you have! Do you really, really need their work? Or are you better off not actually working and taking the hit. In the example above, the company felt that it had too much work (which it doesn't now - BTW) - and dissed the client. In other cases, you may be really hard strung for money and have no choice.

Again, it also depends on what stage the project is in.

If I am a customer, I would feel bloody cheated if after the work started (or contract was signed), the developer comes and tells me: "Oops! We made a mistake. It will cost you twice as much now!"

I ran my own software consulting company for four years and we have had this issue a couple of times - but both times it wasn't major (about 20% extra effort) and we were able to bear the expenses instead of going to the drawing board again with the client.

However, we learnt later to spend a lot of time documenting the requirements, etc. because most of the times the feature creep, etc. resulted in the client thinking of something else and you having an idea of implementing it in another way. So having a strong initial spec written by you will only reduce heartburn later on.

Make sure you quote prices with hours and quote an hourly price for going over the estimated amount of time.

for example:

This project has been budgeted at 100 hours, including 8 meeting hours: cost $7500.- For extra time needed the standard hourly rate of $85,- will apply.

I found that clients like it more if the initial price is a bit higher but I stay within the set time than the other way around.

If you really need twice the amount of time, you will have to talk to them. If they do not pay you for the hours you work, you can't do the project.