How to Accurately Estimate Project Cost and Duration
- 19589 views
- 7 minutes
Before you entrust a software development company with your awesome product idea, you have to be sure that they’ll properly manage your time and money. And before you begin your collaboration, you’ll need to review project development estimates. But how can you know if your team’s estimates are reasonable?
Perhaps you've already dealt with web or mobile development estimates in the past. Most likely, the final cost didn’t exactly match the initial estimate you were given. This is typical. Estimating the time and effort needed for web and mobile app development projects is tricky. And unfortunately, a poor estimate makes you run the risk of not being able to complete your project within budget.
But why do software developers fail to accurately estimate the timeframe and cost for implementing a set of functionalities? There are various reasons that we could consider, but today we’ll look at the five most common reasons why app development projects exceed initial estimates.
5 common reasons for exceeding app development estimates
- Obscure project requirements. If project requirements are not fully understood by a development company, then the company may leave some required functionalities out of the initial estimate. This scenario is common among software development companies that don’t follow best practices for eliciting requirements.
- Lack of estimation experience. Sometimes, project estimates are provided by non-programmers or by managers who aren’t actually qualified to make accurate project development estimates.
- The developer building the project isn’t the one who estimated it. Estimates are often provided by senior-level mobile or Ruby on Rails developers. But when the project moves to the development phase, the team building the app isn’t composed of the person (or people) who provided an estimate for it. Things get even worse when this team consists of lower level Ruby on Rails developers (middle or junior). Less experienced developers typically need more time to implement a given functionality than what a senior app developer estimates.
- Underestimating project complexity. Some features in a project might seem simpler at first glance than they actually are. When developers aren’t thorough enough, they may overlook some underlying complexities. As a result, app development takes more time than planned.
- Intentionally underestimating a project. Sadly, not all companies are honest with their clients. Some will underestimate projects just to win contracts. These companies typically charge lower rates and promise to deliver an app faster than their competitors. If you receive a project development estimate that’s markedly more optimistic than estimates provided by other software development firms, then be cautious. It’s possible that they’re trying to trick you.
Poor app development estimates lead to unrealistic expectations. As a result, you can lose control over your budget and deadlines.
So how can you know if your team has provided you with a reasonable estimate? The best way to figure this out is to look at the estimation approach that they’ve used.
What’s the right approach to estimating project development time and cost?
There are various approaches that help software development teams provide reasonable estimates. But most app development companies apply one approach to all of their software development projects. Is it realistic to apply the same approach to estimating a personal blog and a marketing automation system for enterprise?
We at Ruby Garage combine several estimation approaches to provide our clients with precise estimates for their projects.
Imagine you want to build an online store that sells cosmetics. Your project resembles Cult Beauty, an online store and advice resource for women's beauty products. You turn to Ruby Garage and ask for an estimate.
Here’s how we would approach your website development estimation.
Step 1. Eliciting requirements
Before moving to the estimation stage it is important for us to understand your product concept. We need to understand your target audience, their problem and how you’re going to solve it.
We’d ask you to provide us with a list of all features you want on your site, a list of competing products, and a prototype (if you have one).
This information-gathering process might take some time, but as a result, we’ll be able to formalize the scope of our potential work in the form of user stories or a to-do list.
Step 2. Decomposing features
Once we have all the information we need, we start decomposing features using the bottom up method. In other words, we break down large tasks into lots of smaller ones. We decompose tasks according to the following structure: Epics – User Stories – Use Cases.
Let’s take a look at a few examples:
With the scope of work already known, we can move on to the estimating stage. In our case we got a list of features that refers to shopping cart.
Step 3. Analogous estimation
As I already mentioned, our Ruby Garage team combines several estimation approaches to arrive at precise estimates. Let's see how it works.
At the first stage of estimation (for your online store that sells cosmetics) we will use an analogous estimating approach. This technique uses a measure from a previous similar project to estimate the cost and duration of the current project.
Your hypothetical project resembles Cult Beauty. So to use analogous estimation, we would need to identify a project we’ve already completed that is similar. As a matter of fact, we did develop ArtDeco for a leading German cosmetics store a few months back, and it has many similar features. This will be our analogous project for our estimation.
As it turns out, the shopping cart and checkout are absolutely identical in both products. The only thing we need to do now is transfer the hours it took us to build ArtDeco’s checkout to the corresponding field in your project estimate.
Relying on previous experience ensures more accurate estimates.
But we can use the analogous approach to estimation only if a previous product contains tasks that are very similar to those in the project we’re estimating.
Sometimes our new projects require features that we haven’t developed before. For example, in addition to categorized products and a shopping cart, you want your online cosmetics store to offer a bulk purchasing option and automatic subscription orders.
Since we haven’t built these features before, we’ll take an expert judgment approach to estimation.
Step 4. Expert judgment estimation
Expert judgment estimation looks to an expert or a group of experts who rely on their experience to estimate software development projects. The process of expert judgment estimation is iterative. We iterate until we reach consensus. Let’s see how it works:
- Our expert (or group of experts) research the features that need to be estimated. In our hypothetical project, those features are bulk purchasing and subscription orders.
- A project manager sets up a meeting with an expert group to clarify the scope of the work.
- The expert group decomposes the bulk purchasing and subscription orders according to the following structure: Epics – User Stories – Use Cases – Tasks.
- The experts estimate the number of hours needed for implementing bulk purchasing and subscription orders.
Step 5. Finalizing the estimate
Finally, a project manager considers the results of analogous and expert judgment estimations and arrives at a final estimate. We put this estimate into an xls document and send it to our clients.
Sometimes, our clients make some changes based on this estimate. They might abandon some features to save time, or might add additional features. If this happens, we provide a re-estimate.
We skillfully combine analogous and expert judgment approaches to provide accurate estimates. Since we base our estimates on real data, we can accurately estimate the time required for implementing a given functionality. In this way, we reduce the risk of exceeding your budget limits.
At Ruby Garage we value our reputation as a reliable and honest partner to our clients and always strive to stay within budget.