Tips on Software Development Effort & Costs Estimation

Building working software is hard. Building working software through a committed timeframe is even harder.

One of the greatest “holy wars” in software engineering certainly lies in producing a meaningful estimate that will satisfy both the stakeholders and engineering departments. Wrong estimates lead to schedule shifts, which in its own turn adds a headache to every party involved in developing and delivering the working software.

This fact makes the great estimation one of the most valuable skills for people working in technical leadership teams. But also, it is equally important for the stakeholders to have an understanding of the way the good estimation is produced and how to achieve it.

Let’s take a profound look into what makes an estimate good and how to produce one.

What Makes Estimation a Hard Thing to Handle

There are 2 main causes why estimation goes wrong:

• Lack of requirements clarity
• Over-optimistic nature of people’s assumptions

The lack of requirement is pretty straightforward. The less you know, the more uncertainty you have, the more risk of changes along the road you face. Here is a simple chart to describe the dependency between the level of detailed specification and possible costs of the development.

The second thing to take into consideration is the risks of under-estimation produced by engineers prejudice. No matter of the amount of information provided about the future implementation, engineers tend to estimate the work assuming that everything will work out as expected along the road. This a dangerous and fallacious way of thinking because it excludes the uncertainty, which is present almost to the very last phase of the development:

• Issues always come up along the road
• Testing always takes longer than expected
• Requirements also change quite frequently based on the feedback
• Systems become obsolete even during the development

There are a couple of methods to tackle the under-estimation problem, like Model-based estimation, Monte Carlo method, PERT (Program Evaluation and Review Technique) and so on. Depending on the complexity of the project and budget/time/resources constraints, you can choose how much of solid math and parametric models to include in your estimation process.

For this article, let’s stick to a high-level estimation effort; hence the simplest one — PERT. You may also know it as arithmetic mean value calculation.

Estimate Effort = (Optimistic + Likely + Pessimistic) / 3

The following approach will help you to mitigate the risk of under-estimation, at least to a certain extent.

The Fundamentals of Estimation

The basis of every estimation is the decomposition. First comes the decomposition of the estimation process itself. We can describe the process in a set of steps for a better understanding of ways to handle the task.

NOTE: The steps are written in sequential order, but the nature of the process in highly iterative, and the parties involved may reiterate one step or another based on the incoming information along the way.

1. Gather and analyze software requirements
2. Define the elements that have to be implemented and overall readiness of the existing software.
3. Estimate software size
4. Estimate software effort
5. Calculate software costs
6. Determine risks

Each process phase can be decomposed on its own, and it is especially related to estimation of software size and effort. Risks, and requirements are not in the scope of the following article, so let’s discuss the effort, size, and costs estimation a bit more.

Decomposing for effort and size

The software effort has to be decomposed in a fashion that the person responsible for the estimation understands the following:

• Number of sequential constraints that define the time of the effort
• Number of independent tasks that define the amount of manpower

Men and months are not interchangeable parameters (well, they are, but only to a certain extent). This is why you need to understand how to calculate ones independently and then sum up into an overall estimate.

Under the sequential constraint, one should understand the dependencies between the system components that are blocking the parallel implementation of the system. Meaning, no matter how much people you assign to the product implementation, the single component cannot be implemented before the one that it depends on will be finished.

The number of independent tasks allows us to calculate an approximate manpower to use in its full capacity during the parallel implementation of components.

Decomposing for costs

Decomposition also is helpful when you proceed with costs calculation. One of the most reliable methods to do some math here is the Back-off-the-Envelope estimation. There is a lot of writing done regarding this method, so I won’t get into details here. Just to mention that it allows to calculate disk space, expected CPU loads, required network bandwidth and so on, which obviously, will set the overall price for the hardware you need to run the product.

Every engineer has to know or at least refer to the following table with latency numbers, understand the power of two concepts in engineering and availability numbers (SLA) of the systems he or she will work with.

Estimation methodology (Spoiler: they’re all pretty much the same)

Now, when you have determined the requirements and decomposed the system into modules/sub-systems/services, the estimation itself comes into play. You may have read a couple of books on the estimation already, but there is always one thing in common between all the suggested methods — an experience of the person that deals with the estimation.

99% of the estimation methodologies are experience-based: either it is an expertise methodology, estimation by analogy, model-based methodology, rule of thumb, and so on. Everything comes from experience gained by building similar systems.

What you have to do is to take a decomposed module and map it to something similar that was already built in the past. Either by you (experience-based) or by someone else (expertise-based, estimation by-analogy). There are two things to keep in mind to make the estimate accurate:

• Understand the estimation context: software architects and software engineers operate in different contexts; hence, they estimate different size and effort for the same product.
• Decompose the system to a level that you can estimate based on experience and not by guessing
• Understand the nature of over-optimistic assumptions and calculate the mean value of the estimate by providing optimistic, pessimistic and likely numbers.

Yes, you better hand the estimation over the most experienced and qualified person in the team.

Some level of uncertainty will be still present along the whole development process, and you may find a common practice for an engineer to add 20–30% of overall estimated time just as the safety measure to cover all the expectancies.

Summary

So, what do we have in the end? Let’s point out the key action items you need to work on during the estimation phase:

• Requirements. The clearer they are, the better the estimate will be. Keep pushing stakeholders to provide additional information and reiterate until you are confident in and satisfied with the incoming data.
• Decomposition. Decompose, decompose, and again decompose. Granularity is the key to the estimation accuracy.
• Calculate mean values. Don’t fall into the trap of the optimistic assumptions. Bring in your optimistic numbers, think of the worst-case scenarios, mix in likeliness based on the experience, get the arithmetic mean value and proceed with it.
• Protect the estimate from uncertainty. Give the estimate additional 20–30% of effort numbers. It is always better to overestimate than underestimate.
• Get the most experienced opinion available. Experience is all we have to get any valuation of the effort, time and cost. Make sure you involve the most experienced guy in the room into the estimation process.

Further reading

• Steve McConnell. Software Estimation: Demystifying the Black Art
• Peter Hill. Practical Software Project Estimation: A Toolkit for Estimating Software Development Effort & Duration
• George Dinwiddie. Software Estimation Without Guessing: Effective Planning in an Imperfect World

Please feel free to reach out to me in case you have any questions or need an advice via email (pavlo.sobchuk@gmail.com) or directly at LinkedIn.