Determining how long and how much it will take to deliver a new software product is one of the hardest things to do in software development. But the main critical problem that arises during software cost estimation is a lack of determination on how long and how much it will take to develop a new software product.
It is inherently difficult to estimate software costs, and humans are terrible at predicting absolute outcomes. However, this problem can only be resolved by transparent communication and development processes based on collaboration and co-creation.
Mad Devs is a software development company, which specializes in developing highly scalable, enterprise-level software solutions, and consulting. We have been engineering our partners’ growth since 2004. Our goal is to deliver value to our customers in the long run by solving end users’ problems. For us, no two projects are the same. Each is unique in what it sets out to achieve and unique in the myriad of parameters that form its existence.
For years, we’ve seen new players in the IT industry struggle to find insights into custom software development. Mad Devs has summarized its expertise by introducing Customer University: a series of articles that bring light to questions that need to be asked during negotiation and proposal evaluation stages.
We believe in starting the partnership by building trust from the very beginning. Therefore, we understand that pricing is one of the customers' main issues. To do this, we explain the mechanism of project estimation transparently. For convenience, we have divided the technical process into four stages.
Stage 1. Receiving the request
When we receive a partnership request, we foremost assess the proposed project to see if we are a proper contractor to take it on. Several features impact our work process, such as expertise in questions, the scope of the project, and can we cover the project with our resources. Mad Devs believes that signing a contract is a long-term commitment, so it is essential to consider every detail. We believe customers' business success depends on whether we have enough expertise and capacity to deliver the project.
After we ensure that we have enough expertise and capacity to deliver the product, we start evaluating the customer's product vision and check whether it has a proven record of market fit.
Unfortunately, it is unlikely to build a valuable product for end-users without precise product specifications and requirements. Such projects usually involve high risks and a lack of personal growth for our developers. Instead of developing features, the IT team will be trapped in a circle of re-developing one module repeatedly and wasting the budget. Cost is a product of time and team members. Suppose you employ people for a more extended period, the cost increases. Adding more team members increases the cost of delivering the same business value.
We expect a certain level of preparedness from our clients. Please note if you have the following problems:
- If there is no vision for the project: there’s a list of requirements in the request but no explanation of how the project can survive in the market or otherwise make profits.
- Projects of small scope or short life span: our approaches (well-established processes, attention to detail, and emphasis on sustainability, e.g., architecture and CI/CD) are suitable for high-loaded projects.
- MVPs without market fit: we do not undertake projects without a defined target market.
Stage 2. Factors affecting the development process: researching & estimating
Worldwide researching & estimating practices
Cone of uncertainty
Defining the scope of work early in the process is often impossible. Usually, the more specific the project requirements, the more accurate the quote will be. The cone of uncertainty is one concept that perfectly illustrates this phenomenon.
According to the graph above, the highest level of uncertainty is typically observed during the planning stage. At this point, the estimated changeability may range from 4x to 0.25x. In other words, if a project is estimated to take a month, it may take from 1 week to 4 months. As the project progresses, the degree of uncertainty decreases. As soon as the software is deployed, the exact length of the project will become evident.
According to the information above, you can see how the Cone of Uncertainty principle should work in theory. Generally speaking, the range of deviations depends on the scope of a project and may differ accordingly.
Principles of software cost estimation models
Most models found nowadays are two-stage models. The first stage is a sizer and the second stage provides a productivity adjustment factor.
First (size) stage. An estimate regarding the size/volume of the software to be developed is determined by a sizing mode.
Second (time) stage. An estimate of how much time and effort it will cost to develop the software of the estimated size. This size estimate is converted into an estimate in nominal person-months of action.
Figure 1 shows the two stages in software cost estimation models.
Figure 2 shows the sizing and the productivity stages in the context of general cost estimation.
Here are 5 components of the general cost estimation structure:
- Creation of a database of completed projects;
- Size estimation;
- Productivity estimation;
- Phase distribution;
- Sensitivity and risk analysis;
Besides the sizing and productivity components, the phase distribution and sensitivity/risk analysis components are distinguished. In the phase distribution component, the total effort and duration are split up over the phases and activities of a project.
The sensitivity and risk analysis phase supports project management in determining the risk factors of a project and the sensitivity of the estimates to the cost drivers settings. The environment and database of completed projects will differ from the project characteristics of the environment(s) in which the model is to be used.
Most SCE model tools do not support project management in all of these steps.
Measures based on the amount produced in a given period ignore quality characteristics such as reliability and maintenance. More does not always mean better. Also, the programming productivity of individuals working in an organization is affected by several factors. However, individual differences in ability are usually more significant than any of these factors.
Productivity should not be a measurement of judgments about the abilities of the engineers in your team. It may be the case that the ‘less-productive’ programmer produces more reliable code. So it is better to always think of productivity measures as providing partial information about programmer productivity. Also, need to consider other information about the quality of the produced programs.
Challenges of software cost estimation models
Cost estimation is a way to find out what the costs will be. Many reasons make software cost estimation so tricky, and without going into detail, some can be listed as follows:
- A lack of data on completed software projects can support project management in making estimates.
- Difficulty in formulating clear specifications at the beginning of a project.
- A priori estimates do not assume that sometimes developers for non-trivial software development use tools they’ve never used before.
- They need to be considered different сost drivers, as they influence the initial outlay range of deviation.
- Sometimes, customers do not have enough technical experience to provide specific requirements.
- Developers understand that the estimation process at an early project stage is highly subjective.
- Underestimation of how long a particular part of the software would take and extrapolate this estimate to the rest of the system.
- Ignoring that a lot of work will be done by staff with different experience levels.
- It is necessary to consider rapid changes in the IT-sphere and software development methodology.
- Estimates in a hurry do not consider the effort required to do a credible job, so specifications may not be precise. As a result, the cost can increase.
Research
If we are talking about our company, often, when we receive a request to develop software, the first thing we focus on is the functionality that serves the customers' businesses and needs most effectively. When we receive a request to develop software, it is essential to understand customer requirements and third-party research solutions. Sometimes it is possible to solve the problem without actual coding.
Software engineering is one of the top services outsourced to contractors. Based on different sources, with a value ranging from $63.5 billion to $159.1 billion globally. In our company, we follow the rule that businesses must know the expected time/budget before starting any cooperation.
Let us not deny we love coding, but developing a product just for developing it doesn’t align with our corporate values and mission. Software engineering is a highly complex area of knowledge, and it can require extensive research and out-of-the-box solutions. We can propose our solution only when we ensure that a product’s value proposition is clear.
Estimating
Estimating a project's scope is the next step. For our team, estimation is one of the most important steps in the whole process. We are trying to find the most accurate sizing figure for the software project effort throughout the process.
According to the estimation result, our project team has some confidence about the required effort and time to plan for the project. Moreover, not all software projects are time and material contracts, some are fixed-price projects, so this estimate is used to negotiate the project cost. Indeed, a product must deliver on its promises and the needs of its customers. If you end up with a product nobody wants or can use effectively, then it's not a worthwhile way to spend all that time and money. As mentioned, estimation is a process. This process contains the following steps to reach the estimate. The cycle will follow until the estimate is complete.
1. Scope
First, we scope the project even if we do not have the complete detailed requirements.
2. Decomposition
We broke the project down into logical 'mini' releases that contribute to the whole product. This process helps our team to avoid unnecessary risks. Also, the customer can define a level of re-prioritization and revise the list of features.
3. Sizing
Most of the time, the estimation is based on the IT team’s seniority levels and its composition.
4. Review
At this step, sometimes, we ask for a review from our colleagues that we have done the correct estimation.
5. Finalization
We aggregate all the estimations from components and functions and have a baseline estimate.
Velocity
Another factor needed to concern before developing software is velocity. The team adds up the effort estimates associated with the completed user stories during each iteration. Velocity measures a team’s capacity to get work done in a given iteration (or sprint). Velocity expresses a range, especially early on in a project’s life.
With velocity, we plan our releases and adapt our plans and work packages as we progress through a project. This enables us to accurately and regularly adjust our forecast for completion through execution. Additionally, velocity limits the amount of work taken on in subsequent iterations.
Risks and uncertainty
We also include risks and uncertainty in our development process. All software projects come laced with a level of uncertainty. Then we have more information about the environment, performance, and the needs of the customer and users, and then uncertainty becomes less, then the project’s progress becomes faster.
Most of the time, the estimation is based on the IT team’s seniority levels and its composition. Together with the combined minds of the SWOT team and the customer, we build a high-level roadmap and define a tech stack. Although, in the beginning, it is almost impossible to predict the exact deadlines and scope of work, a high-level roadmap still brings some clarity and understanding of a project's financial feasibility.
At Mad Devs, we include 15-20% risks to each module, and the percentage is distributed to every feature. Risk management is necessary as the project scope is frequently adjusted, and new black boxes appear. Since 2004, we’ve worked on dozens of highly-loaded IT projects and have developed practical ways to mitigate risks and adequately plan project scopes.
We also include a so-called development tax and deal with technical debts, quality assurance tests, and writing up-to-date documentation. Such additional processes are necessary investments to ensure the product’s stability and scalability.
Stage 3. Choosing the cooperation model
Over the last years, Mad Devs gained experience in 50+ large-scale projects. In the light of the knowledge gained, we developed 360-degree expertise and suggested solutions that fit customers’ business needs.
Outsourcing and outstaffing are traditionally two of the most common cooperation models. Let’s elaborate on them before addressing the more advanced and modernized classification. In some instances, we incorporate a hybrid cooperation model.
Our company uses all manner of methods to take into account all the wishes of customers. We understand that for some customers, the required cooperation model is clear, for some, it does not. For those who require careful assessment of current and future needs, below is described each cooperation model:
- Staff augmentation: we assign individual specialists from our team to complete tasks for you.
- Project-based dedicated team: we provide you with a team (often featuring a project manager) to undertake your project as a whole.
- Temp to hire: we assign individual specialists to complete tasks for you so that they can be later transferred to your team as full-time employees.
- Technical assessment & Consulting: our technical experts with specific expertise perform analysis for you and provide recommendations.
- Team supervision: our managers and team leads supervise your current team and help manage it more effectively.
- Legacy software management & Project transfer: we take on projects that other teams have worked on but failed to deliver desirable results.
Stage 4. Proposal agreement and negotiation
The proposal agreement and negotiation process is a long cycle, where our goal as IT consultants is to understand whether our plan reflects the short and long-term product vision.
As a customer, you need to be well-informed about cost and duration. To answer customers' questions, we conduct a presentation of our plan with a customer. Customers can make changes in the agreement involving multiple interactions and re-estimation. This process may go on until the final result satisfies both parties.
We do our best to answer all possible questions and transparently show the pricing breakdown inside the document.
Our proposal includes the following sections:
- Project goals
- Project brief
- Detailed information on tasks breakdown
- Team composition
- High-level project roadmap
- Development plan and duration
- Cost procedure and quotation assumptions
Extra: Pricing model and formula
Algorithmic cost modeling
The cost estimate is the financial spend that is done on the efforts to develop and test software in Software Engineering. Algorithmic cost modeling uses a mathematical formula to predict project costs based on estimates of the project size, the number of software engineers, and other process and product factors. Generally, algorithmic cost models are used to estimate software development costs. In its most general form, an algorithmic can be expressed as:
- A is a constant factor that depends on local organizational practices and the developed software type.
- Size may be either an assessment of the code size of the software or a functionality estimate expressed in function or object points.
- The value of exponent B usually lies between 1 and 1.5.
- M is a multiplier made by combining process, product, and development attributes, such as the dependability requirements for the software and the development team’s experience.
As the size of the software increases, extra costs are incurred because of the communication overhead of larger teams and so on. Unfortunately, all algorithmic models suffer from the same fundamental difficulties:
- It is challenging to estimate Size at an early stage in a project. It is easier to estimate the size of functions and objects than code size, but they are often still inaccurate.
- The estimates of the factors contributing to B and M are subjective. Estimates can differ depending on the person's background and experience with the system being developed.
When using a cost estimation algorithm, companies develop a range of estimates (worst, expected, and best) and apply the costing formula to all of them. As the software process proceeds, more information becomes available, so estimates become more and more accurate.
Mad Devs strategy
Time & Material basis is the central pillar of our work strategy, which means that you only pay for the actual time our specialists work on your project (this time is tracked in the typical project environment). The basic formula is:
The first essential element in the formula above is time. We include estimates of the whole product development process, including dealing with technical debt and real users’ feedback when calculating it.
The second element is the team. The team can consist of developers of different seniority levels (Junior, Middle, and Senior). Their rates are different, too. We make sure to explain our team composition* choices in the proposal.
We use the time & material model because it enables flexibility. Under this arrangement, a project will have a more or less stable monthly budget, while the scope and tasks can be reconsidered. The alternative—the fixed price model—is rigid: any changes in the initial plans require revising the contract. Click here to learn more about the differences in pricing models.
* When we compose the team, we match the members’ expertise with the project's needs. If the team is overqualified, the customer will be paying an unnecessarily high rate. If the team is underqualified, it will spend too much time on development so that the customer will overpay. We want to avoid these scenarios.
Trusted IT partner
We hope the information above will answer your questions about insight into planning, estimating, and defining a price for a software project. These approaches and techniques are designed to build trust between team members and make customers confident about how much time and resources it will take to build a product.
Our pricing, as well as our approach to developing software, is focused on delivering value. We aim to develop products that ultimately make our customers successful by delivering software that solves end-user needs and wants. Here are the reasons why our customers choose us over other contractors:
- Expertise in long-term, stable and scalable, high-loaded products.
- Transparency in organizational and development processes.
- Value-oriented development.
- Commitment and determination to achieve project results.
Mad Devs have the experience to rely on smart approaches to development. Moreover, we do not hide our plans, processes, or calculations—instead, we share those enthusiastically. When you receive a proposal, you also receive a detailed explanation of why a particular approach will be the best option to implement in your project.
If you have questions or want to discover more details, get in touch with us.
