# Software Estimation Techniques: Methods and a PERT Example

> The most practical software estimation technique for most teams is a bottom-up three-point estimate: break the work into packages, give each an optimistic, most likely and pessimistic value, and apply PERT, (O + 4M + P) / 6. Combine the spread across packages and report a range with a probability, such as 47 to 53 days, 80 percent under 51.

- URL: https://go-projects.de/en/estimates-and-budget/software-estimation-techniques/
- Language: en
- Updated: 2026-10-19
- Publisher: Go Projects (OnlineBuilders LLC, https://onlinebuilders.biz)

Every "two weeks" in software carries an unspoken clause: if nothing gets in the way. Something always does. Daniel Kahneman and Amos Tversky named this the planning fallacy in 1979. People underestimate their own tasks even when they know similar tasks ran late before.

Douglas Hofstadter put it more memorably. It always takes longer than you expect, even when you take Hofstadter's Law into account.

Doubling every number is not the fix. Building uncertainty into the estimate, visibly, is.

## Why early estimates miss so badly

Steve McConnell's cone of uncertainty captures the problem. The less you know about a project, the wider the range its actual outcome can fall into, even for skilled estimators.

**How widely estimates can spread at each stage (ratio of high to low)**

| Item | Value |
|---|---|
| Initial concept | 0.25× to 4× |
| Approved product definition | 0.5× to 2× |
| Requirements complete | 0.67× to 1.5× |
| UI design complete | 0.8× to 1.25× |

Source: Steve McConnell, Software Development's Cone of Uncertainty, Construx 2010

Two caveats matter. These ranges describe the best achievable accuracy, not the typical one; it's always possible to do worse. And the cone does not shrink by itself. McConnell stresses that leadership must actively resolve open questions for uncertainty to drop, and his white paper notes that most of the narrowing happens in the first 20 to 30 percent of calendar time.

Critics such as Laurent Bossavit point out that the specific multipliers came from expert judgement rather than measured project data. The model still earns its keep. Anyone demanding a fixed price at the idea stage is asking for a number that could plausibly be off by a factor of 16.

## The main techniques compared

**Software estimation techniques**

| | Effort to run | Needs history | Best for |
|---|---|---|---|
| Expert judgement | low | no | order of magnitude |
| Analogy | low | yes | budget envelope |
| Bottom-up three-point | medium | no | quotes, approvals |
| Wideband Delphi | medium | no | novel, fuzzy work |
| Function points | high | yes | large or contracted scope |
| Story points + velocity | low | yes | established agile teams |

Analogy is underrated. If you finished a comparable project and know its real hours, that beats any formula. The catch is that you need actuals, which most teams never record. Keep a simple sheet with work package, estimate and actual across three or four projects. It will tell you more about your team's blind spots than any estimation workshop.

Function points measure delivered functionality by counting inputs, outputs, queries, internal data and interfaces, using a method standardised by IFPUG. They take real effort and pay off mainly on large programmes or contracts priced on measurable scope.

Established agile teams have their own approach, covered in [story points estimation](https://go-projects.de/en/estimates-and-budget/story-points-estimation/).

## Worked example: three-point estimation with PERT

For most projects, three-point estimation is the best balance of effort and honesty. For each work package the team gives three numbers: optimistic (O), most likely (M) and pessimistic (P). The expected value is E = (O + 4M + P) / 6, and the standard deviation is σ = (P − O) / 6.

Here's a booking app, estimated in developer-days:

| Work package | O | M | P | E | σ |
|---|---|---|---|---|---|
| Accounts and sign-in | 3 | 5 | 10 | 5.5 | 1.2 |
| Booking calendar | 8 | 12 | 24 | 13.3 | 2.7 |
| Payment integration | 5 | 8 | 20 | 9.5 | 2.5 |
| Admin back office | 6 | 10 | 16 | 10.3 | 1.7 |
| Testing and release | 6 | 8 | 14 | 8.7 | 1.3 |

**From work packages to a project range**

- Sum of most likely values (M): 43 days
- Sum of expected values (E): 47.3 days
- Overall σ = √(sum of σ²): 4.4 days
- 80% chance of finishing under (E + 0.84σ): 51.0 days
- **90% chance of finishing under (E + 1.28σ): 53.0 days**

Adding variances assumes the packages are independent. Real risks are often correlated, so true spread is usually wider.

Two things make this worth the effort. The most likely values add up to 43 days, but the expected total is 47. Adding up "realistic" numbers produces a systematically low total, because things go wrong by more than they go right. And most of the uncertainty sits in two packages, the booking calendar and payments. Rather than padding the whole project, run a short technical spike on those two before you commit.

## How to present an estimate

The best arithmetic is wasted if a single number ends up in the meeting notes. Three rules:

1. Always give a range, never a point. "47 to 53 days", not "50".
2. State the probability. "80 percent chance of finishing under 51."
3. Write down the assumptions. "Assumes the payment provider's sandbox is available in week one and the calendar needs no recurring bookings."

Rule three protects you. People often skip it. If an assumption turns out wrong, the estimate hasn't failed. It needs redoing, which is a normal event.

Turning days into money means multiplying by a day rate. What realistic rates look like, and which costs arrive after launch, is covered in [custom software development cost](https://go-projects.de/en/estimates-and-budget/custom-software-development-cost/).

## Five habits that wreck estimates

- The boss names a number first. After that nobody estimates independently; everyone anchors.
- Only coding gets estimated. Testing, code review, meetings, deployment and documentation vanish.
- The estimate is never revisited. Re-estimate the remaining work after every milestone.
- More people get thrown at a late project. Fred Brooks observed in 1975 that adding people to a late software project makes it later, because onboarding and communication eat time.
- Nobody compares estimate with outcome, so the team never learns.

Wideband Delphi counters the first habit: everyone estimates privately and reveals at the same moment, then the group discusses the outliers.

## Estimates and contracts

A range fits any contract model. Under time and materials it becomes a budget cap with a duty to warn. Under a fixed price, the vendor prices the upper end plus a risk premium. See [fixed price vs time and materials](https://go-projects.de/en/estimates-and-budget/fixed-price-vs-time-and-materials/) for when each makes sense. If your scope isn't settled yet, start with [planning the software project](https://go-projects.de/en/planning/plan-a-software-project/) instead.

If one risky integration dominates your estimate and you want an outside view, you can talk it through with the [OnlineBuilders](https://onlinebuilders.biz/contact) team in a free initial consultation.

Next step: take the three largest work packages in your project and have two team members estimate O, M and P independently. Where the pessimistic values diverge most, your biggest risk lives.

## FAQ

### Which estimation technique is most accurate?

No single one. Two independent methods, such as a bottom-up three-point estimate and an analogy with a finished project, give the most reliable picture. When they disagree sharply, you're missing information.

### Who should do the estimating?

The people doing the work. Estimates from managers or sales tend to be optimistic because they often anchor on the number someone hopes for.

### How much time should estimation take?

For a quote or a budget decision, one to three percent of the expected project effort is a reasonable allowance. Spend more only if it resolves real unknowns, for example a short spike to test a risky integration.

### What's the difference between an estimate and a commitment?

An estimate is a statement of probability. A commitment is a business decision about how much risk to accept. Mixing them turns every estimate into a deadline that will almost certainly slip.

Photo: Sauvagette, CC BY-SA 4.0 (https://commons.wikimedia.org/wiki/File:Multiple_hourglasses.jpg)