Software estimates, as the name conveys, is a way to come up with a price to build a particular piece of software.
In terms of detail and accuracy, estimates run the gamut. An estimate could be a broad range based on past experience and gut feel, a series of high-level calculations, or a very detailed plan where all tasks are specified individually to come up with the final number.
The Best Way To Estimate A Project
The best way to estimate a project really depends on the type of estimate you need. Initially starting out, a rough ballpark figure is good in order to know if the project is feasible or not. As you move further along, getting more specific and detailed in what you want to build, your estimate needs to match.
When dealing with software estimates, it’s easy to hear a number and use that as your working figure. But knowing that estimates come in all different shapes and sizes, you can ask a few clarifying questions to gauge the quality and accuracy of the numbers you are given. If you take estimates at face value, you will probably be surprised at a later date.
Here are a few questions to get you started.
- Can I use this figure for getting funding from investors?
- How much detail has gone into this estimate?
- What assumptions have been made?
- Is there anything this estimate does not include that I might need?
- How confident are you that you can hit this estimate with my project?
- What is your track record with this level of estimate and projects like mine?
- How similar is my project to others you have done?
Assuming your project is billed as Time & Materials before you start development you will want to get a detailed estimate. The goal of the detailed estimate is not in arriving at details, but in getting the accuracy you need to budget and get funding.
There are many moving parts in software: environment set up, planning, coordination, creative design, architecture, front-end development, business logic, data management, reporting, interfacing with 3rd party systems, and testing to name a few. Writing the tasks down not only helps to assure that is everything included, but that the estimates across the board are in line.
For example, if designing the administration component of your application looks 2-3 times larger than building the main functionality, you can start to ask questions to gain a better understanding. Maybe it will take more effort or maybe there is a mistake. You can also see if any functionality is missing or listed twice. When dealing with a large project estimate, it is not unheard of to make a few mistakes.
One approach of estimation we found that works well for our clients is to group tasks by feature. This again lets you see if certain features seem heavier than others so you can cross-check for errors or misunderstanding, but it also allows you to weigh the cost vs. value if you need to cut scope and postpone items for a later release.
Ultimately estimation is a best guess and target goal based on the experience and calculations of your software project team.
Your software team will most likely factor in a buffer to accommodate unknowns based on their experience and the types of projects they handle. But as the person reviewing and approving the estimate, it is good to understand that even the best software estimate is still an estimate. Some tasks will be completed faster and others slower than predicted.
For more information on creating software budgets, managing your project to a budget, and the common reasons why software projects run over, see our other articles below.
The Checklist For Sharing Your Software Vision
Before you get started in developing your software app, your thoughts and ideas should be clarified and written down so they can be consistently and easily shared and understood. To help you get started on the right foot, we have created a checklist.
You can grab a copy of that checklist below and share it with your team!