Business-focused custom software

I recently delivered some software to a customer that took more than double the time of my original estimate. Since my bids are typically at a fixed rate it didn't affect my customer's costs. However it could have affected their planning timeline for implementation.

Here are some things you should keep in mind about software development estimates:

Estimates are by their nature imprecise

An estimate is called an estimate because we don't really know for sure how long it will take. If we knew for sure, we'd call it something else. The only way to know exactly how long something will take to complete is to, well, complete it, and then count up all the hours. (But that won't help you with planning beforehand.)

Give yourself some wiggle room

I was lucky - even though delivery of my software was delayed, it didn't negatively impact my customer too much because some other dependent activities in the project had also been delayed. That being said, be smart and give yourself some space between dependent activities so that if something goes wrong you have some maneuvering room.

Understand the risks

The primary reason my project took longer to complete was that it used technology unfamiliar to me. The result was that my estimate did not account for several tasks that were required to complete the project. And for the tasks that I did include, some of them took a lot longer than I anticipated because using the technology was more complex than I thought.

I would have been much better prepared if I had accounted for this risk better in my estimate. Within the spreadsheet I use to estimate projects, I use a "confidence" percentage both at the task and the project level. The idea is for me to identify how confident I am about the task or project based on my experience with the technology, subject matter, or other factors. This percentage is then used in calculating my estimate. Lower percentages add more time to the estimate to adjust for the additional risk. In this case, I should have used a much lower confidence percentage than I did, given my inexperience with the tool. I also should have communicated this to my customer, so that they were prepared for any potential delay.

The primary reason I am able to provide fixed fee pricing for my customers is that I am very good at estimating the effort involved. However sometimes I get it wrong, and your developer will too occasionally. Hopefully they will learn from their mistakes so that the next estimate is even more accurate.