Stop overestimating your software projects
“A good estimate is an estimate that provides a clear enough view of the project reality. It allows project leadership making good decisions on how to control the project to hit its targets“.
Steve McConnell
The estimates are a tricky part of every software development project. Oftentimes people assume that writing new software is similar to building a car, where you have a team of experienced technicians, a project roadmap, and a list of requirements to meet within a certain period of time.
Then why is it such a big deal to provide an accurate estimate? While auto mechanics work with known materials, established techniques and processes where everything is planned down to the last detail, software developers build a lot of things from scratch, and have to decide how to put everything together and make it work as the client wants.
It’s harder to predict when you’ll finish if you don’t know all the challenges you’ll face on the way. This doesn’t mean that it is impossible to make a good software estimate, and it is certainly not an excuse for overestimating the project. We don't claim we are experts at creating accurate estimates, but we definitely know our way around it and would like to share some of our hands-on experience.
Why estimate?
Businesses need certainty about what they will get and when. Unfortunately for most businesses, there is very rarely any certainty in software design and development. How much is the software going to cost? Clients can’t and shouldn't try to guess this figure themselves. So they are quite right to seek out an expert.
Why overestimation is a bad idea?
Despite all popular arguments that overestimating is less dangerous than underestimating for both a client and a contractor, we still try to avoid doing so. The reason is simple. If you overestimate a lot, and complete the task within half of that time, you are in trouble. This - seemingly reasonable - precaution could cost you a client's trust.
Say you needed to add a complex search functionality to a website and you estimated it to take 40 man-hours to complete. Then you deliver it in 20 man-hours. What does it say about you? It means that you work fast? Not necessarily. There is a good chance that client will assume you’re incompetent and not trustworthy.
Usually clients have an idea about how much time developers need to get work done based on a past experience. They also may compare your estimate to the ones from other contractors. So, we try not to ruin client expectations with overestimating. From our experience, it is better to inform the client that we are to exceed the original estimate than to protect ourselves with that extra time.
Another argument against overestimation is a protection from so-called Parkinson's law that says:
Work expands so as to fill the time available for its completion.
If you give the team a month to deliver the project that could be done in three weeks, the team will use the extra time for revising, redoing, and improving. We don't want this to happen because the time is a precious resource, and there are always the tasks to move on to.