When starting your software project, the budget and timeline are essential. You go to your software developer and ask them to give you a software estimation: how much will this cost me, and when can I expect it to be completed?
However, this isn’t the easiest question for software developers to answer. Here’s how Amplified estimates software projects - and why it’s not as simple as you might think.
Think about building a house. You know how much material you need given the square footage and the schematics. You know the raw cost of the material. You know how much labor is necessary to build the house, over what period of time. And once you pour the foundation, you are not making major changes to the design of the house.
But software doesn’t play by those rules. In many cases, like building a home, having a firm quote is the norm. In the software industry, however, it’s very difficult. This is because:
Software is abstract.
There’s more than one way to build a functioning software product. In many cases, you don’t know which way is the best until you try it. Estimation is simply choosing one way as the best-case scenario and then being open to changes. Speaking of —
Software is malleable.
Requirements for a specific project frequently change and that has unforeseen impacts on the overall estimation. As developers, we have to be open to those changes and work with them.
Software is intellectual.
Think about a really hard math problem. How long do you think it will take you to solve that math problem? It’s hard to say. But solving math problems is what engineers do all day. Each will have their own method for solving it, and it’ll take them a different amount of time. Estimations can try to assume the average amount of time it might take, but it’ll never be exact.
So how do we estimate software projects at Amplified? We offer two types of estimates: loose and tight.
A loose estimate is by nature going to be less accurate and less exact than a tight estimate. Effectively, a loose estimate is a guess based on comparable projects we have built in the past (comparable in terms of product scope, ambition, etc.). This kind of estimate is useful for preliminary conversations to establish initial budgetary alignment, but it’s not a reliable number. There’s a wide margin of error for loose estimates, and often you’ll find the number changes — drastically.
To develop a more realistic budget, your developer needs to give you a tight estimate. Tight estimates are much more reliable, since they break down the work to a matter of hours, days, and weeks. A tight estimate accounts for every component of the project, who’s working on it, how long it’ll take them to do it, and the sum total of each component, plus debugging and fixes.
To get a tight estimate, you’ll need to provide your software developer with the following:
Overall, the more details you can give your developer, the more accurate your tight estimate will be — and that way, you won’t get many surprises later on.
Our process for creating a tight estimate is rigorous. We want to give our partners a number that’s as close to what they’ll see at the end of the project as possible, so they can plan well. It also tells them that we’ll be honest with them every step of the way and sets expectations for our relationship with them.
We take the following steps to come up with an estimate:
The more questions, the more answers, the more precise the estimation.
3. We determine what technology stack will fit with the project.
4. For each part of the project, we:
We cycle these steps for each feature.
5. Next, we compare the project with something similar. Our team has individually and collectively worked on many projects, so we can use a comparable project to help in our estimation.
6. We add buffer time for testing.
7. We add extra time to test for bugs for each feature.
8. Now we have all the tasks for each feature. We separate tasks by team members so we can put them in a calendar; some tasks can be done at the same time.
9. We add the number of hours for development and add buffer time for system testing.
10. We arrange hours in a calendar period, taking into account that every week there’s also planning and meetings. The leftover time is what the developer has available to work.
11. We divide the total hours needed by hours in a week, which gives us the number of weeks.
12. We add a buffer week for sickness or anything else that might delay the process.
At the end of this process, we have an estimate that we feel comfortable sharing with our partners.
It’s worth noting that within Amplified’s tight estimate, there is still a margin of error, which we account for and communicate to our partners. Therefore, the tight estimate will actually be a range: as we estimate, we include a target hourly estimate, and also a minimum and a maximum cost they can expect.
In some cases, if we know exactly what to build and there’s a high degree of confidence in our estimate, the margin of error will be small. In other cases, the margin of error will be wide, for example, if we are less experienced with that particular task, in which case, the estimate is only our best guess.
When we calculate the target estimates and the minimum/maximum, we get a range of hours needed to execute the entire project. Then we multiply those hours by our bill rates and we end up with a range for the estimated project cost, which is effectively $X +/- Y. So ultimately we always communicate estimates as a range, which allows clients to visualize both a best and a worst-case scenario.
If we’ve run a thorough and honest estimation process, and if the scope of the project doesn’t significantly change through the course of software development, then the odds of being over budget should be the same as being under budget. This range offers our partners a more realistic, useful, and honest view of their project and our work.
