2.2Estimating effort & durations
The essentials in 30 seconds
- Effort ≠ duration: effort is work (person-days), duration is calendar time — 4 person-days by 2 people doesn't mean 2 days.
- Techniques: analogy (past projects), expert judgment, three-point estimation (optimistic / likely / pessimistic).
- Reflex: an estimate is not a certainty — plan margins and communicate a range.
Running mini-case — Bilal stops confusing effort and deadline
Bilal estimated "two weeks" for the tracking tool, without saying whether he meant effort or calendar time — with a half-time developer, the real lead time doubles. He retakes each WBS package: effort in person-days first, duration next given availability, and three-point estimation on uncertain packages. His deadlines become defensible.
Sequel to case 2.1 — Bilal costs the work identified in his WBS.
1. Effort ≠ duration
Once work is identified (WBS), it must be estimated: how much effort (effort, in person-days) and how much time (duration) each task will take. It is one of the trickiest exercises — all scheduling and budgeting flows from it.
A 4 person-day task done by 2 people does not necessarily last 2 days (coordination, availability). Bilal learns it with his half-time developer: estimated effort must be confronted with real availability.
2. Techniques and uncertainty
Several techniques: analogy (comparing with a past project), expert judgment, or three-point estimation (optimistic, most-likely, pessimistic) factoring in uncertainty.
Key point: an estimate is not a certainty. Acknowledging it as such — and planning margins — avoids many disappointments. Bilal now communicates a range ("6 to 8 weeks") rather than false precision.
🔎 Concrete example — 🔎 Concrete example — Optimism bias
Why we underestimate.
We forget contingencies, coordination, rework.
Remedies: past-project data, 3-point estimation,
have doers estimate, add a reserve.
→ communicate a range ("6 to 8 weeks"), not "47 days".Outcome: credible foundations for schedule and budget.
Reflex: note each estimate's confidence level.
Section vocabulary
- Effort
- Amount of work needed, in person-days (or hours). Distinct from duration.
Simple example: The tracking tool estimated at 10 person-days of effort.
What it is not: "two calendar weeks", which is a duration.
Reflex: always estimate effort before calendar time.
- Duration
- Calendar time to deliver a task. Depends on effort AND assigned resources and their availability.
Simple example: 10 person-days with a half-time developer last far more than 10 days.
What it is not: effort itself, independent of availability.
Reflex: convert effort → duration via real availability.
- Analogy estimation
- Estimating from similar past projects/tasks (fast, but depends on comparability).
Simple example: Bilal reuses the SME's previous site real efforts.
What it is not: inventing a figure with no lived reference.
Reflex: find the closest past project before estimating.
- Three-point estimation
- Combining optimistic, most-likely and pessimistic values (often via PERT) to factor in uncertainty.
Simple example: On the tracking tool: 8 days if all goes well, 12 most likely, 20 if it sticks.
What it is not: announcing one single precise date when uncertainty is high.
Reflex: on every uncertain package, give three values, not one.
- Uncertainty
- Error margin inherent to any estimate. The newer/more complex the project, the bigger.
Simple example: The tool part, new to the team, has a wide range.
What it is not: a certainty: the right estimate first time.
Reflex: note each estimate's confidence level.
In practice — In practice — Estimating effort and durations
- For a few WBS packages, estimate effort (person-days) with the most fitting technique (analogy, expert).
- Tell effort and duration apart: a 4 person-day task done by 2 people does not necessarily last 2 days (coordination, availability).
- On uncertain tasks, apply 3-point estimation (optimistic/likely/pessimistic) to objectify the margin.
- Own uncertainty: note each estimate's confidence level and plan a reserve (see budget, 2.6).
Ready-to-say script — asking for a three-point estimate (1 min)
"For this package, give me three figures: if all goes well, most likely, and if it sticks. Plus your confidence level. We'll announce a range to the sponsor, not a date carved in stone."
Say to each estimating team member: three values + confidence, never one single figure.
Copy-paste template — per-package estimation sheet
PACKAGE (WBS): _______________
EFFORT (person-days, via analogy/expert): _______________
AVAILABLE RESOURCES: _______________
DURATION (calendar time): _______________
3 POINTS (optimistic / likely / pessimistic): ___ / ___ / ___
CONFIDENCE (low / medium / high): _______________Small business / tight budget
With no quantified history: estimate in pairs, compare with the last similar job, keep a record for next time.
Algerian SME
Bilal has doers estimate: the developer costs their package, not the boss — plus the margin for local contingencies (outages, travel).
Remote team
Remote estimation demands writing: noted assumptions, shared range — otherwise everyone understands a different date.
Brand-new / innovative project
Maximum uncertainty: systematic three points, wide owned ranges, mid-course re-estimation planned.
✓ Best practices
- Always tell effort (work) from duration (calendar time) apart.
- Have those who will do the task estimate.
- Communicate a range rather than false precision.
✗ Common pitfalls
- Confusing effort and duration (2 people ≠ mechanically 2× faster).
- Taking an estimate for a certainty (optimism bias).
- Announcing a precise date early, when uncertainty is high.
Key takeaways
- Effort (work in person-days) differs from duration (calendar time).
- Techniques: analogy, expert judgment, 3-point estimation.
- 3-point estimation explicitly factors in uncertainty.
- An estimate is not a certainty: plan margins.
48h Challenge — apply tomorrow
Take 3 packages of your WBS and estimate each in effort then duration, one of them at three points (template above). Compare with the doers.
- I can tell effort (work) from duration (calendar time) apart.
- I can apply three-point estimation on an uncertain package.
- I've estimated 3 real packages with confidence level.
Frequently asked questions
Why are my estimates often too optimistic?
It is a near-universal bias ("optimism bias"): we underestimate contingencies, coordination, rework. Remedies: rely on real past-project data (analogy), estimate at three points, have doers estimate, and add a reserve. We naturally picture the ideal flow, without the frictions that always occur in reality.
Should you give a precise date or a range?
A range is more honest, especially early in the project when uncertainty is high (the "cone of uncertainty" narrowing over time). Communicating an interval ("between 6 and 8 weeks") rather than false precision ("47 days") avoids creating unkeepable expectations. Refine as the project advances and uncertainty shrinks.
Bilal's tool needs 10 person-days but his developer is only half-time available. What must he tell apart?