Estimating software projects is hard. That’s why I was a little proud of myself when I recently completed a short client project right on time. My initial estimate for that project was ten days (or 80 hours) of development time. The actual time needed turned out to be 77 hours. I pretty much nailed it.

However, that is not to say that the project was finished within ten days. In fact, it took close to 8 weeks from beginning to completion. There were several reasons for this discrepancy:

1. I cannot complete ten days of full-time work in ten days. As a freelancer, I have to complete other tasks that invariably pop up. I often have to juggle multiple projects and clients simultaneously. Accounting and other paperwork cannot be postponed infinitely. And then there is the inevitable daily dose of entertainment, information and learning spent on Twitter and elsewhere on the web.

   All these tasks mean that even on a good day, I rarely get more than five or six hours of productive programming done. I don’t consider this a bad thing, by the way. That’s just the way I work. And the same thing happens to employees, too. There are meetings to attend and paperwork to be completed. The only difference is that as a freelancer, I don’t get paid for these tasks.

2. Delays in other areas of the project can delay your schedule. For instance, the designer requires more time to finish the graphics you need for the development of the next screen. In this particular case, the original designer had to leave the project and a replacement had to be found, causing a delay of more than a week. Another example is that the client needs time to discuss an aspect of the project internally and the project stalls in the meantime.

3. Any number of external events can cause delays.

Now some of these delays are predictable and others are not. My point is, make sure you know what you are estimating when you give your client (or your boss) an estimate, and communicate this to the other party. The difference between gross time and net time can be huge.

Joel Spolsky wrote a great post on evidence-based scheduling, his recommended way of estimating software development projects. This method implicitly includes the tasks I mentioned under (1) above. As such, it is a great way to arrive at a more exact shipping date estimate, but probably not suitable for estimating cost if your client pays you by the hour.