Overestimating software projects
When it is difficult to assess the scope of a software project, one should not tend to overestimate.
"A good estimate provides a clear overview of the project's reality. It enables the project management to make appropriate decisions about how to control the project in order to achieve its objectives."
The preceding estimates are a difficult part of every software development project. It is often assumed that writing new software is like building a car, where you have a team of experienced technicians, a project roadmap, and a list of defined requirements that must be met within a certain timeframe.
While car mechanics work with known materials, established techniques and processes where everything is planned down to the smallest detail, software developers build many things from scratch and have to decide how everything should be put together and also still work according to customer request.
It is of course more difficult to predict when everything will be finished if the upcoming challenges are unknown, which one encounters on the way. However, this does not mean that it is entirely impossible to make a good estimate of the project duration, and it is certainly not an excuse for a complete overestimation of the project. We are not claiming to be experts in second-accurate estimates, but we definitely know a little and would like to share some of our practical experience.
Why estimate?
Companies need certainty about what they will get and when they will get it. Unfortunately, most companies are rarely certain about how software will be designed and developed. How much will the software cost? Customers should not try to determine this number themselves, so experts are often called in.
Why is overestimation a bad idea?
Although it is commonly argued that overestimating is less dangerous for both customers and contractors than underestimating, too large time estimates should still be avoided, no matter how "accurate" they may be. The reason is simple. If you overestimate the project duration by a lot, but get everything done within half the time, this does not necessarily mean anything good. This - seemingly reasonable - precaution of overestimation can cost you a customer's trust.
If you were to add a complex search function to a website, and you estimated it would take about 40 hours of work to complete, then you delivered the finished work in 20 hours. What does this say about you? Does it mean you work quickly? Not necessarily. There is just as much of a chance that the customer will assume you are incompetent and not really trustworthy.
As a rule, customers have some idea how much time it will take for a software developer to complete a project, based on their past experience. They can also compare your estimate with those of other contractors. For this reason, it's usually best not to disappoint customers by underestimating the time required. Our experience shows that it's better to let the customer know that the original time estimate will be exceeded than to give an overly optimistic estimate in the first place. Trust and open communication are always advantageous.
Another argument against overestimation are Parkinson's laws, which state:
"Work expands precisely in proportion to the time available for its completion."
If you give the team one month to complete a project that could be done in 19 days, the team will use the extra time for redundant rework, repetition and improvement. Such unnecessary downtime should be avoided; time is a valuable resource and there are always new tasks that are more rewarding than artificially inflated deadline projects.
