IT Project Cost Estimation – an Overview Of How to Do It Right

Quoting the final price of a project that doesn’t exist sounds like trying to predict the future. So how do you know that the IT project cost estimation is done the right way? 

As project cost estimation comes with risks that might bring unexpected costs, it needs to be based on deep analysis of the project, related data, technology, team velocity, and many other factors. 

There are various techniques for calculating the cost of software development. This article will show you how we do it at Studio Software. 

The accuracy of project cost estimation

The more details we have from you, the easier it is to calculate your software development costs and hours. Our experience shows that clients usually aren’t clear about the requirements when they ask us for an estimation of the cost of their projects. 

We draw a quotation based on our framework, but besides standard indicators we also include two things that matter for precise estimation.

1. The first one is an assessment of the specifications you deliver to us. We use a 3-point scale. 3 is for top project specifications that make us fully understand your problems, needs, and expectations, while 1 is for specifications that lack details.
2. Another one is prediction of how precise and accurate is the project estimation. Here we also use a scale from 1 to 3 and the outcome is based on what you provided and how complex is the project. Then we operate based on our experience, so we take previous similar projects with their cost and time data to estimate your project.

And what about projects that we’ve never done before? We estimate the features based on our expertise, define the scope of work, and the technology that will have to be used. Then we can estimate the time we need to build such solution. 

Our figures come with notes, so you always know why they have a low or high rating. Overall, it all depends on the quality of information we have from you, so we need fully outlined requirements for more precise estimates. If we get napkin notes, you can’t expect exact pricing. 

So before we create any cost estimate and detailed budget we organize a discovery call to gather key project information. Specific questions help us get deeper knowledge of your project’s scope, timeframe, and expected outcome. 

Backend and frontend developers take part in the entire valuation process (as they can evaluate accurately based on their experience), and then they ask another technical person to verify their estimations. 

When we’re provided with all the details, we can draw up final estimates. This is why we use an Excel file to keep it all crystal clear so that you can see what the exact numbers mean. 

Cost estimation — what to expect from your potential technology partner

It’s worth mentioning that you should expect a ballpark estimate rather than an accurate final price. It’s because most of the features can be interpreted in various ways, especially at the beginning when the project details are only on paper. 

Keep in mind that features that seem easy to you can be complex to create and may require hours of coding.

The process is called estimation, not exactimation.

Phillip G. Armour

It’s about predicting the resources, so these are not only the technology costs, but also time and people. Many other factors affect the final price as well, such as the time for architecture planning, bug fixing, project management, meetings, etc., so you need to determine whether the estimation is to include the following things: 

• Manual or automated unit testing. You need to agree with a software house what % of total project time should be allocated to QA. 
• Project management. Is it included in your project? Note that it usually takes 10-15% of the budget. 
• Team meetings. They are important to keep everyone involved in the project on the same page. It takes time to set all the details, so meetings can take up to 10%. 
• And what about setting up new environments, making project analyses, deployment, etc.? They come with extra money for the project too. 
• Nonfunctional requirements for the project. If there are such requirements, they need to be agreed before we start the valuation. Do we need to run a load test to find problems before they impact users? Perhaps you want your application to automatically scale depending on its needs. Load balancing traffic requires adding more servers, so then we need to use relevant solutions that also cost money. The same goes for third-party requirements, etc. 

Before providing the final estimation we also need to know whether the project requires unfamiliar technologies. We analyze potential risks and issues. You will receive a custom estimate created after all the thorough research. 

Of course, we want to know your terms and budget restrictions, but the scope of a project should determine its budget. If it’s done the other way, it may lead to a project that doesn’t meet requirements. 

So if a software house gives you the exact price, it should set off alarm bells in your head. The same should apply if you’re only provided with the price for features mentioned in your project description. Giving a fixed price without in-depth analysis of the project, a number of calls, and a kickoff meeting is impossible. What you should get is range value. 

Be aware of underestimation

One of the most challenging things during cost estimation is to strike a balance between over- and underestimating. IT projects tend to be underestimated and it doesn’t impact only costs. It’s also related to time or technical complexity. PMI’s 2018 findings show that only 57% of projects are finished within their initial budgets. 

It’s no secret that underestimation of IT project costs is a common mistake made by agencies and it is a problem occurring on a larger scale. It’s mostly because of underestimating features that look easy to develop, but require hours of development, known as SMOP (small matter of programming). 

This is why we put such emphasis on asking probing questions during a discovery call to get as many detailed answers from you as possible. This ensures that every estimation is near the final price. 

And guess what? Every time we are about to make a IT project cost estimation, Hofstadter’s law springs to mind: 

Hofstadter’s Law: It always takes longer than you expect, even when you take Hofstadter’s Law into account.

Project cost estimation is easier said than done

The exact specification is essential to reduce development costs. This is why the evaluation should always be preceded by thorough research based on key project information gathered during meetings. All of them help to evaluate work hours, product complexity, team commitment, technology, and more. 

Big projects that come with a number of variables and functionalities require a detailed roadmap. Hence you shouldn’t expect to get an exact price. But if you get an estimation, it will help you decide whether the project will be feasible. 

If you need a free quotation for your IT project, drop us a line at hello@studiosoftware.com. We’re always happy to help!