An accurate and reasonable estimate forms a strong foundation for a software development project.

There are many different ways that teams can approach the estimation process, and there is no such thing as a blanket “best approach.” A combination of expert estimation and historical estimation has been where we’ve found the most success, so we recommend these two methods.

Expert Estimation

An analogy for expert estimation is a mechanic who specializes in building classic cars. The mechanic may have built many classic cars from scratch in his lifetime. So he understands the process and can gauge the effort it will take to create something similar.

In software development, expert estimation is when industry experts provide judgmental estimates within the company. Experts are typically well-versed in doing similar work, and their experience gives them a more accurate gauge of what it will take to get the project done.

Successful When:

• There are highly-detailed requirements
• The person doing the work is also doing the estimates
• More than one expert weighs in on the final numbers

The Downsides:

• It is a time-consuming process
• Accuracy can only be expected when there is certainty in requirements
• Experts reflect the most optimal efficiency and don’t necessarily represent the time it may take for another team member to do the work
• They are predisposed to biases

Formal/Historical Estimation

Formal estimation is like plugging in all of your desired car specifications into a computer and having it add up all of the choices you’ve made (leather, automatic, technology) and spitting out a final number. This gets tricky when you want custom options that aren’t included on the assembly line.

In regard to software, historical estimation includes formulaic estimates where numbers are derived from historical data. This approach requires a company that has experience in building products with similar functionality to the proposed application. The concept here is simple: if the developer has done something similar before, it should be easy to insert the requirements of a new project, make a few adjustments and come out with an accurate estimate.

Successful When:

• There are historical parallels of functionality in projects the agency can reference
• There is enough information to assess incremental differences from work completed before
• It is paired with expert estimation as another point of reference

The Downsides:

• Features and functionality can easily be taken out of context
• There may not be work comparable enough to reference
• Project aspects can be missed if it lacks human intervention

You Get What You Pay For

When comparing the cost of building a software application across companies, it is important to remember that “you get what you pay for.” There is an inherent risk in accepting a relatively low estimate in the pool of prices. That can result in a minimal partnership, poor technical foundation, and potentially unsophisticated or unscalable code. Ultimately, a bad understanding of estimates can lead to wasted time and money.

When the focus is put primarily on efficiency, the wrong incentives can be given to the team. If developers feel pressured to whittle down estimates from what’s originally given, they might take shortcuts or compromise the functionality to fit the project’s budget.

This leads to a product in need of being built that is not realistic given the constraints. The client can end up with something they didn’t set out to create. It is important to be aware of this during the estimation process, staying informed about what makes up the ultimate bottom line.

It’s important to keep in perspective that we’re not just selling hours; we’re selling expertise. Part of that expertise involves allowing the team to dive deep into the project requirements upfront. This enables the most educated decisions and planning moving forward.

How Fresh’s Design-Led Approach Affects Estimation

We keep 3 aspects at the forefront of our estimation process:

1. Create certainty and vision, planning as much as possible upfront

2. Involve multiple experts and include historical references where applicable

3. When there is uncertainty, provide estimates as ranges, continually adjusting the ranges as uncertainty increases or decreases

Our approach is different than other consulting firms. We don’t throw the dart and then draw the bullseye around it. We draw the bullseye then throw the dart as closely and precisely as possible. To do this we pull on user feedback, analytics, and testing to better estimate the scope of work. Just like our scientific approach to design and development, we take that same approach with estimates.

The process focuses on the end user, which is why we strongly advocate for an in-depth discovery so that design is well-informed. This makes the handoff to developers more seamless.

To us, a design-led approach is extremely efficient. We take steps to identify and eliminate user acceptance issues during the prototype stage before even one line of code has been written. That is not to say we don’t iterate—we do—but from our experience many agile projects incur a lot of wasted effort. This includes building and correcting features that could have been designed correctly from the beginning.

Wrap Up

Waiting to provide holistic estimates until the entire project is well defined is a mutually beneficial piece of the process. Then, whether the contract is fixed or hourly, the majority of the risk is mitigated because there is more certainty in the project. Things can still be left open-ended to account for the likely change in requirements throughout the project, as these are to be expected and lead to adjustments of estimates/scope along the way.