When potential customers contact us, the odds are that they want to know two things:
- How much does it cost to implement the application?
- How long it will take to implement the application?
The honest answer to both of these questions is:
We have no idea.
Needless to say, if we give this answer to potential customers, the odds are that they will not buy our services. That is why we use work estimates to provide answers for our customers.
The problem is that work estimates don’t provide the right answers. This blog post describes two reasons why I think that using them is not worth it.
1. Estimates Are Guesses
This might come as a surprise to our customers but our estimates are only guesses. It is pretty easy to figure out if a specific task is small, medium, or large. However, it is pretty damn hard to figure out how much work is required to finish a single task.
One reason for this is that sometimes estimates are based on insufficient information. The problem is that when we give these estimates, we might have only user interface mockups or a list of user stories. There is no way in hell that we could know how long it will take to implement this software.
Why?
Because we cannot estimate the unknown. For example, we don’t know
- How the data should be validated?
- What are the business rules of the application?
- How the authorization should be implemented?
There are a lot of questions without answers, and yet we should be able to give exact estimates. If you believe that this is possible, you are dreaming.
Every estimate given in this situation is a guess.
In other words, if we have a “detailed specification”, we can give exact estimates? Right?
Well, we can give “better” guesses. A “detailed specification” will help us to get a better understanding about the implemented application. This information ensures that we can make “educated guesses” about the amount of required work.
Why we cannot give exact estimates?
- It is “impossible” to write a specification which covers everything, and if something isn’t in the specification, we cannot estimate it.
- Some people are too optimistic and some people are too pessimistic. This means that we have to add “extra time” to optimistic estimates but how do we how much time we should add? We don’t. That is why we guess.
- It is impossible to know what kind of problems we will face during the project and how long it will take to solve them. Because we cannot estimate the unknown, we don’t include problem solving time in our estimates.
As long as we cannot eliminate the unknown from software projects, we must accept the fact that estimates are only guesses. This means that estimates shouldn’t be used to make any assumptions about the budget or schedule of a software project.
2. Estimates Don’t Encougare to Maximize the Added Value
Estimates are used for two different purposes:
- The customer wants to know how long it it will take to implement the application and how much it will cost.
- The software development company wants to ensure that the software project is profitable to them.
This means that the customer uses estimates to control the budget and scope of the project, and the software development company wants to make profit.
In other words,
- The customer thinks that the maximum price (and scope) of the project is set.
- The software development company tries to cover its back by ensuring that the estimates are “big enough”.
This is a recipe for disaster. Of course it is entirely possible that the estimates are correct and everyone is happy. However, if (when) the estimates are not correct, one of the following things will happen:
- If the estimates are too big, the customer pays more than they have to.
- If the estimates are too low, the software development company probably tries to minimize its losses.
The first scenario can be annoying but the odds are the customer is still a somewhat happy with the outcome.
What happens when estimates are too low? I can guarantee that the software development company wants to finish the project as soon as possible. In other words, adding value to the customer is no longer their main priority.
This can lead to a disaster.
I think that the most important goal of a software project is to maximize the customer’s return of investment. Sadly, using guesses (estimates) as a budget management tool will not help us to achieve that goal.
It Is Just a Game
I think that the only reason why we provide work estimates is that the customers require us to do so. To be honest, creating these estimates is pretty frustrating because everyone who sits in an estimation meeting knows that these estimates have got nothing to do with reality.
It is just a part of the game which must be played if we want to win (get the project). If our customer wants estimates, we must either estimate or fire the customer.
There is of course a better way, but I wonder how we can convince our customers to use it.
