Prices vs. Estimates (And How to Educate Your Clients on the Difference)

Tell me if this sounds familiar.

A client comes to you with a custom software development project.  They ask you to put together a proposal and an estimate.  

You write the proposal.  You estimate how many hours it should take.  Then you double the estimate. (You've done this before and you know your eternal optimism is working against you.)  You estimate that the project will cost about $15,000.

You explain to the client that this is just an estimate.  You explain that you've built in time for unforeseen problems, but this is just an estimate.  You will keep the client up to date with regular progress reports so they can keep an eye on the project budget, but THIS IS JUST AN ESTIMATE.

As the project reaches the home stretch–and all those little requirements that the client was sure they had told you about in the beginning start rearing their ugly little heads–it becomes obvious to everyone that there is no way the project will come in at or under $15,000.

The project eventually comes to a close.  The client is thrilled with the software but bitter about the final cost of $18,000.

"You told us it would only cost $15,000," says the client.  "That's all we had budgeted for the project."

"I believe I mentioned that $15,000 was just an estimate," you reply.

The client snorts, "Well, not a very good one apparently."

Having reached the point where you just want to be done and move on, you agree to knock $1,000 off the final price.  The client grudgingly pays the $17,000 as you hear them mutter under their breath one last time, "It'll only be $15,000, he says..."

The Disconnect Between Client and Developer

A price is a set amount that one pays for a product or service.

An estimate is a guess as to what the final cost will be for a product or service.

The fundamental problem is that when you give a client a dollar amount, they will think of it as a price regardless of what you actually call it.  And if when your project exceeds the estimate, they will feel cheated.

The Ideal Approach

I believe the best way to avoid this problem is to ditch hourly billing entirely by switching to value-based pricing.  But I've been on that particular journey for several years now, and I know firsthand that it is not easy to transition from hourly billing and/or fixed cost (time and materials) pricing to value pricing.  It's especially difficult with existing clients.  I'm still not there yet.

The Next Best Thing

Short of switching to value-based pricing, the best way to communicate the difference between a price and an estimate is to let your client choose which they would rather: a price or an estimate.  

What does this look like in practice?  

Let's go back to the original scenario.  To make the math easier, let's assume your current hourly rate is $100 per hour.  Based on your original estimate of $15,000, your best guess was that it would take 150 hours to complete the project.  Here is how I would offer to complete the project using my Hourly-Fixed-Hybrid approach.  Here is an example from a fictional project proposal:

Option A: Hourly Billing

We charge you $100 per hour for our time working on the project.

This is the highest risk option for you and the lowest risk option for us.  If it takes significantly more time than we anticipate, this option would be the most expensive for you.  Alternatively, if it takes less time than we anticipate, this would be the least expensive option.

Option B: All-inclusive Fixed Price

You pay a fixed cost of $23,000.

This is the highest risk option for us and the lowest risk option for you.  If it takes significantly more time than we anticipate, this would be your least expensive option.  Alternatively, if it takes less time than we anticipate, this would be the most expensive option.

Option C: Hybrid

You pay $15,000 up-front for up to 187.5 hours of billable time on the project.  You will be responsible for the full cost of these initial hours.  Any time we spend beyond the initial allotment of hours will be billed at a rate of $100 per hour.

This option allows us to share the risk.  Our fixed price will be a 20% discount on our hourly rate if you use exactly 187.5 hours.  Your up-front cost is lower than Option B, and if the project takes longer than we anticipate, this will be less expensive than Option A.

Why This Works

The Hourly-Fixed-Hybrid approach forces the client to recognize the uncertainty involved in pricing a custom software project.  It is also very transparent about how risk drives the three different models.

Ultimately, this approach is about forcing the client to come to (literal) terms with the difference between an estimate and a price.

Image by Nattanan Kanchanaprat from Pixabay