Publication Date: 1/6/2009 6:18:01 AM
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:
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.)
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.
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.
Your URL (optional):
Type the code shown
Top 5 Programmers to Avoid
What everyone should know about bugs
How to tell if an estimate sucks
The Secret to Building a Crappy User Interface
The Problem with Selecting the Lowest Bidder
5 Ways to Control Software Development Costs
Avonelle is an incredibly talented software developer. She works fast, is economical, and offers great insights into the project at hand. She is also not afraid to speak up when she has concerns about a decision or approach. We’ve utilized her talents on many of our software development projects over the years.
Carrie Rocha, Chief Operating Officer @ HousingLink
Copyright © 2013 Avonelle Lovhaug. All Rights Reserved.
Sitefinity ASP.NET CMS