By Michael Solomon, 10x Management Co-Founder

Here’s the brief! A great estimate will:

1. Break down larger tasks into smaller, manageable, and measurable tasks.
2. Take into account the experience and history of the programmer.
3. Consider the full potential of the project. Is the customer asking for a down and dirty Minimum Viable Product (MVP) or a fully scalable product? Both can appear the same but the underlying product is very different as is the underlying time in creating each.
4. Depend on the scope of the project and the amount of data provided by the customer.
5. Provide a buffer for mistakes and misunderstandings, because these are generally inevitable.

At 10x Management, we facilitate contract work between high-level freelance technologists (sometimes referred to as contractors, agile talent, freelancers, 1099s, consultants, etc.) and companies looking to engage them. Often, the art of due diligence and the hiring process for the companies (we refer to them as our customers) that hire our tech talent includes asking for an estimate of how long a project will take. For example, if a customer wants to build a mobile app for a new service, they will ask one of our top-tier developers before any work has begun for an estimate of approximately how long the build will take.

Given the right information from a customer, truly great programmers can provide fairly accurate estimates within a reasonable margin of error. We always screen our developers to ensure that they are realistic and vigilant with their estimations – and we work closely with them to make sure all the right questions are asked when preparing an estimate. We also know that they have only gotten great at estimating through trial and error (and learning from prior mistakes!) which helps them offset their own biases with the right multiplier to make the final estimate more accurate.

5 Tips for Getting Great Estimates

• A great estimate will break down larger tasks into smaller, manageable, measurable, and deliverable tasks.

Dividing the project into separate tasks and providing estimates for each of those tasks will simplify the timeline process. It provides measurable results as the project is underway and a checklist of things to do.

• A great estimate takes into account the experience and history of the programmer.

While most estimates in programming are arbitrary, a programmer with a lot of experience can look at a project and provide best case and worst case scenarios for each task. A great programmer will build their known margin of error into the estimate. The worst case scenario (where errors happen and everything is as complicated as you think it will be) will be the long estimate, and the best case scenario will be the short estimate.

• A great estimate will consider the full potential of the project. Are you asking to build a down and dirty Minimum Viable Product or a fully scalable product?

Sometimes, freelancers’ estimates can be drastically different for a very important reason: they have completely different visions for the exact same product.

If you’re building something worthwhile, one freelancer might look at the product and think of a simple solution that would function perfectly in the short-term and require 50 hours to build. Another freelancer might look at the same project, and want to build a fully scaleable product that is meant to last for years and contemplates future features. They might determine that the same project will require 300 hours to build. In the immediate short-term, these products will look virtually identical, but one will function at scale and one will not. If you don’t instruct your freelancers as to which type of product you want, you will likely end up comparing bids for projects with different scopes.

If we take the analogy of building an app to building a house, the point can be demonstrated a little more clearly. Let’s say you want to build a 2 story house with the option of adding a third floor at a later date. One contractor might come to you with a low price and a quick timetable, and build you a perfect 2 story house. Another contractor might come to you with a high price and a longer timetable, and also build you a perfect 2 story house.

The difference?

The first contractor built you a foundation that could only sustain 2 stories, while the second contractor took the time to build a solid foundation that could be expanded on to add a third story (and maybe even a fourth!). In the short-term, both of these solutions work, but the second contractor will ultimately be your savior if you want to scale.

This is where the concept of technical debt is so important in the technology world. The reality is that providing a short-term solution (like a quick 2 story house) is actually much more work in the long-run than building a solid foundation on which you can expand. A great estimate will not accumulate technical debt for the opportunity to save time. If a project is time-sensitive, a great programmer will know the limits of time sacrifices and how to best handle making these decisions. Sometimes an MVP is all that is required but either way, the contractor needs to know what the goals are.

• A great estimate will depend on the scope of the project and the data provided BY the customer.

This is where the customer plays such an important role in ensuring that a time estimate is met. The programmer can do only so much given the information he or she is provided prior to the start of an engagement. If there is not a detailed software scope or product description outlining the project details, it is likely the programmer will not be able to provide an accurate estimate. Similarly, if not enough data is provided by the customer regarding the project, or if there is existing code that is poorly documented and maintained that a programmer has to sift through, the timeline will be longer. The sooner they have the information, the sooner they can react.

• A great estimate will provide a buffer for mistakes, because they are inevitable.

A great engineer knows his or her limits and the amount of leeway they will need when performing a task. There are always going to be challenges in programming, so allowing for a margin of error is necessary. As stated earlier, when you provide a window of time in which a project can be completed, you are allowing yourself that contingency time to finish well. The other things a buffer allows for, if all things go smoothly is the ability to deliver earlier than estimated and for less money.  Nothing makes a customer happier than that!   

After all of the engagements that 10x Management has set up and overseen, time and billing estimates have emerged as two common sticking points. That’s why it is so important to know with a high degree of certainty the productivity and experience level of your engineer. Working with a reputable company and checking references is a great way to avoid the pitfalls of bad estimates. We rigorously screen our programmers to ensure that they have the technical chops and experience to provide and follow through on their estimates to customers.

I’m curious to hear your take on this article. Please comment below.

If you enjoyed this article you might also enjoy reading The Advantages of Remote Work – From the Perspective of Businesses