How to Estimate Software Development: Factors, Roadblocks, and Success Tips

Imagine what our life would be like if we all followed the flow and never planned ahead. This would be a world of chaos where decisions are made on the fly, and nobody quite knows what outcomes to expect. Now, apply this scenario to the world of software development, and you have a recipe for projects that go over budget, are overdue, and fail to deliver. 

How many IT projects do you think fail due to poor estimates? We bet you’d be surprised to know that this number is as high as 70%. These statistics don’t look inspiring but don’t be discouraged. Once you master the art of estimating the cost, time, and effort of software development, you’ll set yourself up for success. 

What Is Estimation in Software Development?

Let’s start by understanding what estimation means in terms of software development and why it is so important. In layman’s terms, software development estimation is the process of predicting the most realistic amount of effort, expressed in terms of hours, days, or weeks, required to build a piece of software. In some sense, it’s a guess but one that’s based on a variety of factors, including past experience, technical difficulty and requirements of the software, and resource availability. 

Reasons for Software Development Estimation

Accurate estimation is important for IT projects for a number of reasons. Let’s go over the most important of them.

Estimation Gives You Clarity

When a client comes to a software development company with a project, it’s important to bring everyone on the same page about what needs to be done. When the outsourcing company you’ve hired goes through your software requirements, user stories, and any other documentation you provided, their experts, both business and technical, form independent conclusions about the project time, its complexity, and the effort required to complete it. 

Sometimes, team members will have different perspectives on the problem and how to solve it. Their implementation ideas can be far apart, and the project development approaches they propose may differ from one another. 

For example, a software architect may propose adjustments to your tech stack or offer to use a tool that would drastically improve the quality of your product or speed up the delivery process. This may lead to a somewhat lower estimate for the project. At the same time, a business analyst may identify a serious pitfall in your project documentation or insist on adding a crucial feature others have forgotten about, which may lead to a considerably higher estimate.

When team members provide you with a whole range of different options on how to optimize the development process or the solution itself, these independent conclusions give you a lot of crucial information for further planning and accurate low-level estimation of the project. This means your vendor won’t miss any important signals and will be well-prepared for any turn of events during the actual development phase.

Estimation Helps You Manage Trade-Offs 

If you’re running short on cost and time in the course of development, you will most definitely have to make sacrifices, be it the functional features of your software product or its quality requirements. From serious maintenance and extension issues to a complete failure of your software solution, these trade-offs may lead to a whole variety of problems you don’t want to deal with. That’s what the software development estimation process can save you from before it’s too late.

The estimation process allows your development team to refine your project requirements and adjust the course of action before the actual work begins—before the team runs into any unexpected complications or blockers that would put your project at risk. Such thorough analysis of the project scope helps your vendor identify issues and prepare a baseline to effectively tackle them: adjust the scope, increase the time required for software development, etc.

Requirements analysis in the course of the software development estimation process helps you better manage trade-offs on complex projects. An accurate estimate, whether it is lower or higher than you expected, raises important discussions on the scope of the project. It enables you to: 

• rethink the set of features you planned for your software solution;
• prioritize tasks more effectively;
• identify and give way to a critical component that was buried somewhere deep among the less important ones;
• scale back your solution to improve your time to market and take advantage of several quick wins.

The estimation phase is the best time for you to raise discussions on scoping and adjustments if you want to keep the project within the allocated budget and time frame.

Estimation Saves You From Getting Lowballed

When your cost and time estimates are significantly off, you essentially kill the project before it even starts. And let’s face it, no one normally overestimates the amount of work to be done—it’s the underestimates that may become the nail in the coffin of your project. A bad estimate is a pitfall you will find extremely hard to deal with the deeper you are into the development phase.

As we mentioned before, an underestimate may serve as a means of deception that a dishonest outsourcing vendor is using to hook you with a lower price tag. However, it may also be the planning fallacy so common in today’s fast-paced digital world. After all, people do tend to underestimate the time needed for a lot of things, from simple chores like cooking breakfast to responsibilities such as implementing a software development project. Another possible cause of underestimation may very well be the aggressive goals you’ve set in the hopes of pushing better productivity or achieving a faster time to market. And the next thing you know, your overly ambitious goals backfire and are rapidly dragging your entire project down.

When forced to finish the project on time and within the allocated budget, your development team takes shortcuts, sacrificing features and letting a whole myriad of bugs and errors infest your code. The quality and scalability of the underlying architecture may also be put at risk when rushing to meet a deadline. Suddenly, your software solution is not nearly as polished as expected, and a lot of work is deemed “non-essential” as you’re trying to avoid the financial burden of accumulating even more technical debt. Future extension is slowed down as your vendor is locked in the repeating cycle of fixing bugs and other quality issues.

Code quality requires a lot more work than you normally expect, and it should never be underestimated in the planning phase. Otherwise, you’ll be stuck dealing with functional and non-functional issues for a long, long time. You may not just end up late and significantly over-budget with your release, but the project may turn out such a failure that its future wouldn’t even be worth fighting for. To avoid underestimation and get the quality you’re aiming for, there is a wide range of estimation methods to help you plan software development ahead, which we’ll discuss later in the article.

Estimation Challenges

Now, let’s consider the main roadblocks that may stand in the way of accurate estimation. Understanding the challenges that other founders typically run into can help you be more prepared. 

1. Lack of Clarity

According to statistics, one of the primary causes leading to 35% of product failures is a lack of clarity in the requirement-gathering stage. Unfortunately, not all founders understand the importance of the initial stage and give developers just a brief description of the app they want. 

Quite often, this sounds like this: “I want an app like WhatsApp.” Naturally, this approach is doomed to lead to misunderstandings. Even if developers try to estimate this project, which many developer shops will do — you can be sure the time estimation for software creation won’t be right.

2. Project Complexity

Software products aren’t created equal. Some can be rather simple, while others rely on complex technologies, API integrations, or third-party services taking longer to implement. Therefore, it’s a good practice to attract business analysts. They can bring a critical eye to the planning process, helping identify potential complexities and areas where you may need to allocate additional resources and time. 

3. Changing Requirements

In an ideal world, software requirements shouldn’t change much once they’ve been discussed and agreed upon with the vendor, but this always doesn’t work that way. As your project progresses, you may think about adding a new feature or technology. And if you spend all your available resources early in the SDLC, implementing those changes will put a strain on the software development budget. Never forget that development is a dynamic process, and it’s best to leave some wiggle room, both in time and money, to adapt. 

4. Time Constraints

The speed of product release is an important factor in the software’s success, and founders often put rather strict deadlines on projects. The problem is they don’t factor in unexpected complexities that may arise during the development process, leading to rushed work, compromised quality, and potential team’s burnout. 

To avoid this mistake, ensure that you have realistic expectations from the start, understand the scope of your project, and recognize the capabilities and limitations of your team. A great formula you can find on Quora goes like this: “Make your best estimate and multiply it with the Pi factor”.

Generally, a basic application without advanced features typically requires around 800 hours of development time, which translates to about 4-6 months of work. Conversely, a more complex project can easily take upwards of 1200 hours to complete, often stretching the timeline to a year or more. These are the average numbers, they  vary depending on the size of the software solution, the team’s skills and expertise, and the required integrations. 

Which Estimation Is Good?

The hallmark of a good estimation is its accuracy, which is typically defined by an error margin of 5 to 10%. As you can see, there isn’t much room for error, making the estimation phase of a software development life cycle (SDLC) the most important of all. However, the time spent on software estimation will certainly not be wasted, as you’ll increase the chance of producing a better quality product that won’t fail. 

Different Aspects of Software Estimation

Software estimation encompasses several interrelated aspects, each critical to the project’s success, including:

• Software development time estimation;
• Software development effort estimation;
• Software development cost estimation. 

We’ll elaborate on each of these below, giving you a better understanding of the methods and techniques that are best used to create accurate forecasts. For now, let’s just say that they are equally important, and without each of them, it’d be impossible to get a clear and accurate picture of the future project. 

View all

Odoo Development For An Insurance Company

Developing an Odoo solution for an insurance company that wants to streamline the processes for its partners and make sure that insurance calculations are quick, precise, and fault-free.

Read more

Loan Management System For Thrift Plus 1

Developing a web app for quick and easy loan management that can synchronize data across different servers and financial institutions and is based on our previously developed solution.

Read more

BIM Content Configurator Development

Creating a BIM content configurator that enables you to build entire assemblies and download your creations to popular design tools, complete with cut sheets, specs, and other product data.

Read more

Software Development Time Estimation

Software development time estimation, just as the name suggests, is the process of determining how long it will take to complete the project. This process involves gathering and analyzing the project’s requirements, then breaking them into small, manageable tasks, and then distributing them among the team. 

Predicting the software time frame isn’t always a straightforward process. First, you may work on long-term projects where specifications change over time. Secondly, no one is guaranteed against unforeseen problems that may get in the way of the development process, leading to delays, missed deadlines, and lost revenue. Therefore, it’s necessary to approach time estimation with caution, factoring in multiple variables. 

How to Measure an Effort in a Software Development Process?

Software development effort estimating is typically measured in man-hours, man-days, man-weeks, or man-months and is performed once the scope and goals of the project have been determined. Precise estimation helps make sure your team isn’t overwhelmed and no one is left behind, as is often the case with traditional settings where internal testing teams may sit idly waiting for tasks. More importantly, it allows you to better plan the time and cost required for the project completion, preventing resource leakage. 

What Is Cost Estimation?

Software project cost estimation is a crucial step, particularly in outsourcing. When done right, it creates a solid foundation for all of the subsequent decision-making efforts and management stages and helps avoid any ambiguity or false assumptions that could jeopardize your entire project.  

Software Development Estimation Tools

Estimating the cost, time, and effort of building a software solution can be extremely difficult without external help. Even experienced project managers with hundreds of completed projects behind their backs may struggle to provide accurate estimates. Hence, the use of specialized software development estimation tools becomes essential. Below, we break down the most popular tools used by vendors to estimate software development time and enhance the accuracy of their forecasts. 

• Project management software. Tools like JIRA, Trello, or Microsoft Project offer functionalities that help in breaking down projects into tasks, assigning timelines, and tracking progress. The great thing about them is that they also include features for estimating time and effort, making it possible to anticipate the outcome based on task complexity and team capacity. 
• Cost estimate software. These tools focus on calculating the financial aspects of a project. They can include features for budgeting, forecasting, and financial analysis, giving you a clear picture of the financial health of your project. 
• Effort estimation tools. Tools like Planning Poker or COCOMO II are used to estimate the effort required for software development. They often employ various estimation methodologies to provide a more accurate effort forecast. 

It’s important to note that while these tools can aid in estimating the development process, they shouldn’t be viewed as a substitute for human judgment and experience. The most effective approach often involves combining the use of these tools with the insights derived from brainstorming every specific task. 

Key Estimating Software Development Factors

Now, let’s consider the key factors that affect the precision and quality of a software development project estimate:

Project Scope and Deliverables

This means a detailed breakdown of what each service your vendor will provide on the project entails. This includes design, development, testing, deployment, and maintenance combined or as separate tasks/stages depending on a particular work order. When you have all the specific goals, tasks, and deliverables well documented, it helps you avoid any confusion and disputes on the project. You will know exactly the range of services your vendor is obliged to cover for the agreed reward and what things will most likely come at an extra fee.

Resources

The biggest price component in project cost estimation in software development outsourcing will always be person-hours—the number of specialists and the effort needed to complete each task or activity in the course of a project. The number of hours required to deliver the project will mainly depend on the skills and experience of the engineers and managers involved in the process. Therefore, it’s crucial to make sure that the vendor you hired for the job has a clear understanding of the scope of your project so that they can provide you with an accurate cost-to-time ratio. They must also pay attention to the required skill level (junior, middle, senior) to allocate people as efficiently as possible. This is especially important for long-term projects.

“For example, it would take 15 hours for a senior engineer to complete a particular task, while a middle developer would be able to carry out the same work in about 18 hours. Yes, a senior engineer would complete a task slightly faster. However, given that their time costs nearly twice as much as that of a middle developer, hiring a senior engineer for a small, simple project that a middle could easily handle might be an overkill.”

Roman Lyha, Head of PMO at QArea

---

Roman continues:

“On the other hand, when we’re talking about large projects that rely on complex software architecture, you absolutely must entrust building one to the most experienced and skilled engineers in order to ensure that you have a high-quality foundation for further development and encounter no blockers along the way.”

Person-hours is not the only component of an estimate. There are other expenses that usually make up no more than 10% of the budget. This includes:

• reusable software components (e.g., third-party APIs, libraries, frameworks, etc.)
• equipment (custom hardware, server equipment, IoT devices, etc.)
• third-party services (hosting, on-demand computer system resources, platform fees, etc.)
• accounts and licenses (Google Play or App Store accounts, validation services, industry-related licenses and accreditations, etc.)

Let us help you assemble a team with the skills and domain expertise that suit your goals best

Contact us

Tell us about your project.

We’ll send back CVs and get in touch to learn more about your project.

Name*

Email*

Project Description*

I agree to the QArea Cookie Policy and Privacy Policy*

[email protected]
+1 310 388 93 34

Δ

Thank you!

We’ll be sending you some CVs within two business days.

 Timeline

As part of a project plan, a timeline serves as a concise representation of the steps required to complete each piece of work. It shows the project duration in days, weeks, months (sometimes even years) to give you a high-level understanding of the time your vendor needs to complete the project. Timeline highlights every important dependency, milestone, and deliverable. It shows the time each phase is scheduled to begin and end, as well as the team members involved in each stage.

It is important to point out that the estimated person-hours and the estimated timeline are two drastically different things.

“The important difference is that person hours represent the total time a specialist will dedicate to the project, while a timeline breaks this time into phases. Say, an engineer needs 20 hours total to complete a task, but in fact, it will take them two weeks as their involvement in the completion of the task will depend on other people’s work through different phases.”

Roman Lyha, Head of PMO at QArea

---

Risks

In project management, a risk is any unexpected event that could jeopardize the timely and on-budget delivery of your software product. As one of the key factors to project success, risk assessment plays an important role in project cost estimation.

Assessment of potential risks can be broken down into three stages: 

1. Predicting the events or conditions that may occur in the course of software delivery.
2. The likelihood of their occurrence.
3. The impact they may have on your project.

Beware of outsourcing vendors that are overly optimistic in assessing the risks of your project. In the hopes of enticing you with a lower price tag, they may ignore potential issues and the long-term consequences these issues can have on your project. And remember that even the most experienced software engineers can’t guarantee that your project won’t face any blockers. So go with a software development company that provides you with realistic risk analysis and a percentage of contingency built into an estimate.

The more accurate the risk assessment is, the better prepared your project will be to deal with potential issues. This also means that your vendor will be able to build stronger risk management plans and lower the likelihood and impact of unfavorable events and conditions with efficient mitigation strategies.

Project Estimation Approaches and Techniques

There are so many software development projects, each with different requirements, goals, and conditions, that there is no single, perfect way to accurately estimate them. But it’s your vendor’s job to analyze your project documentation and find what development approaches and technologies suit your project goals best. As such, your vendor may have to apply a whole range of different techniques to estimate the project adequately.

Further down, we’ll share with you the most common software project estimation techniques companies use to gauge the cost, time, and effort required to complete the project based on the project management methodologies. 

Traditional Approach

While the Waterfall Model is far from being perfect, its main strength is that it doesn’t imply evolving requirements. In this model, the vendor breaks the project into a number of tasks under the Work Breakdown Structure (WBS) and then estimates the time and resources needed for each of them. At this stage, they may use the following techniques:

Analogous (Comparative) Estimation

As a combination of expert judgment and historical data analysis, estimation by analogy requires your vendor to involve experienced specialists to produce an accurate output. The scope, resources, deliverables, timeline, and risks of similar projects are reviewed and compared to what you have in mind with your project—the more similarities, the better. When the best analogy is found, and the possible differences are analyzed and considered, the resulting cost estimation should be fairly accurate.

The comparative estimation approach is preferable when the information you possess about the project is limited. These high-level estimates usually take no longer than a couple of days to pull together and serve as a good tool to make sure everyone is on the same page before either you or the software development company you’re about to hire invests any more time into further project planning. It’s worth mentioning that for analogous estimation to be accurate, your vendor must have many years of experience and a pretty solid portfolio.

Delphi Technique 

When decisions need to be made quickly, the Delphi technique comes into play. This method is particularly popular in situations when the project comes with lots of uncertainties and/or a lack of derivables. The main principle of the Delphi technique is that decisions are made by experts involved in the project from the outside. They all evaluate the project and then share their vision based on their hands-on experience and expertise. 

The only downside of this approach is that it’s easy to make wrong decisions if the participants invited don’t have a deep understanding of the nature of the project and give you just generalized advice. Therefore, it’s highly important to ensure that the vendor you choose attracts experts with extensive niche expertise.

“Expert judgment means that we involve a niche specialist with broad experience in a particular area to help us with the estimates. They will either do the job themselves or refine the estimates developed by a different specialist who is possibly not as experienced in the relevant tech or business domain.”

Roman Lyha, Head of PMO at QArea

Agile Software Estimation Techniques

Three-Point Estimation

When it comes to agile methodologies, the safest and best way to estimate the time, effort, and cost of a software development project today is the three-point estimation technique. Rather than assuming one estimate, software development companies use this estimation technique to calculate the most optimistic and pessimistic values that are then averaged to determine the most likely cost of a project. Thus, we get three points:

• optimistic estimate;
• pessimistic estimate;
• most likely estimate.

As you have probably figured out, the optimistic estimate is your best possible outcome that represents the expected amount of effort, time, and money required to complete a project, assuming there will be no blockers or unfavorable events hindering the delivery process. 

Then, there’s a pessimistic estimate—the worst-case scenario that takes into account all the possible risks that might affect the delivery process and result in cost escalation. 

By calculating the average between these two extreme points, we get a somewhat realistic estimate. This would be called the triangular distribution of three-point estimates—an ideal solution for estimating small, simple projects where there is no reason to dig deeper. 

However, this may not be the best case for complex, large-scale, and enterprise-level projects where you need to be more thorough with risk assessment and really tighten the most likely estimate. In this case, the project should use PERT estimation.

PERT (Program Evaluation and Review Technique)

The PERT distribution of three-point estimates implies overweighting the most likely estimate to convert a simpler triangular three-point curve into a bell-shaped one. The PERT method provides you with a better, more accurate means of estimating probabilities of ranges of expected values. 

It’s also advisable for complex projects to go the extra mile and enhance the precision of your software development cost estimation with other task-level techniques such as expert judgment, analogous estimation, and parametric estimation.

Parametric Estimation

Both parametric and analogous development time estimation techniques use historical data to produce estimates. The parametric method, however, requires a higher effort upfront and is often perceived as a more accurate alternative to the analogous method. What makes a substantial difference between the two is the process each of the approaches uses to perform the calculations.

While in the analogous approach, your vendor would simply compare and adjust values from past projects with a similar scope, parametric estimation provides an additional estimation layer on top of that using a set of algorithms. It applies a statistical or mathematical approach to the historical data your vendor has collected—uses the relationship between variables (i.e., unit cost/duration and number of units) from similar projects and applies them to the one at hand to estimate the cost, duration, and effort needed. 

Simply put, this is how it works:

1. The team pinpoints the units based on project requirements, complexity, tech, and other variables from similar projects with consideration of the scale differences.
2. The data on the required effort/cost/time to complete one relevant unit is then calculated against the total number of such units in the current project.
3. The estimates are derived from the empirical relationship between the relevant unit rates and the total number of such units.

Top-Down Approach

The top-down approach is a project-level estimation technique that uses known data points and specific parameters to first establish the scope/cost/duration of the entire project and then apportion this data into individual tasks and deliverables using the task-level techniques listed above. It is generally restricted to projects where your vendor deals with a predetermined project budget and/or duration.

For example, you have determined the budget in advance and set a strict deadline for the project. Using the top-down approach, your vendor will take these parameters and break them down into the effort, time, and cost estimates for each activity within the project. They will analyze the impact on project complexity and see how realistic the project scope is against the given time and budget constraints. If the matter is open to debate, your vendor will offer a range of solutions to how they could adjust and optimize the scope to make the project viable (in case it isn’t).

Similar to the analogous technique, this rough approach is mostly used for the initial stage of project cost estimation to see if the project can be implemented within the given parameters. It also helps with strategic decision-making in situations where the information on the project is insufficient, or the requirements are still floating.

Bottom-Up Approach

The exact opposite of the top-down approach (as you have already guessed), the bottom-up estimation approximates the cost, duration, and resource requirements of the project at a very granular level. This technique involves working your way up from estimating individual low-level activities and work packages to phases and deliverables to, eventually, rolling these up into overall project estimates.

Bottom-up estimation is significantly more accurate, but the trade-off is that it is a lot more time-consuming than the top-down approach. This is because your vendor has to gradually collect the smallest pieces of information into a whole and thoroughly estimate each and every one of them to get a good understanding of the big picture at play.

The level of detail available for estimation will highly depend on the maturity of the project and the quality of documentation you provide to your trusted software development partner. Therefore, it’s probably the wrong path for immature projects with little information and floating requirements.

Software Development Estimation Process Step by Step

Clients come to us with all kinds of different requests we need to thoroughly analyze and provide accurate estimates for in order to get a green light for the delivery phase. Considering the variety of requests we get and the broad range of services our company provides, every project requires a unique approach and has a different life cycle.

Some clients come to us with defined and well-documented requirements that make it very easy for us to estimate the project and get on the same page without any additional discussions. Some submit requests with mere vision boards or references to apps and websites, saying that they want their solution to be “something like that.” And then there are clients that seek our help in fixing the mess some other company did on their project.

So, knowing the algorithms and understanding the software development estimation techniques is one thing, but it’s the experience and mature estimation processes honed over years that distinguish the good from the best. Now, let’s break down the software development estimation process and walk through it step by step.

Pre-Sale Phase

It all begins when you submit your request to us. Our account manager responds within a day, and we normally start our relationship by signing an NDA in accordance with the information security standards our company follows. Then, we send you a project template to fill out so that we can get a better understanding of the product you want to create and determine whether the information is sufficient for our team to start working on high-level estimates. In addition to requirements that may vary in quality and level of detail, you can also share the budget, deadline, preferred collaboration model, maturity/stage of the project, and other information that could help us provide accurate estimates.

Following the greets and meets and all the request processing procedures, a delivery manager is assigned to the project. They carefully analyze the information you provide and decide whether it is sufficient for high-level estimation. There can be two different scenarios. If the information you provided is enough for us to start working on estimations, we do so without delay. In case there’s any ambiguity in the provided documentation, or we require more details to provide an accurate project cost estimate, we prepare a concise and well-structured list of questions, followed by one or several calls to clear things out.

“In addition to an account manager and delivery manager, a software architect, business analyst, or any other specialist with relevant niche skills and domain expertise may also be invited to the call. Thus, we make sure no issue is left unattended.”

Nikolai Pivovarov, Delivery Director at QArea

With every issue discussed and settled, we move on to the actual software development cost estimation process.

High-Level Estimation and Resource Analysis

With sufficient information on the project, the assigned delivery manager can start coordinating with our software architecture team to look at what architectural choices and options we’ve got. Sometimes, they are dictated by you and your stakeholders, depending on the stage of development and your current or preferred tech stack. In this case, the assigned software architect can immediately start working on software development estimation. Alternatively, you may choose for us to provide suggestions and tech solutions most suitable to your project goals. When that is the case, the software architect decides on the appropriate tech stacks and development approaches. They also suggest potential people within the company it would be logical to involve in order to provide an appropriate estimate.

To make sure that the right people are made available to do the estimates, the delivery manager and software architect will liaise with our resource managers. Our HR department will then provide a list of available specialists who possess the required professional skills, domain knowledge, and experience. Together with the software architect, the delivery manager will assemble a team of best-fitting candidates and finalize the high-level estimates. 

Finally, the resource, cost, and project duration estimates are validated by the delivery director and sent to you for approval. The high-level estimation process takes one day in person-hours for small and medium projects and two days for large projects. The timeline for the estimation shouldn’t be longer than one week, regardless of the scope and complexity of the project.

As a result of high-level estimation, the client receives two documents:

Proposal

Not to be confused with RFP (Request for Proposal), this document represents the way we see the project, how we plan to implement it, and by what means. It walks you through the tech solutions and business approaches we’ve chosen for the implementation of your project. Depending on the project, a proposal document may include information such as:

• project scope;
• project management plan;
• key deliverables;
• timeframes and milestones;
• required access to environments;
• required third-party components and/or services;
• known risks, assumptions, and mitigation strategies;
• portfolio with relevant case studies.

High-Level Estimate

The estimation document is broken down into tasks, deliverables, and their descriptions, followed by the expected time required to complete each task, the hourly rates of resources assigned, and finally, the costs of each and every phase and deliverable. 

“Following the industry-best standards and our years of experience in the market, we have refined our templates to make them as concise and easy to understand as possible. We often receive positive feedback from our clients on how on-point and clear our proposal and estimation documents are.”

Nikolai Pivovarov, Delivery Director at QArea

After you have received and studied these two documents, we arrange a call to get feedback and discuss further action. Our next step essentially depends on the scope and complexity of the project. If it’s a small and simple app/website we’re talking about, we can skip the discovery phase, sign the contract, and go straight into the delivery phase. On a large-scale project, however, especially the one with documentation that doesn’t inspire much confidence, we always insist on a thorough discovery phase.

Share with us the project cost estimation challenges you’re facing, and we’ll connect with you an expert best equipped to help you solve them

Schedule a call

Tell us about your project.

We’ll send back CVs and get in touch to learn more about your project.

Name*

Email*

Project Description*

I agree to the QArea Cookie Policy and Privacy Policy*

[email protected]
+1 310 388 93 34

Δ

Thank you!

We’ll be sending you some CVs within two business days.

Discovery Phase

The role of the discovery phase in the software development estimation process is to dive deep into the tech and business analysis, discovering possible flaws, inconsistencies, and opportunities to adjust the estimates accordingly—make them as accurate as ever. Without it, both your company and the software development vendor on the job can suffer huge financial losses.

The discovery phase helps us achieve certainty in that the project requirements are final, and there will be no sudden/drastic change in the course. It also helps us refine assumptions and reveal hidden risks or potential blockers—laying the groundwork for delivery on time and within budget.

“Most projects simply must go into the discovery phase before starting actual development. When refining the requirements, it often happens that the client decides to add some functionality shortly into the discovery phase. As a result, our previous estimate, acceptance criteria, and risk mitigation strategies have to be revised. And it’s in the best interest of everyone involved to do this during discovery rather than the delivery phase.”

Nikolai Pivovarov, Delivery Director at QArea

Back to the process now. When you have approved the high-level estimate and accepted the proposal, we will proceed to signing the contract for the discovery phase. Then, we begin to put together the development team approved for the project. In addition to the delivery manager and software architect, the team for the discovery phase may consist of a UI/UX designer, niche developer, business analyst, QA engineer, subject matter expert, and even a DevOps engineer, depending on the complexity and scope of the project.

We tell everyone their role on the project, the tasks they are expected to complete during the discovery phase, and the artifacts that should be produced as a result.

Discovery Phase Artifacts

This section describes the artifacts you get as a result of a discovery phase and their importance in the software development cost estimation process. If you are an experienced entrepreneur, well versed in project management documentation and how it correlates with software cost estimation, feel free to skip ahead to the next step of the process.

Project Management Plan

A project management plan (also known as Project Initiation Document) refers to a series of documents that define the execution and control stages of the project. This includes roles and responsibilities on the project, communication, risk management, resource management, quality control, and change control, as well as the scope, deliverables, and timeline. A project management plan provides insight into the escalation process between the client and the software development team.

Product Backlog

As described in the Scrum Guide, “the Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.”

The project roadmap and requirements provide the foundation for this crucial artifact in Agile software development. Here, the most important activities/deliverables are shown at the very top so that the development team can prioritize what to deliver first.

Acceptance Criteria

In Agile software development, the term acceptance criteria refers to the conditions that a software product must meet in order for a project to be accepted by the client. Acceptance criteria are based on the scope and requirements of the project—the work the development team has to complete in order to consider the project successfully delivered and the contract fulfilled.

Well-defined acceptance criteria help set and manage expectations, reducing ambiguity on the project and unifying the product vision of the client and the development team. They protect the project from scope creep and make sure the team sticks to the predetermined course of action.

On the subject of project cost estimation in software development outsourcing, the crucial function that acceptance criteria perform is change control – a matter of utter importance in fixed-cost projects.

For example, a client adjusted their business strategy and decided that they needed a couple more features to be added to the software solution we are developing for them. For us as a software development company, this means additional effort and the risk of going over budget. In such a case, we refer to the acceptance criteria, where we check if the requested features are part of the predetermined project plan. If they aren’t, we gather a change control meeting to create the necessary change requests.

 “There is an industry-standard policy that we follow regarding change control. The project team will update the acceptance criteria and introduce the necessary estimation adjustments only after they’ve received an appropriate change request document. The same applies to changes in the project management plan. Otherwise, we stick to the previously agreed course of action.”

Roman Lyha, Head of PMO at QArea

UI/UX Approach

When it comes to design, the discovery phase output really depends on the scope of the project and the steps UX and UI design hold on the priority ladder. In most cases, a UI/UX designer provides a preliminary UX prototype in the form of flowcharts and wireframes to show the client the general design approach chosen for their software solution. On smaller projects, however, the designer may provide you with a clickable prototype that includes elements of graphic UI design, animations, transitions, sliders, etc.

Architectural Approach

The software architect’s job in the course of the discovery phase is to build a comprehensive conceptual model of the future technical structure of the software product. This includes information such as system behaviors, components and subsystems, processing logic, operating environment, etc. This document may also include references to existing software solutions and relevant historical data.

Business Approach

In case it’s a product development project, the client may also require the help of a business analyst on the vendor’s part. If so, the assigned business analyst will be responsible for producing the following artifacts:

• A business requirements specification that may contain data such as a problem statement, business use cases, business drivers, and business model.
• Functional requirements specification that is the collection of all the functional features planned for the product.
• Non-functional requirements specification that covers quality indicators such as performance, security, maintainability, etc.

“From my perspective, a discovery phase may be a few days up to two-three weeks for a potential large-scale enterprise project. This is a good step to ensure that we understand all of the client’s corresponding needs, and they understand the work that is going to be entailed and how it is going to physically be done by the development teams before we move into a formal contract for the delivery process.”

Bruce Mason, Delivery Director at QArea

Seal the Deal

Following the discovery phase comes the presentation of our solution to you. There are times when we revise the budget both up and down, depending on whether we were faced with additional risks and complications or, on the contrary, refined the requirements and developed a more efficient delivery plan. As a result, if you are satisfied with the low-level estimate we provided, the team commits to the project, we sign the delivery agreement, and the work begins.

Why Can Two Similar Projects Be Priced Differently?

The exponential growth of all things digital makes the market an increasingly tight environment for businesses to compete within. The time to market becomes one of the main goals businesses pursue when developing a new digital product or service. To cater to the needs of their clients, software development companies are continuously evolving their delivery approaches to increase velocity, and tech companies roll out solutions that provide businesses with convenient development shortcuts.

Custom or platform-based is a common question we get from our clients when they come to us with a request to develop a solution. 

“A mere decade ago, software development projects used to be measured in thousands of hours. Today, a standard scope is 200-400 hours. Nowadays, there are a lot of frameworks that significantly reduce software delivery time. Take eCommerce, for instance. Platforms such as Shopify, Magento, and WooCommerce give you a lot of advantages out of the box—features that used to be custom-made.”

Nikolai Pivovarov, Delivery Director at QArea

This is standard practice in software development cost estimation. When we see that your project can be completed in different ways, we always tell you the options you have.

For example, you want a custom eCommerce store developed using a specific stack of technologies that you read about or learned from your competitors. But do you really need a custom one to achieve your business goals? We thoroughly analyze the requirements and weigh our options. If we see a more cost-efficient way to achieve the same business goals without sacrificing quality or making trade-offs, we suggest that you take this path. Thus, we deliver the same results significantly quicker and at up to 10 times lower budget.

Another reason for price discrepancy that is worth mentioning is third-party integrations and how this correlates with quality assurance. There are those types of situations when you deal with an application that has multiple third-party integrations. And while the hookups of the APIs may seem relatively simple compared to custom software development, it’s the testing that becomes a tricky part. So, let’s take a look at another example.

Can Testing Overweigh the Software Development Cost?

Say we receive your request to develop an eCommerce-based application where you want to include a series of products within your eCommerce website. From the development perspective, the back-end developer will hook up an API with a third-party provider, which will pass data to the system, while the front-end developer will take care of the API connection part. 

In this case, both the back- and front-end parts are relatively straightforward: the back-end developer needs to make sure that the external API has a connection to token authentication, and all the front-end developer has to do is call the appropriate API from the back end. Hooking up these pieces of corresponding work wouldn’t take a large amount of person-hours. But that’s where the testing perspective comes knocking on our door, and the corresponding work becomes an overhead. 

While the development work is relatively small, the amount of physical testing required to check the API interaction significantly outweighs the development work. The team has to test the API data that’s coming through the system. They have to check the front end—the way that it’s actually showing the corresponding data. And last but not least, check the components that are being used to call the API to push the data into the database. 

All of those stacked together can make a huge difference on the part of a testing estimate in relation to the development estimate. So, in this instance, the testing estimate can end up being 300-400% larger than the development estimate. 

“Explaining these types of things to a client is tricky. They may say that you can just take the API data and push it through. Yes, you could. But you then have to test it and make sure everything works together. And then, when you throw in multiple devices and platforms, for example, tablets, phones, web applications, different browsers -all of this suddenly exponentially grows to the point where you turn around and say to a client that to test all of this properly is going to cost them thousands of person-hours.”

Bruce Mason, Delivery Director at QArea

Among other factors that affect the price difference between two similar projects in software development outsourcing can be:

• the stage of our engagement on the project (the amount and quality of work done prior to our collaboration)
• the number of project team members and their seniority level
• the collaboration model chosen for the project

Build software fast and within budget with our flexible collaboration models

Learn more

Tell us about your project.

We’ll send back CVs and get in touch to learn more about your project.

Name*

Email*

Project Description*

I agree to the QArea Cookie Policy and Privacy Policy*

[email protected]
+1 310 388 93 34

Δ

Thank you!

We’ll be sending you some CVs within two business days.

Do project cost estimates differ depending on a chosen collaboration model?

Yes, they do. And it’s always a trade-off. Despite a common belief, a fixed-cost project will often turn out to be more expensive and time-consuming than a time & material or dedicated team approach. 

This is mostly due to fixed-cost projects being estimated closer to the pessimistic point on a three-point estimation curve, with every risk and potential contingency included in the price. Another complication fixed cost projects face in 90% of the cases is the lack of flexibility. More often than not, our clients don’t know what their final products should look like. Therefore, they waste significantly more time on change control. Instead of staying within the fixed budget they had planned, clients are stuck in a daunting cycle of pushing change requests, adjusting acceptance criteria, and making amendments to the delivery agreement.

In such a case, a T&M model would cost a lot less money to a client than a fixed-cost contract. The T&M model makes it possible to be flexible in change control—work with changes to functionality without using change requests.

“The client pushes a request, and we estimate the work required to complete it without a halt. We estimate the additional tasks then and there, managing change more effectively.”

Roman Lyha, Head of PMO at QArea

Some clients may not choose to work on a fixed cost or T&M model at all. They may want a dedicated team where we will basically provide them with resources that are charged on a monthly basis. This is a trade-off again, which the client has to consider. Charged by the month, a dedicated team will variably work out cheaper than T&M or especially a fixed cost model that charges by the hour.

In a dedicated team-based collaboration, we will guarantee to do X number of sprints over a Y-month window where the provided dedicated set of resources will deliver the corresponding work as required. Focused solely on your project, a dedicated team will gradually improve sprint velocity to the point where they are continually performing at a level much higher than a fixed cost or T&M team would, given that the developers in those collaboration models may be engaged in a number of different other projects depending on the windows they have on your project timeline. 

“There’s a fine balance for clients between each of the collaboration models. We just need to make certain that we really have considered all the risks and ways we’re going to mitigate them against the delivery timeline to ensure that we can deliver within time and budget.”

Bruce Mason, Delivery Director at QArea