Software Cost Estimation: How to Calculate Your Budget and Stick to It

If you want to make God laugh, just tell Him about your plans. If you want to make God cry, tell Him you’re 100% confident that you have a precise budget for your digital project. 

When you don’t doubt the accuracy of the budget, your project is much more likely to fail. In this case, your team is ready for only one scenario while many unexpected things can affect the software development cost. Pulse of Profession reports that 39% of IT projects that excessively trusted their cost assumptions finish with a significant cost overrun, and 34% out of them fail due to a budget loss.

Since setting a certain budget is hardly possible in such an uncertain world, estimation of software development costs should be agile enough to avoid unnecessary expenses and set priorities for development of the product’s most important features.

That’s why the JatApp team devotes this article to a discussion of how you can estimate your project costs effectively and what you should do to gain more product value with less expenses.     

How budget estimation works

In general, estimation of software development cost is a process of guessing how much time and money are necessary to develop a digital product. A prediction usually bases on the project requirements and resources availability. 

Conventional software cost estimation models calculate the budget according to a fixed list of features that should be in the final product, while time and money are the main variables. Let’s take a look at several examples.  

Conventional models

• Constructive Cost Model (COCOMO). This software development cost model simply estimates the cost of software development by calculating the number of code lines, effort of tech workers who will write it, and amount of time necessary to complete the whole project.  

• Expert judgment. Software development cost estimation with this model is also plain as day. An experienced project manager or even a software engineer just predicts how much the solution will cost according to their knowledge and experience. 

• Static single variable. That’s where traditional cost estimation gets complicated. The model uses several formulas to calculate the cost, effort, and duration. We don’t want to bore you with all these complex figures, so we suggest googling them if you believe this model is what you need for your budget estimation (we bet it’s not). 

• Static multi variable. If you think that numbers and formulas in a static single variable model are not enough, you can try to use this model as well. It works just like a single variable model but also takes into account such factors as effort adjustment and cost drivers.  
• Estimation by past projects. Making a cost estimation by using the data from past projects is pretty much the same as the expert judgment model, but you don’t delegate a decision-making process to your project manager only. Instead, your team members review past projects of your company and similar projects of your main competitors. 

Agile approach

The Agile approach focuses on the product’s scope instead of time and money. Business environments are rapidly changing, so investing money in development of necessary features only is much more effective than preparing a budget that can become totally invalid in the blink of an eye. 

The Agile methods of software development cost estimation approach time and money as static measures, while the product’s scope can change and evolve throughout the project. That is why the Agile cost estimation takes into account the scope of work to be done (size) and a team’s capacity to complete this work (velocity).

This approach to calculation of software project cost ensures that you get a value for every single dollar you invested in the project. However, how do you exactly decide what features to develop first? 

This question is easy to answer: set a simple priority list that has four categories: 

• Must Have. In this category, you include all features, without which development of your product is pointless. Just imagine what will happen, if you don’t develop these features at all. Will your solution be viable? Additionally, you need to develop features that ensure legal compliance and security of the software. 

• Should Have. This kind of features is also crucial to your product, but the solution will still be viable without them. These features may also require some extra work to be done and their development consumes time and resources necessary for musthaves, so they are developed as soon as the basic functionality is in place.   

• Could Have. These features are desirable but they are less important than those that belong to the Should Have category. Usually, such features are included in the best case scenario when both Must Have and Should Have features have been developed successfully and you have enough resources to work on additional features as a cherry on the pie.

• Won’t Have This Time. You don’t develop these features within the first iteration, but you can think about adding them later on when your product proves its value to users.

Estimation of the project’s size

When you estimate the size of your project, you need to look at its scope. What are you going to develop? Imagine you’re cooking a meal. What will it be: a bacon sandwich from a diner or a Michelin star filet mignon? 

Depending on the kind of solution you intend to develop, you can estimate the size of the work to be done. There are several simple, yet effective estimation techniques you can use:  

• Story points. This size estimation involves the user story tool ‚ a detailed description of a feature from the user’s perspective. Story points refer to a relative size of one user story to another. For instance, story A has one point, while story B has two points which means that it’s twice larger in size. The maximal score of one user story should be no more than 12 points.    

• Shared estimation. You get your development team together and you discuss how much time and money each phase of the software development life cycle will require (discovery, design, development and so on). This technique enables you to take into account all expenses necessary at each stage of the project, so that your budget plan doesn’t omit anything. 

• Analogue estimation. This technique requires you to take two user stories and decide which one is larger than the other by assigning a particular number of story points. For example, you decide that the smaller story is two points and the larger one is five points. Then, you compare the rest of functionality in relation to those two features you handpicked. 

• Planning poker. You don’t have to bluff and there is no flush or full house. What you need here is to cooperate with your team. You pick a feature, discuss it in detail, and then everybody plays a card with a story point written on it. In case your estimated story points are equal, you assign a relevant size. If not, keep playing the cards as many times as necessary to reach an agreement.   

Velocity

Velocity is a measure of a team’s capacity to complete a target size of work within the current iteration. There is no reliable data in the beginning, so forecasting velocity for the first iteration is a very rough estimate. 

To start with, you need to take all epics/user stories you chose for the first iteration, and divide them into individual tasks. Then, suggest time for every single task. 

The next step is to measure the team capacity. Say, you have a team of five tech workers and you plan to finish the first iteration within two weeks. You also need to set a baseline capacity of your team at the 70% out of all working hours available within this iteration. 

As a result, you get 5 members x 2 weeks x 40 working hours per week = 400 working hours. The baseline capacity will be 400 x 0.7 = 280 working hours for the whole iteration. 

With having the baseline capacity, you can start summing up all hours you assumed for each task as we mentioned above. You have to stop counting when you reach 280 hours as that’s the amount of work you defined you can perform within the first iteration. 

Convert the individual tasks back into full user stories and determine how many features you’ll be able to develop within 280 hours. Summarize the story points of those features to get the velocity estimate for your first iteration. 

You also need to calculate the 20% out of your velocity to determine the range. Let’s say you have a velocity of 100 story points. It means that your velocity range should start from 20 points less and 20 points more than 100. So, the range is between 80 and 120.  

Budget estimation by JatApp

JatApp always tries to serve the best interests of our customers, so we believe that a good cost estimate is the number one thing that satisfies the client and involves an acceptable level of risk. Our team performs software development cost estimation in two phases: cost approximation and precision. 

Cost approximation

The approximate estimation involves a shared approach that was mentioned earlier. The entire team gets together to discuss the size of the project in days and money range. 

The range is calculated for every type of tech specialists involved in the project: developers, designers, quality assurance experts, and so on. We calculate the range as follows: a number of specialists x number of months estimated x number of days x number of working hours x payment rate.  

However, approximate estimation can be too vague because a client might not have enough specifications about the product they would like to develop. For that reason, JatApp offers the customer to run a product discovery. This process helps to understand the current market situation and offer a product concept that will create the best value for the money invested. 

For instance, one of our customers from the US asked JatApp to build a product for the education sector. The entrepreneur didn’t have all the necessary details, just an idea, so JatApp initiated a product discovery and market research. 

We came up with a solution that presents an online tutoring marketplace where students can find tutoring help with a subject they want to improve. The product turned out to be profitable, as it gathered $500K in funding and currently has a rate 20% of annual growth rate. 

User interface of the online tutoring marketplace

A thorough product discovery helped to specify the product requirements and therefore plan the budget that allowed the development of the product valuable to the client’s business. 

Budget precision

As soon as the approximate estimation is finished and we have basic requirements to the product, the next phase of estimation comes up. At this point, we ask a customer to provide technical/business specifications and design requirements. 

We also negotiate a target deadline with a client to complete a project management triangle that includes size, money, and time. A good software price estimation should have a triangle with equal sides. It means that the costs are estimated in the most optimal way for reaching the maximal product quality. 

When our team has enough specifications and requirements, we divide the entire product into features to separately estimate time and money for each of them. In case the team has to work with a big complex feature, it is also divided into several user stories, development of which is estimated in hours. However, we may need additional specifications from the customer. Features that require extra clarifications are always estimated in days only.   

How we avoid cost overruns

As for keeping the project within the budget, our project managers tend to believe that a good estimate makes only 35% of the project’s success. Instead, the ability to handle changes on the go is much more important. 

The matter is that changing any feature takes more time and money than a customer may expect, even though the change is insignificant. In case a client requests a change, duration and costs are discussed separately as they will affect the whole budget. 

JatApp always discusses such issues with our clients before any changes are made, so you can be confident that we won’t deviate from the initial project plan without your approval. 

Why long-term planning matters

We encourage our clients to discuss with us their plans for the future as we need to know whether a customer intends to scale their business or not. 

Long-term plans of a customer are critical to the cost estimation process. If the customer doesn’t want to extend their product, we plan a monolithic architecture for the product, so it will be a static solution that can’t include any new features later on. 

Monolithic architecture

When the client confirms that they intend their company to grow, our project team starts working on a multi-service architecture for the product. 

Example of multi-service architecture

Development of a multi-service architecture is more expensive than monolithic one, but refactoring the entire solution from a monolithic architecture to a multi-service would make a hole in your budget. 

That is why we believe that it’s much better to assume a solid budget in the beginning. Having enough resources guarantees that the product will be in line with the client’s business strategy, while an attempt to cut costs will result in the resources shortage in the middle of the project. 

JatApp always pays much attention to risks

Our software project cost management also includes discussion of risks that a customer believes are applicable to their project. We take this information into account and plan the costs accordingly. 

If the customer wants a more detailed risk measurement, we provide a standard risk matrix to identify risks that are most concerning, so we can make relevant updates to the budget plan. 

Tips on keeping your project under the budget 

Even though you may be satisfied with how you approached estimation of costs on software development, you still have to be careful to keep your expenses within the budget. Here are some tips that are quite effective and easy to follow:  

• Understand your true business needs. When you know your business objectives, you’re more likely to invest money in development of the features that can really make your business grow and prosper. In such a way, you won’t regret a cent you paid for the product, as it creates a real value to your business.

• Create a baseline. Set an amount, beyond which you won’t go despite any circumstances. You may lose some additional opportunities, but your project will survive and you’ll have a chance to invest more money in scaling your product up. 

• Review your budget regularly. As your project makes progress, you may find out that your initial estimates are completely irrelevant. So, reviewing the budget from time to time and making corrections before it’s too late is a wise thing to do.  

• Plan in small portions. Don’t plan expenses for large components of the product as you miss many nuances that actually make up your budget. Instead, divide your product into small chunks to observe all hidden costs and have a realistic view of the project budget. 
• Develop a contingency plan. You have to be ready when your budget goes over the limit. It’s necessary to create a plan that involves decisions and actions to help you readjust the budget and regain control over expenses. No doubt, this recommendation makes you wonder: “How do I create this contingency plan?” No panic, we are prepared to answer this question as well. Let’s dive into details. 

What to do when you’re already beyond the budget

When you’re close to the budget overrun or already short of money:

• Throw away features that are not the most paramount to keep the costs down.
• Redefine a new budget and project expectations such as deadlines and deliverables.
• Check how other businesses handle similar situations. Perhaps, your team lacks some knowledge, skills, or capabilities that are important to the efficient use of money.  

Also, it’s crucial to know why the budget overrun happened, so ask yourself and your team the following questions:

• Did we have to make changes in the project scope?
• How did we communicate the role of the changes and how did all stakeholders understand them?
• Were there any unexpected problems our team was forced to deal with?
• What was the cause of these problems?
• How many tasks took longer than expected and what are the reasons?

Summary

IT project cost estimation is not just about saving money, but also focusing on the development of the product features that are most critical to its viability.  

Not everything depends on a human factor, so a total reliance on cost estimation is unreasonable. Instead, budget planning should stem from features you prefer to develop first, while resources are no object. Surprisingly enough, by following this approach you’ll save much more money compared to non-Agile cost estimation models. 

The Agile approach enables you to minimize a negative impact of uncertainties that seriously affect the cost of software today. At the same time, uncertainty negatively impacts trust, so you need an IT vendor that won’t make big promises about developing an one-of-a-kind product for almost nothing. 

In JatApp, we always set a budget in accordance with a customer’s preferences, but we never promise more than we can do. As a result, we managed to complete more than 200 projects for customers all over the world with 99% of satisfaction rate. If you want to start a project with a vetted software development agency, you just need to contact us. We will be glad to hear your ideas and offer our professional help.