Skip to content

Lesson 1 — Effort and Cost Estimation

At a glance

  • Module: 07 — Cost & Estimation
  • Level: Intermediate
  • Estimated time: 40 minutes
  • Example project: the LMS

Learning objectives

By the end of this lesson you should be able to:

  1. Explain why software estimation is systematically difficult.
  2. Describe how the precision of an estimate should change as a project progresses.
  3. Build a cost model that separates labour, non-labour, contingency, and management reserve.
  4. Explain the difference between an estimate, a target, and a commitment.

Prerequisites

Introduction

Every project has a number attached to it before anyone knows much about it: a budget. That number is usually produced by estimation, and that estimate is usually wrong — not because estimators are incompetent, but because of three structural features of software work.

This lesson explains why that is, and how to produce an estimate whose precision matches what is known. The next lesson covers the techniques themselves.

1. Why estimation is hard

Software is largely unique. Bridges are built by analogy to other bridges, with known quantities of material and labour. Two enterprise systems of the same nominal size can differ by an order of magnitude in effort, depending on integration, legacy constraints, and how settled the requirements are.

Progress is invisible. A half-built bridge looks half-built. A half-built system may look complete and fail every test, or look unfinished and work perfectly. This breaks the feedback loop estimators rely on: you cannot correct an estimate from evidence you cannot see.

People are inside the loop. Estimates become targets, targets become commitments, and people adjust behaviour accordingly. This is not dishonesty — it is the normal response to being measured against a number someone guessed.

None of this is a reason to abandon estimation. It is a reason to estimate in ranges, to state assumptions, and to re-estimate.

2. Precision should track knowledge

The estimation funnel describes how an estimate should tighten as a project proceeds. Early estimates are wide ranges; later ones narrow. An early estimate presented as a single number is not more accurate — it is merely less honest.

Stage What is known Appropriate form
Idea A problem statement Order of magnitude: "roughly the size of X"
Initiation Goals, rough scope Range: "between A and B"
Planning Requirements, design Estimate with stated assumptions
Delivery Actuals Re-estimate remaining work

You will meet this again in Lesson 2, where techniques are matched to how much is known.

3. Estimate, target, and commitment

Three words that must not be used interchangeably.

Word Meaning Who owns it
Estimate A probabilistic statement about what the work will take The person doing the work
Target What the business would like it to take The sponsor
Commitment A promise to deliver, with consequences The delivery team, having accepted the risk

Confusing them is the single most common cause of damaged projects and damaged teams. When a target is treated as an estimate, the schedule is fiction from day one. When an estimate is treated as a commitment, the team is held to a statement it never made.

A healthy project keeps all three visible, and explicitly records the gap between them.

4. What "cost" includes

A cost model built only from developer salaries is not a cost model.

  • Direct labour — the people doing the work, including the time they spend not doing it (meetings, support, onboarding, leave).
  • Non-labour direct costs — infrastructure, licences, tooling, training, travel, procurement.
  • Contingency reserve — for known risks, and derived from the risk register. Module 08 produces the risks; the contingency is their price.
  • Management reserve — for unknown work, such as scope changes. Controlled by the sponsor, not the team, because it exists for changes above the project's control.
  • Total cost of ownership — build cost plus the cost of operating and maintaining the product. A cheaper build that is expensive to run is not cheaper.

The distinction between contingency and management reserve is not accounting pedantry. Contingency belongs to the project manager; management reserve belongs to whoever funds scope changes. Mixing them destroys the ability to say "this is a change, not an overrun".

Key terms

Term Meaning
Estimate A probabilistic statement of expected effort or cost
Target A desired cost or date, set by the business
Commitment A promise to deliver, with consequences attached
Estimation funnel The narrowing of estimate ranges as knowledge increases
Contingency reserve Budget for identified risks, from the risk register
Management reserve Budget for unidentified work, controlled by the sponsor
Total cost of ownership Build plus operate and maintain over a lifetime

Worked example

Task: build a cost model for the illustrative LMS submission release. Rates, percentages, and amounts are assumed for illustration, not market data.

Step 1 — Establish effort. The activities from Module 06 total 17 person-days of effort. Not all of a working day is available for project work, so divide by an assumed productivity factor of 0.8: about 21 person-days of paid time.

Step 2 — Establish labour cost. Assume a blended rate of PKR 20,000 per person-day: 21 × 20,000 = PKR 420,000.

Step 3 — Add non-labour costs.

Item Basis Amount (PKR)
Staging environment 3 months of hosting 45,000
CI and code tooling Per-seat subscription 25,000
Accessibility testing tool One-off licence 10,000
Total non-labour 80,000

Step 4 — Add contingency, from the risk register. Take the three highest-impact risks and cost their response. Suppose that comes to PKR 63,000 — which happens to be 15% of labour, but the percentage is an output of the analysis, not an input.

Step 5 — Add management reserve. Assume 10% of labour plus non-labour, controlled by the sponsor: 50,000.

Step 6 — State the estimate.

Component Amount (PKR)
Labour 420,000
Non-labour 80,000
Subtotal 500,000
Contingency (known risks) 63,000
Management reserve (unknown work) 50,000
Total 613,000

Step 7 — State the assumptions in the same breath. "Estimates cover the submission capability only, with the scope in the Module 05 WBS, at a blended rate of PKR 20,000 per person-day and an assumed productivity factor of 0.8. Excludes ongoing hosting beyond launch." An estimate without its assumptions cannot be re-used or challenged.

Step 8 — Report a range, not a point. "PKR 590,000 to 680,000 depending on the security review outcome." The range is the estimate; 613,000 is its centre.

Common misconceptions

“A more precise number is a better estimate”

Precision is not accuracy. "PKR 613,000" is not better than "PKR 590,000–680,000" if the second is honest about what is unknown — it is merely more likely to be treated as a promise.

“Contingency is padding”

Padding is an unexamined addition. Contingency is the priced response to risks you have identified and written down. One is hidden; the other is auditable, and can be reduced by reducing risk.

“Estimates should be made by managers”

The people doing the work have the most relevant information. Managers should challenge and aggregate estimates, not invent them — an estimate imposed from above is a target wearing an estimate's clothes.

Practical activity

Build a cost model. For one release of an example project:

  1. Convert your activity estimates into effort, then into paid person-days, stating your productivity assumption.
  2. List non-labour costs with a basis for each figure.
  3. Identify three risks from your Module 08 register (or draft three) and cost their responses to produce contingency.
  4. Separate management reserve and state what it is for.
  5. Present the total as a range with assumptions written directly beneath it.

What "good" looks like: every number traceable to a basis, the assumptions stated as prominently as the total, a range rather than a point, and contingency derived from risks rather than chosen as a round percentage.

Self-assessment

  1. Give two reasons software estimation is harder than construction estimation, and explain each.
  2. What is the practical difference between contingency and management reserve?

  3. A team is told it must deliver in eight weeks. The estimate was twelve. How should this be handled?

  4. Apply it — e-commerce platform. At concept stage you are asked for “a number” to put in next year's budget. There are no requirements, the team has not been hired, and the payment provider has not been chosen. The figure will be read as a commitment.

    Hint: A strong answer says what precision is justified, what the figure is built from, and how the uncertainty is presented.

Show answers
  1. Uniqueness: each system differs in ways that are not visible from the outside, so analogy to previous work is weak. Invisible progress: you cannot inspect a partly built system and see the fraction complete, so estimates cannot be corrected by observation. A third accepted answer is the human factor — estimates becoming targets, which changes behaviour.
  2. Contingency covers risks already identified and priced, and is controlled by the project manager. Management reserve covers work nobody anticipated, such as scope changes, and is controlled by the sponsor. Keeping them separate is what allows "this is a change" to be distinguished from "this is an overrun".
  3. Record all three numbers — estimate twelve, target eight, and the gap of four. Then choose how to close the gap: cut scope, add resources, accept a later date, or accept lower quality — and make the choice explicit and sponsored. Compressing the estimate to eight removes the decision rather than making it, and guarantees the discrepancy reappears as an overrun.
  4. Give a range with a basis and stated assumptions, not a point: for example eight to sixteen person-months for the first release, built from analogous projects, and stated with the assumptions that would move it — which payment provider, how much catalogue data has to be migrated, how many existing customer records must be imported. Say plainly what precision is justified: at concept stage the honest precision is an order of magnitude, and a single number would be false precision. Separate the parts: labour, non-labour, contingency for identified risks, and a management reserve for the unidentified ones, each with an owner — contingency belongs to the project manager, reserve to the sponsor. Finally, name which of the three things you are giving: an estimate (yours, revisable with evidence), a target (the business's aspiration), or a commitment (a promise with consequences). Only the third needs the sponsor's signature, and it needs requirements first.

Summary

  • Estimation is difficult because software is largely unique, progress is invisible, and estimates change behaviour.
  • Precision should track knowledge; early estimates belong in ranges.
  • Estimate, target, and commitment are different things with different owners.
  • A cost model includes labour, non-labour, contingency for known risks, management reserve for unknown work, and the cost of operating the product.
  • Always state assumptions and a range, not a bare number.

Further learning

Next

Continue to Lesson 2 — Estimation Techniques.