Even for tech-savvy buyers, the process of collecting and assessing quotes for a software development project can be complex and a little confusing because, no matter how many vendors you reach out to, every single one will provide an estimate that’s different from the rest. Unlike commodities or off-the-shelf products and solutions, for which you can compare competitive offerings side-by-side, apples-to-apples, software estimates aren’t that clean cut. In fact, they’re more like educated predictions than firm pricing. After all, because custom software projects are built from the ground up, specifically for each unique buyer, these estimates are all built around a degree of uncertainty.
But that doesn’t mean the numbers on the quote come out of nowhere. Usually an estimate contains two large sets of numbers, and they are calculated differently. The first set of data refers to the core functionality of the application and its features. Here, an engineer or a group of engineers make predictions regarding pricing for each feature based on their experience creating similar features for other products. Although there is always a degree of uncertainty here, these predictions should be fairly accurate assuming the developers have worked with similar features in the past. For features that are outside of the realm of the developer’s experience — or features that are more complex or dependent upon third-party systems — the estimator may account for that added uncertainty by adding reasonable risk budget to the estimate.
The second set of numbers refers to “generic activities” that aren’t related to developing specific features but are integral parts of the software development process. Examples of these activities include quality assurance, project management, tech leadership, and sometimes additional business analysis efforts. The budget for these items isn’t calculated as an estimate but as a percentage of the features estimate above. The vendor usually approaches these parametric estimates with a statistically significant amount of data regarding the use of these services, and a savvy vendor always know how much effort will be required to release a quality application, considering the factors of industry, application type, client’s personality, complexity, level of details, and possible changes. Additionally, it’s important to note that these don’t scale down well — even a small project needs project management and quality assurance — but they do scale up, as these “intangibles” become even more important as a project grows in scope and complexity.
Assessing Your Software Development Estimate
To a potential buyer, these numbers can feel arbitrary and difficult to parse. But a better understanding of what goes into a project estimation can help a business choose the right vendor for its projects. To help clarify the process, here are a few tips to help you make heads or tails of your custom software estimate.
1. Is It Itemized?
When an estimate is nothing but the high-level numbers, that’s a red flag. A quality vendor will itemize every key feature and its estimate (though occasionally minor features can be rolled into the larger ones they support) and clear explanations of the “generic activities” that support development. Once you’ve looked at the overall sum, you should be able to see exactly where each dollar comes from.
2. What Tools Did They Use to Create It?
While there is no industry standard program vendors must use to create estimates, it’s not a bad idea to look into how the estimates you receive are made. Tools like MS Project help vendors account for every piece, from timelines to dependencies between features and process to costs, resources, Gantt charts, and more. When an estimate presents features like these, that’s a good sign that it’s thorough and well thought-out. If, however, it’s too minimalistic or looks like it’s been slapped together in a hurry, you might consider looking elsewhere.
3. Is It Thorough?
Once you’ve checked to be sure the estimate is itemized, make sure it accounts for all the efforts involved in software development, from features, requirements engineering, and architectural and technical design to quality control, project management, user acceptance testing, pre-release stabilization efforts, business analysis, technical reviews, and the allocation of development efforts throughout the features. One way to tell if any big pieces are missing is to compare estimates side-by-side. While, as we’ve mentioned, no two will be formatted the same, you’ll be able to flag big-ticket items that are present in one but missing in another.
4. Do Timelines Match the Team?
Your estimate should also include detailed information about timelines and team size, and it’s important to make sure the two correlate well. Do the overall team size, monthly workload, and ramping up/ramping down efforts make sense? If a vendor is suggesting kicking off the project with the full-scale team at work from the start, that’s a red flag. The start of a software project should include a gradual process of increasing and adding capacity, and winding down the project should be the reverse process. Also keep an eye out for points where resources are unreasonably concentrated or out of balance in favor of speeding up the timeline. This is a common operational mistake, and good vendors will always avoid it.
5. Where Are the Checkpoints?
You should start seeing progress from your vendor long before the project is completed, and a good estimate will indicate that. Look for clear milestones, achievements, and deliverables that will allow you and the vendor to ensure you’re aligned in vision and expectations from start to finish.
These questions will help you assess the validity of an estimate, but the best way to qualify a quote is to ask specific questions of the vendor based on the materials they provide. Vendors shouldn’t be pulling estimates for thin air or consulting their crystal balls for the details. Instead, they should be implementing logical, data-driven process, and they should be able to use those processes to support every item in the document. If a vendor can’t answer your questions about the estimate clearly and effectively, that’s a sign you won’t work well together. But when they can provide firm, well-grounded answers, then you can feel comfortable adding them to your shortlist.
