Why estimates don’t work

Posted on July 15, 2019

“When potential customers contact us, they probably want to know two things: How
much does it cost to implement the application? And, How long will it take?”,
says the developer Petri Kainulainen on his website. And he adds: “The honest
answer to these is ‘we have no idea’. Needless to say, if we give them this answer,
chances are they will not hire our services. That is why we use work estimates to
provide answers to our customers”.

“Our clients need estimates”

There are many variations on this, but they are generally reduced to: we need
customer and customers need estimates, thus we do them. Some examples of
this idea, as given by programmer Woody Zuill in an article on his website, are:

● No customer would accept to hire us to program software for them unless we
provide them with an “estimate”.
● Business reality is that we must give estimates to our customers so we can
work.
● We should provide good estimates because our competitors are doing the
same.
● The customer wants to know if we can do the job for a price he/she can pay.
● The customer needs to know if he/she can make a profit contingent on the
amount that the software will cost, thus an estimate is needed.

However, as raised by Petri in his article, the problem of giving an estimate is that
many times we are not telling the truth.

Estimates are assumptions

This might come as a surprise to them, but our estimates are only that: guesses. It is
pretty easy to figure out if a specific task is small, medium, or large. However, it is
quite hard to figure out how much work is really required to finish a single task.

One reason for this is that, estimates are often based on insufficient information.
The problem is that when we give these references, we use examples of users’
interfaces or a list of user stories; consequently there is no way to know how long it
will take us to program this software in particular.

Why? Because we can’t estimate what we don’t know. For example, we don’t know:

1. How we should validate the data?
2. What are the business rules of the application?
3. How the authorization should be implemented?

There are a lot of questions without answers, and yet we should be able to give an
exact estimate, which is kind of utopic, according to Petri.

Estimates don’t encourage us to maximize the added value

Estimates are used for two different purposes:

● For the customer to have an idea of how long it it will take to implement the
application and how much it will cost.
● For the software development company to ensure that the project is
profitable.

Woody shares some considerations to bear in mind if, anyhow, there is the need of
giving estimates:

● Are you willing to give a free estimate / price?
● Who pays for the estimates of jobs that are not hired afterwards?
● How much more do you need to “fill” the work for “strangers”?
● Why should your customer pay for that?
● Will you give a range? For example: “It won’t cost you less than this and not
more than that”. Can you guarantee that?

● If the software is then more expensive than it was estimated, are you willing to
bear the loss? Why? If not, how will you deal with that? Will you renegotiate
the terms of the contract?
● How do you know enough about the job to be able to offer a precise and
reasonable estimate?
● If a competitor gives them a better offer, Will they ever come back to you?

The agile way

Jeff Sutherland, one of the inventors of Scrum software development process, gave
a talk in which he mentioned the “80/20 rule”: which states that “80 percent of
the value is in only 20 percent of the characteristics” of a software project. And
he suggested that “we should fund that 20% and not do the rest”.

“I believe that the rule is more a “95/5”, meaning 95% of the value is in
approximately 5% of the functions, and the people who pay for the project will see
it completed once that 5% is in use”, Woody explains in his article.

This is why some choose the “agile way”. In that model, it is acknowledged that
“requirements come up”. If we can be good at letting the most important and
useful requirements to arise naturally, it will amortize well.

That’s why the estimates requests exist: a customer that needs to know “how
much it will cost” before deciding to hire you for the project might not be the kind
of customer that is ready to let the unexpected to happen, because it is simply not
his/her way of thinking.

Not every customer requests a quote

It all boils down to this: you can choose who to do business with. If you choose to
serve customers who need estimates, then build estimates, quotes and find out how
to make that work for you. If you opt for customer who are willing to let the
requirements emerge, then go for the agile way and take a chance on them. It is
your choice.