Ins & Outs of Estimating Software Projects

What Is Software Development Estimation?

The success of a project hinges largely on its accurate assessment. Estimating a software project is challenging because it demands a comprehensive understanding of all stages of the project, prior experience in tackling similar tasks, and proficiency in using software tools.

Each development company follows its unique approach to project evaluation. Here at Integra Sources, we’ll walk you through how we evaluate software development projects.

When a customer approaches us with an idea for a software product, they naturally want to know the development timeline and cost. First, they receive a rough estimate, which might differ from the final cost but gives them an initial sense of how long the development will take and how much it will cost.

Following this, specialists dive deeper into the project details and create a detailed table that outlines the minimum and maximum estimated hours for each project stage.

The estimate always includes a range of minimum and maximum estimated hours. This range is typically smaller for routine projects and larger for complex ones.

The minimum number of hours assumes an ideal process where everything proceeds smoothly—something that rarely happens in real life. The maximum number of hours accounts for time needed for bug fixes, optimizing solutions, and addressing unforeseen challenges.

Besides project duration and cost, clients often inquire about the software tools that will be used to develop the program: programming languages, libraries, frameworks, and so on.

A software app project estimate may also include a portfolio showcasing apps created by the team along with app screenshots to demonstrate the team’s UI/UX design expertise.

Additionally, project estimates may include team size if the client requires strict deadlines or wants the work completed as quickly as possible.

Several factors influence software project evaluation. Here are just a few of them.

• Project development specification

To make accurate software development estimates, the team must fully grasp the project's objectives and scope. The more detailed the client’s requirements about the future software solution, the more precise the development team’s estimate will be.

All of the customer’s ideas and requirements regarding the software product are outlined in the project development specification. The client can prepare this document in-house or delegate it to an outsourcing development team.

Certain project categories, such as medical software and electronics development, necessitate extensive preparatory work. The client creates a discovery phase report containing a detailed product description, proof-of-concept, software UI/UX design, and other details. The team uses this report not only to evaluate the project but also throughout development.

• Project size and complexity

The larger the project and the more tasks it contains, the harder it becomes to estimate its duration. Complex project evaluations are usually handled by all team members involved in the development.

• Experience in developing similar software products

Evaluating a typical project (like Windows audio and video drivers) doesn’t take much time or present any major difficulties. A rough estimate will generally match the final development cost closely.

Estimating the development of a completely unfamiliar software product is far more challenging because the team lacks experience with similar solutions.

• Software team skills

If the software developers are proficient in all the necessary tools for the project (programming languages, libraries, frameworks, and development environments), it becomes much easier for them to estimate the duration of each project stage. They clearly understand all the tasks and can anticipate potential issues.

What Does a Project Estimate Consist of?

The hours allocated for a project can be split into two parts:

• development hours;
• hours of additional activities.

Let’s discuss the hours allocated for development. The team uses different criteria for software and hardware development estimates since the objects of evaluation are different.

Software development may involve application design, interface layout, database design, server software development, library creation, frontend and backend development, and more.

Electronics development may include schematic and PCB design, PCB assembly, FPGA design, and embedded software development (often without an interface, making the embedded software estimate different from the app estimate).

Development duration also includes the time required for electronic components (for hardware development) or the customer’s device (for software development) to arrive. Pauses caused by long component delivery and parallel development processes are clearly visible on a Gantt chart. It is essential for IT project estimation as it shows the project schedule to the customer and helps distribute the workload among developers.

The additional hours estimate has the same components for both software and hardware projects. It includes testing, debugging, preparing documents, project management, communication, and handover. Additional activities take up half the project time or more and increase with the project size. Larger projects require more time for these activities.

PCB and electronics testing can be conducted in special laboratories if necessary, increasing the number of testing hours.

The project budget may also include pre-certification activities.

When developing an electronic device and its embedded software, we first estimate the hardware development hours since the software part depends on the electronic components we’ll use. If the task is to design a device and a mobile application for communicating with it, then the evaluations of the hardware and software parts can proceed in parallel.

Please note that changes in electronic component selection will invariably affect embedded software, meaning development hours can increase significantly.

Estimation Techniques

There are numerous approaches to effectively estimating a software project and its critical parameters such as cost, scope, and time.

Analogous estimating is based on comparing the effort needed to complete a project with a similar project finished in the past. It works well for typical projects or stages where experts are confident in every development step. Analogous estimating saves time and resources as the team doesn’t need to evaluate each task from scratch.

Top-down estimating is a form of analogous estimating and is based on expert opinions.

Bottom-up estimating covers the entire scope of a project and involves calculating the cost and time for each task. This detailed approach involves all team members and focuses on the smallest details.

The bottom-up approach is ideal for non-standard projects or stages, especially when the team has no history of running similar tasks. By working through all the development steps, programmers can find innovative ways to complete a task in a shorter time without compromising quality.

Three-point estimating uses optimistic, pessimistic, and most likely scenarios to find an accurate project estimate.

There are two calculation formulas.

1. The triangular distribution is a weighted average of the optimistic estimate (o), the pessimistic estimate (p), and the most likely estimate (m).

2. The Beta distribution (or PERT) is a weighted average, with the most likely scenario given four times more weight than the optimistic and pessimistic estimates.

Generally, the PERT distribution yields a more accurate estimate than the triangular method.

The Wideband Delphi method is based on peer assessments of the time required to complete a task. The technique involves multiple rounds of anonymous task assessments followed by discussions between rounds. Team members can revise their estimates, ultimately reaching the most accurate estimate.

IT project estimation techniques can align with specific project management approaches. Agile project management (APM) emphasizes the team’s ability to quickly adapt to changing development requirements. APM uses flexible approaches to project evaluation.

T-shirt sizing is a method that categorizes project task sizes as if they were T-shirt sizes, such as XS, S, M, L, and XL. Everyone knows roughly the difference between T-shirts in XS and XL sizes. Similarly, developers are familiar with task sizes without needing to measure each one.

The T-shirt size technique implies that the development team doesn’t estimate the time required to complete a task or predict a specific deadline but rather compares the size of one part to the size of another.

Planning poker (or Scrum poker) is an estimation technique used in the Scrum management methodology. Projects are estimated with the help of poker cards. This technique minimizes the anchoring effect: when participants’ estimations are influenced by a judgment previously expressed by another team member (especially a reputable one).

Each technique has its pros and cons, so you can use holistic project estimation methods to achieve a high level of certainty and improve the reliability of the estimates. Thus, the PERT estimating method is often combined with analogous estimating or with the top-down technique.

You can mix methods for different stages of the project. For instance, the poker planning method can be used at the beginning when there is still uncertainty and insufficient information, while the three-point estimation technology can be applied later when all the necessary information has been collected.

Techniques Our Experts Use

The Integra Sources team uses holistic project estimation approaches when evaluating software development. When starting a project, we rely on estimates of similar past projects and consider the expert opinions of the developers. We also use a three-point technique to provide a detailed project duration and cost estimate.

If a project is complex or contains challenging tasks, we apply the bottom-up technique, breaking down the project into smaller tasks and estimating how much time and effort each task will take.

Sometimes, but not as often, our team uses scrum methods, like T-shirt sizing, Planning poker, etc., to understand how quickly we can move through development stages and how we can optimize processes.

Who Makes Software Project Budgeting?

The project manager is responsible for software project planning. The PM adds all the necessary additional activity hours to the project estimate. Depending on the IT project estimation technique chosen, different specialists may be responsible for estimating development hours.

At Integra Sources, the project is evaluated by technical leads and developers. Moreover, the CTO always validates the final project estimate before sending it to the customer.

Software Project Estimate Issues

First, the effort spent on estimation depends on the project itself. Large, complex, and unique projects make estimation more difficult and errors more likely to occur.

According to statistics, poor estimates during project planning are one of the most common causes of project failure.

What does underestimating a project lead to?

• The project goes far beyond the budget in terms of time and cost, affecting its results and future cooperation. Exceeding the budget rates leads to misunderstandings and disputes. The team and the customer spend even more time trying to figure out what went wrong.

• Software product quality may suffer due to haste caused by deviations from the schedule. As a result, the customer either receives a solution with many shortcomings or has to wait longer until the developers fix the bugs caused by the rush.

The better safe than sorry principle isn’t always true when it comes to project evaluation. Yes, the final estimate includes additional time to address possible difficulties and unexpected situations since there are no ideal projects. However, an overestimated project can deter the customer, who naturally desires software to be developed faster and for less money.

An incorrect assessment has ruined more than one project, and, unfortunately, we have had such experiences ourselves.

Our development team conducted a rough estimate of electronics and embedded software development. There were some doubts about whether we correctly understood the customer’s wishes and would be able to implement the project. We advised the client to conduct pre-project preparation and write a thorough requirement document.

After carefully studying the specification document, our developers increased the estimate by 1.5 times since the project turned out to be more complicated than we expected, and the customer added new requirements. The new cost appeared too high for the customer, and he stopped the project.

The biggest lesson we learned from that unsuccessful project many years ago, at the very beginning of our activities, is that we should evaluate projects as carefully as possible, clarifying in advance all unclear moments with the customer.

Another thing that can scare customers away is when estimates change too much.

Why Might the Estimate Change?

Fluctuations in project estimates can occur for many reasons. Here are the most common ones:

• Software developers misunderstood the customer's wishes.

This often happens due to a poorly drafted requirements document or when there is no document and all the requirements are explained verbally.

High-quality pre-project work and a thorough specification can minimize the risks of incorrect project estimates.

• The task took longer than planned.

Some development stages may prove more difficult than initially expected, or there may be many nuances, for example, when developing medical solutions. Programmers may spend more time when they lack expertise in a specific programming language or software tools.

These moments are difficult to avoid or predict, and a competent estimate of software development should include additional hours for challenging tasks and unforeseen circumstances.

• The customer wanted to make changes to the electronics functionality or add new software features.

This happens most frequently in software projects (e.g., app development) since the client’s wishes aren’t limited by the hardware architecture’s capabilities.

Keep in mind that even seemingly small changes in software design or functionality can result in a large number of additional development hours.

Conclusion

Accurately estimating software development duration and cost isn’t an easy task. There are many things to consider, including time for force majeure, logistical delays, and finding solutions to challenging tasks.

Incorrect project evaluation can cause the loss of a project and a client. That’s why precisely estimating the time and effort put into development is so crucial. Diverse development experience and mastery of various project evaluation methods will help the outsourcing team achieve accurate budgeting. Tell us your ideas, and we’ll estimate how long it will take to put them into practice and how much it will cost.