Ins & Outs of Estimating Software Projects

What Is Software Development Estimation?

Success in a project hinges greatly on its accurate assessment. Estimating a software project is no small feat—it demands an understanding of every stage of the project, prior experience solving similar challenges, and proficiency in using relevant software tools.

Each development company approaches projects differently, so let us walk you through how we handle software development estimation here at Integra Sources. When a customer brings us an idea for a software product, their immediate concern is typically the duration and cost of development.

To begin with, the customer receives a rough estimate. While it may differ from the final cost, it gives them a general idea of the timeline and financial commitment required. Following this, our specialists dive deeper into the specifics of the project, creating a detailed table that outlines the minimum and maximum estimated hours for each stage.

This estimate always includes a range of minimum and maximum estimated hours. The range tends to be narrower for routine projects and wider for complex ones. The minimum number of hours reflects the ideal scenario where everything runs smoothly—though this rarely happens in real-world situations. The maximum number of hours accounts for time spent fixing bugs, finding optimal solutions, and addressing unforeseen challenges.

Beyond the project duration and cost, clients often inquire about the software tools that will be used, such as programming languages, libraries, and frameworks. A software app project estimate might also feature a portfolio showcasing apps created by the team along with app screenshots to demonstrate their UI/UX design prowess.

Additionally, project estimates may include team size if the client needs the work completed quickly or has strict deadlines to meet.

Software project evaluation depends on numerous factors. Here are just a few of them.

• Project Development Specification

For an accurate software development estimate, the team must fully grasp the objectives and scope of the project. The more detailed the client's requirements, the more precise the development team can be in estimating the project's timeline. All of the client's ideas and requirements regarding the software product are outlined in the project development specification. Clients can prepare this document in-house or delegate it to an outsourcing development team.

Certain project categories, like medical software and electronics development, necessitate extensive preparatory work. The client creates a discovery phase report containing a detailed product description, a proof-of-concept, software UI/UX design, and more. The team uses this report not only for initial project evaluation but also throughout development.

• Project Size and Complexity

The larger the project and the more tasks it entails, the harder it becomes to estimate its duration. Evaluating complex projects usually involves input from 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 significant challenges. A rough estimate will closely align with the final development cost.

On the other hand, estimating the development of an entirely unfamiliar software product is far more challenging because the team lacks prior experience with similar solutions.

• Software Team Skills

When developers are proficient in all the tools necessary for a given project (such as programming languages, libraries, frameworks, and development environments), they can more easily estimate the duration of each project stage since they fully understand the tasks at hand and can anticipate potential issues.

What Does a Project Estimate Consist of?

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

• Development hours;
• Hours for additional activities.

Let’s talk about the hours allocated for development. The team uses different criteria for software and hardware development estimates since the objects being evaluated are distinct. Software development can include application design, interface layout, database design, server software development, library creation, frontend and backend development, etc.

Electronics development may involve schematic and PCB design, PCB assembly, FPGA design, and embedded software development (often without an interface, so the embedded software estimate differs 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. This is essential for IT project estimation as it shows the project schedule to the customer and helps allocate work 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 even more, and increase with the project size. The larger the project, the more time is spent on these activities.

PCB and electronics testing can be performed in special laboratories if necessary, which increases 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 will depend on the electronic components used. If the task is to design a device and a mobile application for interacting with it, then the evaluations of the hardware and software parts can proceed in parallel.

Please note that changes in electronic component selection will inevitably affect embedded software, leading to increased development hours.

Estimation Techniques

There are many approaches to effectively estimating a software project and its critical parameters like 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 since the team doesn't have 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 engages 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 lacks experience with similar tasks. By working through all the development steps, programmers can find innovative ways to complete tasks more efficiently without sacrificing 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 conducting multiple rounds of anonymous task assessments. Team members discuss results between rounds and can revise their estimates. Ultimately, the team should reach the most accurate estimate.

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

T-shirt sizing is a method that categorizes project tasks based on size, similar to T-shirt sizes (XS, S, M, L, and XL). Everyone knows the approximate difference between XS and XL T-shirts, so developers intuitively grasp 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 instead 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 using poker cards. This technique minimizes the anchoring effect, where participants’ estimations are influenced by a previous judgment expressed by another team member (especially a respected one).

Each technique has its pros and cons, so you can combine holistic project estimation methods to enhance accuracy and reliability. Thus, the PERT estimating method is often used alongside analogous estimating or the top-down technique.

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

Techniques Our Experts Use

The Integra Sources team employs holistic project estimation approaches when evaluating software development. When starting a project, we rely on estimates from similar past projects and consider the expert opinions of the developers. We also use the 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 it down into smaller tasks and estimating how much time and effort each will take.

Sometimes, though less frequently, our team uses Scrum methods like T-shirt sizing and Planning poker to understand how quickly we can progress 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 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. Furthermore, 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 increase the likelihood of errors.

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 exceeds the budget in terms of time and cost, affecting its outcome and future cooperation. Exceeding 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 for the developers to fix the bugs caused by the rush.

The better safe than sorry principle isn’t always valid when it comes to project evaluation. Yes, the final estimate includes extra time to address possible difficulties and unexpected situations since no project is ideal. However, overestimating a project can scare away the customer, who naturally wants software developed faster and for less money.

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

Our development team initially conducted a rough estimate for electronics and embedded software development. There were some doubts about whether we fully understood the customer’s wishes and could 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 complex than expected, and the customer added new requirements. The new cost appeared too high for the customer, and he canceled the project.

The biggest lesson we learned from that unsuccessful project, early in our activities, is that we should evaluate projects as carefully as possible, clarifying all unclear points with the customer beforehand.

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 turn out to be 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 tool.

Such 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 often with software projects (e.g., app development) since the client’s wishes aren’t constrained by hardware limitations.

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

Conclusion

Accurately estimating software development duration and cost is no simple task. There are many factors to consider, including time for unforeseen events, logistical delays, and solving challenging tasks.

An incorrect project evaluation can lead to the loss of a project and a client. That’s why precisely estimating the time and effort put into development is 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.