Understanding the Challenges of Estimating Software Projects

You may be looking to build an MVP for your startup idea, and you may have started contacting freelancers and software development consultancies to inquire about estimates. If you have done this, you probably ran into one of these types of providers:

A. The over-optimistic freelancer:

He can build your product in 100 hours and for $5000 dollars. Everything you showed he seems reasonable and easy, and he was able to determine within 30 minutes of conversation what your product will cost and within how many hours it can be delivered. 

B. The cautious consultancy:

This company does not like to give estimates, especially not fixed cost estimates. It’s a double edged sword: estimate too conservatively and they won’t get the project, estimate too optimistically and they will run into trouble when things go over budget. This company will have told you that software development estimation is not an easy task or an exact science. They will take some time and produce a “best effort” estimate, and clearly state that the actual work may not reflect the initial estimate. This estimate will have left you with a sense of uncertainty as it boils down to “this may take about 500 horus, and it’s possible that we may complete it by May, but we really aren’t sure”. If you did it right, you probably received estimates from both these guys, and are now confused about how to move forward. Do you go with the guy who is sure he can do it in 100 hours, or with the company who may or may not be able to do it in 500? 

In our experience, avoid the lowest quotes. These are well meant, but not well thought out. They often come from developers who haven’t worked on the project management side of a software consulting company and usually have the following problems:

• They assume the best case scenario: These estimates don’t consider bugs, mistakes or mysterious problems that usually arise during development. 
• They don’t contemplate full requirements: Very rarely do these estimates come from a full list of requirements, but rather from a verbal description of the project. They have almost certainly missed important details that will add significantly to the cost of the project.
• They make assumptions about requirements: These estimates often assume the easiest path for the requirements. 

As a rule of thumb, I recommend that developers who don’t have formal processes and experience with estimations to do the following:

• List out every feature and chore in your app in a spreadsheet
• Estimate the time it takes to do each one in hours
• Multiply your final estimate by 3. 

Multiplying the final estimate by 3 usually gives a more accurate estimate of the actual time and effort it will take to build this product. To understand a little bit more about why cautious consulting company is so coy about giving an estimate, let’s talk a little about why software estimations are so difficult.

1. You don’t fully understand what you want: Most clients don’t have a full understanding of what they want to build, but rather a vague idea. The worst ones are the “uber for cats” and “airbnb for hair salons”. On the other end of the spectrum there are folks have actually taken the time to list out a few paragraphs describing their idea and potentially some bullet points listing out the features they want. They have not decided on whether they will be using Stripe or Braintree, whether they want their app on both Android and iOS or only iOS, and they definitely want the dashboard where they can see reports on everything. Those requirements are still vague enough that this product could cost $50K or $150K. 

2. Estimating properly requires a lot of time: Producing a proper estimate requires first refining the requirements to a fairly detailed level, then dedicating a good number of expensive developer hours to sit down and list out what is required to build that product and how long each of those tasks might take. For a $10K project, they will not want to spend more than a few hours estimating. 

3. Your understanding of your MVP will change: The requirements for software products often evolve as they are being developed. Once clients are able to see their products as they are being built, they often realize critical changes are necessary. These changes, although apparently minor, often require significant additional work from the development team. These changes are hard to predict and hard to estimate initially. 

4. Even well done estimates can be substantially wrong: If you’ve been in the construction industry you understand why this is. Bridges, stadiums and pretty much any type of construction project frequently run over budget. These are projects where every blueprint has been drawn, every construction material has been accounted for, and yet there are still budget overruns for unpredictable reasons. Just like in construction, software projects have thousands of variables and unknowns that may affect the end result. 

How can I get a better estimate?

There are a few things that you can do as a client to ensure you are able to get better estimates. Here are a few of them: 

1. Understand that an estimate is an estimate: Freelancers and consulting companies both fear that they will produce a ballpark estimate which will then be taken by the client as a quote. Make it clear that you understand that an estimate is just that, an estimate, and that you want it just to get an idea of what your product might cost.
2. Take the time to think your product through: To be able to product an estimate, the team relies on you to think about the business use cases for your product and make decisions as to what features are necessary. The better you can define these features and functionalities, the less guesswork there will be on for the software development team.
3. Create clear documents outlining what you want: Spend some time and product proper documentation on what your product is. Think about this as a business plan: if you are going to be investing $10K, $50K, $100K or even $500K on a software product, you will benefit from having a clear picture of what you are looking to build, and a detailed understanding of what features and functionalities need to exist. These docs will be invaluable in helping the development team produce a faster and more accurate estimate. 
4. Have a clear budget: One of the hesitations companies have in putting the time to produce estimates is that we will go and spend a number of hours putting in work to later be told that the client only has a budget for 20% of their estimate. Deciding on a maximum budget and being upfront about what it is will make everyone’s life easier. If your budget is too small, we may recommend some features that can be removed, or simply refer you to a lower cost firm. Some clients fear that letting their budget be known will increase the price: normally what happens is that it helps the company guide the conversation towards the best solution possible with the available budget. 
5. If you need a detailed estimate, offer to pay for it: Many companies will be glad to put in the time and effort to help you flesh out your idea, build requirements, draw up mockups, and then produce a much more accurate estimate if you are willing to pay them for the 10, 20 or 30 hours of work required to do so. It also helps them assuage the fear that you are not a serious buyer.

Remember that a serious software development firm wants your project to be successful just as much as you do. The best case scenario for them is a project delivered on time, within budget, with a happy client and a well built product. A good development company will make their best effort to give you an accurate estimate and to keep realistic expectations, but will require your help to do so. If you would like to talk about estimating your project, please reach out to us.