How to: Estimate the Cost of Software Development
Updated - iZND Development
When a company or individual looks to estimate the cost of software development, inevitably questions like “How much?” and “How long?” are asked.
Two questions define the constraints that most clients experience in project work – “Can I afford this?” and “Can it be done in time to meet my expectations?”. Almost every sales meeting regarding software development revolves around getting answers to these questions. Often customers don’t realize the factors that affect the cost of software development. Estimates of software development costs can vary and the estimate process is not transparent to customers.
Here we outline what goes into estimating the amount of effort and costs of a software development project. These points will clarify the difference between timeline and effort, explore what factors are utilized to come up with an initial estimate, then discuss specific examples of projects with pricing estimates.
Every engagement is unique and there is no one simple formula that will work for EVERY scenario. That said, we at SphereGen have been helping companies for over a decade and are happy to share a few rules of thumb to use when estimating project cost. We’ve been able to identify 3 main components that have the largest effect on project cost and timeline.
The first questions typically asked by those looking to have software developed is, “How long will it take and how much will it cost?” But from a pure cost standpoint, that answer is all based on how much effort is required.
To answer the question of How Much Effort? – we need to make a distinction between effort and time. Effort is how many hours of work need to go into a project; Time is how long something takes from start to finish.
For example, 40 hours of effort can be put forth in 8 hours by having 5 engineers divide the work in one day on a project. Alternately, it could take well over 40 hours to get the same amount of work done if we weren’t able to dedicate an engineer to the project full time. Or if we ran into external issues, like a client not granting access to a server and waiting for a week before credentials are approved. In both cases, the effort is the same (40 hours of engineering time), but the timelines are different.
So, make sure when you get a project quote that it takes into account both effort and time. If you are told something will take “3 weeks”, is that 3 weeks from start to finish, or 3 weeks of effort? Now that we have that straight, let’s take a look at how to determine the amount of effort that goes into a project.
The first part of pricing comes down to how much effort is needed to achieve the desired outcome. i.e. how many engineers and how many of their hours per day will be required to get the job done.
Once we know how much effort a project will take in a perfect world, we then have to consider what circumstances outside of our control may come into play. These things can include:
- The ability of a client to dedicate staff to work with the project team for requirements analysis, design checks and user testing
- What does it take to get database or system access, Is this a quick call to a DBA, or is there an approval process that has to get committee approval?
- How easy is it to get firewall changes
- What needs to be done to get a cloud-based solution approved
- What is the deployment process?
These types of issues can exaggerate the difference between effort and timeline – and the longer the timeline extends, the more project management effort is needed to keep everything on track.
Now that we are square on the difference between timeline and effort, let’s look at the 3 factors we use to best gauge our likely effort and thus software cost.
Let’s explore 3 main factors that most affect software development effort/pricing:
- Type of Software Project
- Size of Software Project
- Development Team Size
1. Type of Software Project
From a high level, typical software development engagements tend to break down into the following types:
New Software Development – new software, involving custom development.
Software Modification – Enhancement of existing software.
Software Integration – Custom code to add capability or integrate existing software into other processes. This would include plugins to packages like Office as well as manipulating data flowing between an inventory system like Netsuite with an accounting system like Quickbooks.
Web Development – custom web-based software development
Each of these types of projects typically has a different team makeup and requires a different amount of development effort. Understanding the type of project is the first step in developing a cost estimate. This information will be used in combination with the size of the project and the project team to determine the final estimate.
2. Size of Software Project
The next step is to determine the size of a project. Size is a bit of a gut call. There tends to be a tight correlation between the complexity of a project and its size, but that isn’t always the case. Generally, project sizes fall into the following categories:
Small
– A small project usually involves minor changes. Typically, things like tweaks to the user interface or bug fixes that are well defined with a known cause. Interaction with the client is limited, i.e. “Is this what you want to be done?” followed up by, “Here is what we did..”
Medium
– These engagements are more substantial than a small tweak but likely have a well-defined scope of deliverables and are often standalone solutions or integrations. Typically, we are dealing with a single source of data. Projects such as a small mobile application or a web interface to an existing inventory system would fall into this category. The external requirements for interaction with a client are more robust than small projects. This might include a few design sessions, weekly check-ins, and milestone sign-offs.
Large
– These solutions include more depth and complexity. Large projects may require integration with multiple systems, have a database component, and address security and logging features. An underlying framework and a module-based design are common, taking into consideration scalability and maintainability. A multi-party application that works across numerous platforms (iOS, Android, Web) would fall into this category. The external requirements for interaction with the client are very robust, i.e Extended design sessions and milestone agreements. Daily calls and interactions with technical team members followed by weekly status calls with higher-level management are standard.
Enterprise
– This level would be a large project on steroids. Enterprise-level projects are almost exclusively built upon an underlying framework. They have much more rigorous security, logging, and error handling. Data integrity and security are paramount to these business-critical applications. Though not exclusive to this category, support systems are built to be resilient and able to handle 2-3 concurrent faults in the underlying infrastructure before having a user impact. A mobile app like Uber would be an example.
The external requirements for interaction with the client involve fully-integrated client and IT teams. Time requirements include extended design sessions and milestone agreements across multiple teams; daily calls and interactions with technical team members across multiple groups/disciplines; weekly status calls with higher level-management; quarterly all-hands meetings.
Using Project Types and Sizes to Determine Time Estimates – “How Long?”
Now that project types and sizes are defined, they can be combined to put together the following possible timeframes:
This grid provides a good starting point to estimate a project’s timeframe. Sales and Delivery can now give a quick estimate to clients regarding how long a project will take.
3. Development Team Size (per Project)
Once the project is defined in terms of type and size, the next factor to be determined is the team size. Every project requires at least 3 roles – a Project Manager, a Developer, and a QA Tester. However, that does not mean that every role equates to one team resource. Some resources can fulfill more than one role.
For example, In a small project, a Developer may also fill the role of Tester. In a small/medium project, the Project Manager may also fulfill the role of Business Analyst, and so forth. For larger, complex projects – team resources usually fulfill only one role to effectively move the project forward.
Rough estimates of team sizes may include the following structural roles:
PROJECT SIZE
*means required resource
| Role | Small | Medium | Large | Enterprise |
| Project Manager | * | * | * | * |
| Business Analyst | * | * | Multiple | |
| UI/UX | May be needed | * | * | |
| Architect | May be needed | * | * | |
| DataBase | May be needed | * | * | |
| Developer | * | 2+ | Multiple | Multiple |
| QA Tester | * | * | Multiple | Multiple |
| Total Roles | 3 | 5-8 | 6-10 | 12+ |
Straightforward Estimate
The most straightforward way to estimate project cost would be: Project Resource Cost x Project time = Project cost
Unfortunately, it is not that easy. As mentioned earlier, some resources may play more than 1 role on a project. Most resources do not work full-time on a project – for example, once anyone in a design role is done (Architect or UI/UX), there is no need for that resource to remain on the project 8 hours a day. They may be needed to confirm coding is meeting design requirements, or be available to tweak the design, but full-time is no longer necessary.
So you may be asking yourself, “Why would I pay for a full-time project team when the entire team is not working full-time?” There are a couple of answers to this question.
- You don’t pay for a full-time project team as the costs of the team are averaged based on the amount of work each resource completes per project. For example, the effort of a tester is usually expected to be a percentage of the entire project. The cost of a tester is based on this percentage.
- If your project requires a team, you are paying for a mix of skill sets. That means you have access to premium skill sets at a lower cost because you are only paying for a percentage of that person’s time.
- Scheduling and maintaining a dedicated project team is instrumental in completing the project most efficiently. There is nothing more detrimental to a project than continually stopping and starting- it can be hard to regain the momentum to get the project back on track.
A project team should work like a well-rehearsed production. Done well, necessary resources come on and off the project with no noticeable lapses in productivity.
Rough Estimate
To obtain rough cost estimates for a team, let’s utilize the following numbers:
These numbers do not reflect actual pricing of SphereGen software development but rather, they are what we use to provide a ball park to work from.
- ~$1,000/day – for a developer*
- ~$10,000/week for a team*
*many factors affect the pricing of a technical resource and team – experience, role, size, location – these prices represent rough costing for quick estimation
Now applying the cost of a team with the project time estimates from the chart above, we can finally come to a project cost. Using these numbers as a guideline, and assuming a certain benefit from scale (meaning larger projects results in better costing/week), we come up with the following pricing chart based upon our time/complexity grid:
| Small | Medium | Large | Enterprise | |
| Software Modification | $3k-$10k | $20k-$50k | $80k-$150k | $100,000+ |
| Web Development | $10k-$30k | $20k-$60k | $60k-$150k | $80,000+ |
| Software Integration | $15k-$40k | $50k-$80k | $70k-$100k | $80,000+ |
| New Software | $25k-$60k | $50k-$100k | $100k-$250k | $125,000+ |
The point to remember with this exercise is that the numbers are an ESTIMATE to get an idea of how much a project will cost and how long it will take. If the estimated cost is reasonable to everyone, then a more detailed quote can be generated, followed by a full project plan outlining the actual costs and milestones. Unless unknowns are discovered, detailed project costs tend to be within 10-20% of the cost using this method.
To put this all into context we put together the following list of representative projects:
Bug Fix – known issue
Resolution of a known issue in existing software that we are maintaining. This assumes that the cause of the issue is known, and the issue affects a minimal number of objects.
Type – Software Modification
Size – Small
Time Frame – 1-2 weeks
Cost – $2k-$10k
Proof of Concept Applications
Often the first step for many startups, these projects tend to focus more on the look and feel of a new application and the possibility of achieving the desired outcome, more than providing functionality.
Type – New Software
Size – Small
Time Frame – 4-8 weeks
Cost – $25k-$35k
Mobile Applications
Standalone application for iOS and Android. Moderate data collection, location awareness, secure cloud database interaction, push notifications, and administrative portal/functions.
Type – New Software
Size – Med
Time Frame – 4 Months
Cost – $60k-$70k
