How to Do Software Project Estimation: Our Techniques and Advice

‘If you ever wanted an example of Heisenberg’s Uncertainty Principle applied to software, estimation would be it’

Nearly every software development project starts with one question: how much effort is this going to take in terms of time and money? Or simply put, ‘What’s the damage?’.

Software project estimation definition: ‘the process of predicting the most realistic amount of effort (expressed in man-hours or money) required to develop or maintain software based on incomplete, uncertain and noisy input.’

Now, that’s a question easier asked than answered. Regardless of experience in software development, answering it ‘off the cuff’ is hardly ever possible. And here is what happens behind the scenes when you ask us for a quote.

Initially, what we can base our estimation on is just an outline of a project, minus specifics. You, as a client, will obviously be looking for the best bid. And so, to secure this bid, we, as a provider, will bid to win. No matter how unethical it may sound, ‘pricing to win’ is a common practice. Managers need to understand the probable price range before they decide on the profitability of such an investment and have a budget approved for the project. Thus when you ask for a quote, you receive a ballpark estimate.

Ballpark estimate

It’s a document including:

• List of features
• Rough order of magnitude estimate
• Evaluation of technical feasibility
• Assumptions
• Suggestions

It is free, part of a Presale stage of our collaboration with a client, and may take as long as a week.

How to calculate a ballpark estimate

Let’s talk a bit about estimation techniques in software project management. The initial estimate is conducted by programming experts, based on whatever data is available at the start – business requirements, specification, project description or other. It is done mainly intuitively or by analogy with similar projects. Calculation of cost is just one aspect within the scope-effort-schedule-staff-cost correlation.

As originally we mostly operate with unknowns, it’s important to keep balance, because both underestimating and overestimating are equally undesirable. The former leads to cost overrun, staff burndown, low-quality deliverables, and loss of credibility if deadlines are missed. The latter makes the project too expensive and uneconomical with regard to resources (consider Parkinson’s Law: ‘Work expands so as to fill the time available for completion’) or may result in lost opportunities if extended over a longer timespan – both factors are likely to eat up a vendor’s profit.

You cannot expect it to be accurate by default. It’s more about setting expectations for a project. Thus a ballpark estimate is an order-of-magnitude figure ranging from the most optimistic to the most pessimistic guess. And the actual cost is not necessarily the happy mean.

Such a span is not a figment of developers’ imagination or a whim but has a scientific basis. The ‘Cone of uncertainty’ will narrow with time when requirements become clearer, more precise and detailed. But the maximum and minimum cost figures will converge only at the finish. The cone of uncertainty is equally applicable to the estimation of costs, resources, time, effort, and scope.

Picture 1 model the Cone of Uncertainty (from Steve McConnell’s ‘Software Estimation: Demystifying the Black Art’)

How inaccurate is a ballpark estimate

Even though the inaccuracy is received as a result of the most precise estimation conducted by technical experts, the initial estimate can be off as much as 400% on the high or low side. That only narrows to +∕−200% after product definition is approved and to about +∕−150% after requirements are completed. As you see, uncertainty is unavoidable and the initial range can be narrowed considerably no sooner than a third of a project has been accomplished.

Picture 2. The Cone of Uncertainty in calendar representation

That is why with fixed-price contracts a detailed estimate calculation takes so much effort, and still does not guarantee 100% accuracy. In case of Time and Materials model, where Agile methodology is implemented, there is no need to secure the price variable at the start. Thus initial rough estimation can be honed ‘on the go’ and there is a chance to adopt the most appropriate and economical direction anytime.

Do I need a ballpark estimate

Well, that’s what you asked for, isn’t it? And it’s the most we can do for you at the beginning. The purpose of a ballpark estimate is to give our client an approximation of cost within a range of required functionality. This document serves for information purposes only.

Detailed estimate

This one comes later on, in case you agree that the project is within budget and fit for a Fixed-price model of engagement. It is a costly project in itself that comprises a thorough analysis of business and technological aspects and risks, elaboration of a detailed specification, and complex algorithmic computations along the lines of five parameters mentioned above. A detailed estimate is provided as part of a Work Order together with a project plan, technical requirements and acceptance criteria at the end of Pre-Production Stage (Stage 1) of the software development process.

How detailed is a detailed estimate

This estimate contains a more elaborate description of the cost of deliverables and services. It’s detailed enough to result in greater precision so that both sides have a common understanding of the project’s objectives and the product’s values. To give you an idea of the scale, let’s look at how technicians break down the development scope. They use hours as units of measure. Every item must be less than or equal to 16 hours (2 days) of development. We make a special point of this requirement as planning over longer periods yields less certainty. By doing this, we can guarantee greater precision of our expert estimates.

As we have shown above, the cone of uncertainty narrows considerably by the time a detailed specification is ready. Still, the following three categories of items remain:

• knowns
• known unknowns
• unknown unknowns

Just a glimpse at technicalities

The Excel spreadsheet, where the total of the foreseeable effort is priced, includes the following categories of items:

• Requirements analysis
• Construction
• Stabilization and Delivery
• Management and Communication

These further break up into subcategories of features and services descriptions.

1. Requirements analysis comprises the effort of creating SRS, calculating the project’s cost and measuring other parameters. All the items are estimated in man-hours by professionals involved.
2. Depending on a project, construction may include particulars of web/mobile/HTML development, estimated by corresponding experts in hourly rates.
3. Stabilization and Delivery is a broad category that may cover a range of subcategories and activities, typically testing (creating manual/automated test cases), code stabilization (bug-fixing, refactoring), and deployment (to staging – UAT; to production). Measuring the scope of these activities may involve expert estimation. However, our practice has proven that an average effort of this category equals about 30 – 40% of the construction cost. So we may just as well add this sum for stabilization.
4. Management and Communication activities involve organizing dev meetings, creating status reports, change requests and other routine activities. These normally add another 30% to the project’s cost. Every single item of the Excel document is assigned to a person accountable; it’s also estimated, rated and priced. If the risks are high and change requests are undesirable, we include a contingency fund. Sometimes, the contract may stipulate that the contingency fund should be returned if not used.

Agile estimation

With Agile projects we normally give a ballpark estimate, but not a detailed one. Why? Because Agile estimation is not about striving for precision and accuracy in measuring the unknown and then struggling to hit the targeted dates and sums. It’s is about efficiency, quality, and delivering business value early.

Read also: Agile or Waterfall: Choose the Right Approach to Your Software Project Management

What’s the point of Agile estimating

At first glance, Agile development effort estimation in software engineering may seem redundant, since the cost variable is not frozen from the start. Indeed, compared to the traditional waterfall project valuation, agile effort estimation techniques in software project management do not aim at calculating the ideal trajectory of hitting the cost/time target upfront. However, they serve as a starting point – to discover the best solutions and make adjustments on the go. The focus is not on how to deliver on time and budget, but how to use the finite resources efficiently to deliver value. Thus it’s enough to roughly understand a project’s size and the team’s velocity to make assumptions about the time and cost. As soon as the team reaches a reasonably consistent velocity (which usually happens after the first few sprints), we can conclude how much time the project will take. As Agile development follows a T&M model of collaboration, its timeline directly impacts the cost.

Want to learn more about our software project estimation techniques? Do not hesitate to ask us directly.