In our previous articles, we’ve discussed how much it costs to build a custom website or mobile app and the factors contributing to the price. Today, we’ll take a look at project cost estimation and how we approach estimating the software development budget. But let’s first answer the question, What is cost estimation?
Cost estimation in software engineering is the process of predicting the resources (money, time, and people) necessary to finish a project within the defined scope.
Accurate estimates help everyone involved in the project:
- Project owners can decide whether to take on the project.
- The development team can know what they are supposed to do and when.
- Everyone is on the same page.
There are two generally accepted methodologies for developing software: waterfall, also known as the traditional model, and agile. Their approaches to estimating projects are quite different. At Steelkiwi, we follow an agile development methodology. Why? Let’s explain using a real-world example of two similar projects by the Federal Bureau of Investigation (FBI) that were developed with two different methodologies and resulted in vastly different outcomes.
Prior to 2000, the FBI was using a paper-based file and record system as well as an automated case support system to manage all of their records. In the interest of upgrading their system, they approached Congress and requested funding. Congress approved $340 million for the FBI to build a criminal management system which was later known as Virtual Case File (VCF). This system was supposed to centralize data at the FBI and make it easier for agents to maintain and find information. Yet in 2005, the project was officially abandoned after $170 million had been spent on it.
Randolph Hite, director of IT architecture and system issues at the Government Accountability Office (GAO), says that VCF “was a classic case of not getting the requirements sufficiently defined in terms of completeness and correctness from the beginning. And so it required a continuous redefinition of requirements that had a cascading effect on what had already been designed and produced.”
Using the same technology, the FBI started to develop a new solution called Sentinel in 2006. Just as with VCF, the Sentinel team initially went with a waterfall approach. The FBI’s original plan divided the development project into four phases, entailed estimated expenditures of $451 million, and set a deadline of December 2009.
However, by August 2010, the Sentinel project was only halfway through and the expenditures had already reached $405 million. This was the moment they decided to shift from waterfall to agile. By adopting an agile methodology, the FBI managed to complete the remaining two phases for $30 million within a year. Ched Fulgham ― the FBI’s chief information officer ― says that “agile development turned out to be the right way to complete it.”
The waterfall methodology is a sequential design process, meaning each phase is started and completed before moving on to the next. Once a phase is completed, developers can’t go back to a previous step.
As there isn’t any room for error or change, waterfall stresses meticulous documentation so everyone involved knows exactly what to expect. However, if the initial plan is faulty in any way, software engineers then lack the ability to adapt and instead have to start over, which often leads to budget overruns. With Sentinel, just as with VCF, the FBI lacked an action plan that would determine exactly how they wanted the new management system to differ from the current one. With agile, developers don’t build the whole project at once. They develop it feature by feature. This allows for project modifications in order to achieve desired results.
With agile development, planning consists of three main building blocks: scope (requirements), resources (software development budget), and time. With waterfall, the scope is fixed while the budget and time are flexible to make sure all required functionally is delivered. This means that the project isn’t considered finished until it meets all requirements. The agile development, on the other hand, is quality-driven, meaning that developers aim at maximizing value while sticking to a fixed budget and schedule.
There are lots of different techniques for calculating the cost of software development. At Steelkiwi, we believe it’s reasonable to apply several project estimation techniques to produce more accurate estimates.
To explain how we estimate, let’s use an example. Say you have an idea for an Instagram-like app similar to one of our recent projects, Yontent. The Yontent app connects brands with bloggers who want to create paid product reviews. You contact Steelkiwi to request our services and an estimate for this project. Here’s how we’ll approach this.
At the outset, we’ll hold quite a lot of meetings with you. The goal of these meetings is simple: to grasp the idea of the project and discuss the design, functional, and technical specifications. Based on the information received during our meetings, we’ll create wireframes to visualize:
- The app’s navigation structure
- Layout: Page hierarchy and the placement of elements on screens
- Content placement within the design
- Functionality: How your product works and how it interacts with users
Once you approve the UX concept, we’ll proceed to creating requirements. Fully outlined requirements serve as the basis for calculating your software development costs and development hours.
For more precise estimates, we use a bottom-up technique. This means we break large tasks into smaller parts and define the time necessary to complete each of them. Then we sum up the estimates for all these parts to get the total estimate.
Alongside the bottom-up technique, we estimate features by analogy. For your project, we take previous similar projects and use their cost and time data to estimate the cost and time for your project. At Steelkiwi, we believe that real time obtained in similar previous projects is the best indicator for predicting the time required for a future project; it’s much better than estimating from scratch. Given our experience gained from similar projects, we’ll know what potential problems can arise, how to work with different development tools, and how to create the business logic for your project. Therefore, we won’t spend time examining these things but instead can use what we’ve done on previous projects. Accordingly, the estimate will be lower.
It sometimes happens that our new projects require functionality we’ve never developed before. Say you have an idea to integrate voice search into your application. As we’ve never done this before, we turn to our experts and count on their expertise to estimate this feature. They’ll define the scope of work and estimate the time required to build a voice search feature.
Lastly, our product manager reviews the estimates made by developers and experts and decides on a precise number. We create an Excel file, draw up final estimates, and send this document to you. If you decide to include new features or make some modifications, we re-estimate.
At Steelkiwi, we create an Excel file that comprises data on all costs, time, and human resources for the project. This file will include different tabs according to the services provided and a Summary tab where we sum up the approximate total hours.
The Summary tab includes the amount of time for development, bug fixing, architecture planning, and risks (challenges). It also outlines the number of sprints, developers, and meetings for each department (backend, frontend, iOS, Android, design, QA, and DevOps).
A tab for development services includes functionality, descriptions, risks, and hours. Like Yontent, your application will need registration and login functionality. In this case, your backend estimate tab contain the following information:
- Functionality and components: All necessary functionality broken into small parts. Take the social login feature as an example. We would break it into smaller tasks: the social authentication mechanism and authentication credentials, Google+ authentication, Facebook authentication, and Twitter authentication.
- Description: Notes on features (if required). In the case of resetting a password via an email link, we would specify what the password reset flow looks like: request ➝ confirm ➝ new password ➝ success.
- Risks: Challenges that may occur while implementing a feature.
- Hours: The number of hours required to complete each task.
We hope this guide has given you insights into how Steelkiwi estimates agile projects. If you want a free consultation with our team or want to get a rough estimate for your project, get in touch with our sales representatives.