How to identify an unrealistic estimate for the software development work
Underestimation of software development work is one of the biggest problems in the development industry. And not all can estimate the accurate time frame for the project tasks. But, at least, you can identify the wrong estimate. What are your options?
Recently, I received a quotation request for developing an image gallery extension for Joomla framework 4.0. The Joomla extension had complex features; searching an image based on its metadata, managing the album, and integrating all image features in the album.
This Joomla extension had a couple of custom modules and plugins to develop. And the owner created a 60 pages specification document. I could say the specification document had almost all the information.
I understood the complexity of the extension and discussed with my team how much time it should take to develop. I always take second feedback from the developer about the estimate. I may make mistakes – as another normal being.
The following is the estimate for the extension;
Total working hours: 200 – 250 hours.
Per day working hours: 4 – 6 hours.
And I committed to finishing the project before the last week of March. The prospect rejected my quotation, and upon asking the reason for rejection, he gave a strange answer as quoted below.
“You gave me an unrealistic estimate for the extension development. Other companies were offering me to finish it within 20 hours.”
Now I say 20 hours is an unrealistic estimate. Your thought?
How can someone create a complex image processing extension within 20 hours? It takes time to read and understand 60 pages of specification, create an architect for the extension, develop the complete extension - including modules and plugins, and then test it.
I knew other companies could not finish it within 20 hours.
I advised the prospective client to be careful about another company. And if it can not finish its extension before March, I am ready to assist you.
Many of you do not have enough technical understanding, and therefore, you can not identify between realistic and unrealistic estimates.
Compare against your benchmark estimate.
You have a benchmark estimate for comparing. No. You are wondering how you are going to get a benchmark estimate?
I have written a detailed blog about creating a benchmark estimate for the software development work. You can follow the guidelines and estimate your development work.
Or you can hire a professional consultant who can estimate your project. And in this case, I can help you in creating an estimate. You can get a free quotation from here.
Once you have a benchmark estimate, you can line up all the proposals and compare them. And remove all of those that are not close to the benchmark.
Find the median of all proposals.
If you do not have a benchmark estimate, you can sort all the proposals and then find the median of them.
Once you have the median, you can compare them against other proposals. The median gave a good idea of what you can expect from the development team.
And this method is used almost 90% of the time. Why? Because many clients do not want to invest money in finding the benchmark estimate. And later, they pay a lot in the failed projects.
Compare the company development experience.
And it is a critical step in finding the right development partner. You can sort all the proposals based on company development experience and then compare them against the estimate.
You find a strange figure.
The experienced company has a more accurate estimate, and it justifies the calculated estimate as well. It enlists all steps, framework constraints, and many other facts.
However, the experienced company also charges a little more than the inexperienced company.
If you apply the above rules, you can filter the realistic estimate from others. The next part is to get a detailed understanding of two questions;
- How the company completes the project within the estimate
- What if it can not finish in time.
The answer to these questions will further give you an idea of the reliability of the development team.
You should note an important aspect of software development. The estimate is only the projection of the work. Sometimes the development work gets blocked because of unexpected events – third-party library update, request change, platform instability, and many others. And therefore, you should have a plan of 20% plus or minus in the original estimate.
And I have the last thing to say on the estimate. You should not trust any developer or company blindly, but you should make rational decisions when selecting a development partner.