Accurately estimating the time it will take to build a project seems to be a problem in IT shops worldwide. One of the reasons may be because many people confuse the project estimate document with the sales quote.

These two documents serve different purposes, even though many people feel they are interchangeable. To put it simply, the estimate is what someone—hopefully a developer—thinks it will take to build a project according to the specifications given to them. The sales quote, on the other hand, is what the sales person thinks he or she can get the client to pay for the project.

Most of the time, there is some type of sane correlation between the two documents—but not always. Creating the project estimate is a complex and time consuming process that should be treated with the appropriate seriousness because, as the estimator, you are setting expectations. Resist the urge to give the specifications a quick read and tell the sales department (or worse yet, the client directly) “This should take us a month.”

Without the proper thought process, your estimate can’t be accurate and, in the end, that hurts everyone involved. Regardless of the pressure that sales will put on you for a “ballpark number”, keep mum until you have the time to properly do the research.

The sales person should be the interface with the client, not the developer creating the estimate. Once the estimate has been delivered to the sales person, there are several variables they can adjust to get the final project price into the client’s budget range. One of the things that they should never adjust though is the number of hours estimated to complete the project. If the final project price comes in high, the sales person can adjust the hourly rate or work with the client to reduce the feature set. These variables are fully under the control of the sales person and within their domain to adjust; the estimated number of hours to complete the project is not.

In many cases, especially in small web development shops, the person doing the estimating and the sales are the same person. If this is your situation, make sure you can “compartmentalize” the work; when working on the estimate, put on your developer hat, and when working on the sales quote, put on your sales hat (mind the propeller on top).

In these situations, it is easy to start second-guessing yourself—and you have to resist that. Developers, after you create an estimate that you feel is accurate and defensible, defend it. Don’t allow the sales department to send it back and tell you its too high, even if that sales department is yourself. Defend your estimate and make the sales department do their job and sell it to the customer.