In My Estimation

In our business we are constantly called on to estimate the time it will take to do something. It should go without saying that good estimating capabilities creates happy customers in addition to well-planned production schedules, definable profit margins and efficient development projects. Also, it should go without saying that we are better at estimating things we have done before than we are in estimating things we have not done before.

First, let me explain our process for estimating tasks and projects that we are familiar with. When a project or task comes along we start by finding similar projects and tasks we have already completed and then use actual data from our detailed time tracking reports to estimate time for each task and for each staff member making up the entire project. This "numbers" approach typically yields a very accurate estimate and we measure this accuracy at several points during a project and three months after project completion. This approach means that our ability to estimate improves as we experience more types of tasks and projects as well as situations with regard to client type, 3rd-party vendors and application of technology.

This brings me to things we do not have experience with. For the most part we also have good success at estimating new tasks and projects. We do this by drawing similarities to things we have experience with in addition to identifying any "unknowns" as professional development topics that we do not bill through to the client. Additionally, whenever possible we use servers, third-party vendors and technologies we are familiar with to further reduce unknowns thereby improving our chances that the estimate will remain good. If we are wrong, we do not bill the difference through to the client and take the mind-set that we "win some and loose some."

We recently took on a new client and a new project that seemed to be a great fit for what we do. The prospective client (a developer) ran into an area he was not comfortable with and needed something that was highly technical, custom and he needed it done fast. We had experience in this area and thought we could estimate very clearly how long it would take to complete the project. We factored in the extra time to work through and around another developer's code and extra time it would take to work with a server we were not familiar with. We posed and had answered a litany of questions about the server, submitted the estimate and subsequently won the contract.

Once the agreement was signed and we received full access to the servers we found that we could not do things as we had done before. Server configuration and access were different than expected and we had to write much more code to do the same thing. We did not compromise the quality of the product and impressed the client, but it took us twice as long. So, as previously described, we did not pass this added cost through to the client and now I am writing this post in hopes of learning something and passing something along.

Two questions:

• Clients: Would you give up access to your server and database to anyone wanting to submit a bid for your project for the purposes of estimation?
• Developers: Would you only estimate a project that you first had full-access to sever and database for?

This was the dilemma we faced. If we were the client we would not give access to bidders, but we would also want an accurate estimate. As developers, we would want to balance a quick and clean estimate/agreement with the possibility of too many questions, caveats and open agreements. So, in the case of our example we did what we thought best and gave a price after a good number of questions were answered, but still with some doubt.

Ultimately, we lost this one in terms of production time and profit, but I am not sure how I would have done things differently. We already feel that we ask too many questions when other developers just say "sure we can do that" and then figure it out later. We may annoy the heck out of a prospective client and may even loose some, but for now I think I will err on the side of too many questions.