Scope, Estimation & Scheduling: Counting the Work Before You Count the Days

Ask a team how long a small café will take to open, and someone says five weeks. Ask each person how long their own part takes, add the numbers along the longest chain, and you get thirty-four working days. Then the permits take two days longer, the equipment arrives late, an inspector is booked for the following week, and the opening is in week eight. Nobody lied. The plan counted what would happen if every step went as hoped, and then reality arrived one step at a time.

This piece is about the three things a plan is made of: scope (what exactly is being built), estimates (how long and how much, as ranges) and the schedule (which tasks wait for which, and which chain decides the date). The café is invented; the arithmetic is the real kind that every scheduling tool, from a paper Gantt to project software, does underneath.

Scope: cut the work into pieces that add up

The work breakdown structure (WBS) splits the project's total scope into smaller and smaller deliverables until each piece can be estimated, owned and checked. Its key rule is the 100% rule: the pieces under any parent must add up to all of the parent's scope, nothing missing and nothing extra. Missing pieces become late surprises; extra pieces become unpaid work.

The second rule that experienced managers repeat: a WBS is made of deliverables (things: "tested booking page"), not activities (actions: "test the booking page"). The activities come later, when you plan how and in what order. A thing can be checked as done or not done; "working on it" cannot. Try telling them apart.

Without JavaScript: "Signed lease" and "Tested login page" are deliverables; "Negotiate the lease" and "Test the login page" are activities. A WBS lists the first kind.

Estimating: from one number to a range

There are four ordinary ways to estimate. Analogous: this looks like the last one, which took 40 days. Parametric: use a rate, such as hours per square metre or per screen. Bottom-up: estimate each WBS piece and add. Three-point: for each piece, give an optimistic, a most likely and a pessimistic value. The first two are quick and rough; the third is slow and detailed; the last is the one that admits uncertainty.

The classic three-point formulas come from PERT, developed for the US Navy's Polaris programme in 1958. With optimistic o, most likely m and pessimistic p:

Because pessimistic cases are usually further from "most likely" than optimistic ones, the mean sits above the most likely value. A task with o = 4, m = 6 and p = 14 days has a mean of 7 days and a standard deviation of 1.7. The "most likely" 6 days is not the number to put in the total.

Two cautions. Early estimates are wide: Barry Boehm's 1981 software ranges ran from a quarter to four times the eventual effort at the start of a project, and the range narrows only when you learn something or remove sources of variation, not by waiting. And people's ranges are too narrow: in the thesis study of 36/90 even worst cases were too kind (the planning fallacy). The fix is to ask for ranges before the point, and to compare with similar finished work. Move the sliders below.

Without JavaScript: o = 4, m = 6, p = 14 gives a mean of 7.0 days, a standard deviation of 1.7 days, and about a 73% chance of finishing within 8 days (and 33% for the most likely 6).

Agile teams often estimate in story points: a relative size with no fixed meaning in hours, where a team's velocity is the points it finishes per sprint. Defenders say relative sizing is quick and does not pretend to precision; critics say points get converted back into hours, compared across teams and used as targets, which ruins them. The #NoEstimates movement (associated with people such as Woody Zuill and Vasco Duarte from about 2012) goes further and argues that, for many teams, counting finished items of similar size gives a forecast without any estimating at all. That works best when the items really are of similar size and the work flows steadily, which is the subject of Agile, Scrum & Kanban (36/92).

Dependencies and the critical path

Tasks wait on each other: you cannot inspect the kitchen before it is installed. A network of tasks and their predecessors gives the critical path method, developed at DuPont and Remington Rand in the late 1950s, the same period as PERT. Two sweeps do the work. The forward pass gives each task's earliest start (ES) as the latest earliest finish of its predecessors, and the earliest finish EF = ES + duration. The backward pass goes from the project end backwards and gives the latest finish (LF) and latest start (LS) that still keep the end date. The slack between them is float:

The critical path is every chain of zero-float tasks, and its length is the project's duration. Below is the invented café. Change a duration and watch the table recompute. The critical tasks are marked. Try making "Hire and train staff" 20 days: that task was far from critical (14 days of float), and now it nearly is.

Without JavaScript: with the default durations the critical path is A, B, E, G, H = 10 + 15 + 4 + 3 + 2 = 34 days. Equipment delivery (C) has 3 days of float, staff (D) 14 and menu (F) 16.

This is a purely logical schedule: it assumes that people are free whenever a task becomes ready. They are not.

Gantt charts and resource levelling

A Gantt chart draws each task as a bar on a time axis, named after Henry Gantt, who popularised such charts in the 1910s; the Polish engineer Karol Adamiecki had published a similar "harmonogram" earlier. The chart makes the schedule readable at a glance, but only shows dependencies if you draw them. Its weakness is that it looks more certain than it is.

Resource levelling adjusts the schedule when one person or crew is needed by two tasks at once. In the café, the owner is needed for permits, staff, menu and the opening. The simple rule below delays the task with the most float until the person is free. If the delayed task has float to spare, the end date does not move. If it does not, the project gets longer. Compare the bars.

Without JavaScript: set staff (D) to 20 days in the network. The owner can't do D and menu (F) at once, so F slips to day 30, the opening to day 36 and the project from 34 to 38 days.

The chance that the plan is met

Add up most-likely numbers along the critical path and you get a date that would be a fair 50-50 only if every task were symmetric around its estimate. Real durations are skewed, and several chains run in parallel, so each merge point waits for the slowest one, an effect sometimes called merge bias. The remedy is a Monte Carlo simulation: draw a random duration for every task from its range, run the network, record the end, and repeat thousands of times. The histogram answers "by what date are we 80% sure?", which is the question a sponsor actually has. Below, each task ranges from 85% of its listed duration up to the listed duration plus a bad-day allowance you set. The draws use a triangular shape (a simple stand-in for beta-PERT) and a fixed seed, so you see the same picture every time.

Without JavaScript: with a 50% allowance, the chance of finishing by day 34 is about 4%, even though 34 is the sum of the critical path; the 50-50 point is about day 38.

Critical chain, buffers and human behaviour

Why not just pad every task? Because people use the padding. Parkinson's law (C. Northcote Parkinson, The Economist, 19 November 1955) says "work expands so as to fill the time available for its completion". Student syndrome, a name Goldratt popularised, is starting only when the deadline is close. Both turn hidden padding into waste, while delays are passed on and early finishes are not.

Eliyahu Goldratt's Critical Chain (1997) applies his theory of constraints to projects. It builds the schedule from shorter estimates (roughly ones with a 50% chance of being met), removes the padding from each task and pools part of it in visible buffers: a project buffer at the end and feeding buffers where side chains join the main one. It also schedules around shared people, not only logic, which gives the critical chain instead of the critical path. Progress is then tracked by how fast the buffer is used, not by whether each task hit its date.

A worked number, with the common rule that the buffer is about half of what was removed: the café's five critical tasks add to 34 days. If each hides about half of its time as safety, cutting them to 17 days and pooling half of the 17 removed (8.5) in one buffer promises 25.5 days, with the safety now visible and shared. Critics question the assumptions (that the padding really is half, that people will work to the shorter times and that buffer rules hold up) and the evidence; Raz, Barnes and Dvir reviewed it in 2003. Supporters report faster delivery in projects with heavy resource conflicts. Reasonable people use the part they find useful: visible buffers and honest ranges.

Template: a WBS and estimate sheet

This sheet is a bottom-up estimate in miniature: deliverables in the first column, three numbers each, the mean and spread computed, and a total with an 80% value. Hours are used here, but any unit works. The example is an invented repair-café website. Edit it, copy it as text, and paste it into your own notes. Nothing is stored. The totals assume independent tasks, which is optimistic; shared causes (a late decision, a sick team member) make real totals wider.

Without JavaScript: for each deliverable write o, m and p; the mean is (o + 4m + p) ÷ 6 and the standard deviation (p − o) ÷ 6; the total's standard deviation is the square root of the sum of the squares.

What a graduate just sees

• A WBS lists deliverables, and the pieces under a parent must add up to 100% of it.
• Ask for a range before a point: the mean of a skewed range sits above the most likely value.
• Early estimates are wide, and the range narrows by learning, not waiting.
• The critical path sets the date; float tells you where there is slack and where there isn't.
• A plan made of most-likely durations is usually met much less than half the time, because chains merge.
• Shared people create a schedule the logic diagram doesn't show.
• Hidden padding is eaten by Parkinson's law; visible buffers are one answer, with real critics.

Where it shows up next

• Risk, Cost & Project Control (36/93): Monte Carlo with risk events, contingency, and earned value, which needs a baseline built from this sheet.
• Agile, Scrum & Kanban (36/92): velocity and flow forecasts as an alternative to task-level estimates.
• Operations Management (34/52): the bottleneck idea behind critical chain.
• In the world: a building site's three-week look-ahead, a software release train, a film shooting schedule, a school's exam timetable.

If you want to go deeper

• 📘 Textbooks. Steve McConnell, Software Estimation: Demystifying the Black Art (Microsoft Press, 2006), useful far beyond software; and Meredith, Mantel and Shafer, Project Management: A Strategic Managerial Approach, a standard university text.
• 📘 Gentler. Eliyahu Goldratt, Critical Chain (1997), a novel that teaches buffers; and Flyvbjerg and Gardner, How Big Things Get Done (2023), on estimates and reference classes.
• 🌐 Free course. MIT OpenCourseWare 1.040, Project Management (Spring 2009), lecture notes on planning and scheduling for infrastructure.