Two Reasons Why Estimates Aren't Worth It

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 Encourage 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.

4 comments… add one
  • Vlad Mihalcea Mar 4, 2014 @ 10:13

    Estimates...can't leave with them, can't leave without them!
    Anyone who's about to invest some money on a given project is interested of costs and profit, so we can't escape initial project estimates. The initial estimates are critical as they are a measure of both parties the ability to successfully communicate and understand each others requirements.

    But there are also iteration tasks estimates which are better replaces by story points. The story point number is totally subjective to the current team and it also depends on the person who estimates and the one who's actually going to implement it. So tasks estimates are still useful as you can somehow predict what to expect from a future milestone, do we need more team members, is there anything slowing them down?

    • Petri Mar 11, 2014 @ 21:20

      I understand why customers want estimates. They probably have an annual budget for IT investments, and that is why they want to know the cost of a software project so that they can decide if it is worth doing.

      If the developers know the problem domain and there is no uncertainty, estimating works quite well as long as long as the specification is "good enough". This doesn't of course leave room for changes and that is why the project must have a separate change management process (and customer must allocate budget for this).

      The problem is that most projects aren't really like this (at least if you do subcontracting work). When a project has a lot of uncertainty, creating an upfront specification (and estimating it) is a bad idea because no one can be sure what the real problem is.

      Nevertheless, if we specify and estimate the project before "it is started", there is a huge risk that we create something which doesn't solve the right problem.

      Also, Often (not always) upfront estimation means that the customer wants to sign a contract which has fixed price and scope (this is a huge risk to the subcontractor). That is why I think that estimates aren't useful in these projects.

      But like said, we will end up doing them anyway because the our other option is to fire the client and that isn't a viable business strategy (at least not always).

Leave a Reply