The Discipline of Delivery · companion to Chapters 5 & 6
WBS, Scheduling & Critical Path
Decomposition to the 100% rule, three-point estimation, dependency types, float and the chain that governs your date.
WBS, Estimation, Scheduling & Critical Path — Mastery
From "what needs to be delivered" to work packages, estimates, milestones, and the path that decides your finish date.
How this fits with the EVM tutorial. This is the layer that comes before EVM. You can't compute Planned Value without a scheduled, estimated, budgeted work breakdown. Build this first — WBS → estimates → schedule/critical path — then EVM tracks performance against it.
🧭
The decomposition ladder
Every good schedule starts as a chain, not a list
Teams that jump straight from "requirements" to "a task list in Jira" build fragile schedules — things get missed, estimates are gut-feel, and nobody can say why a date moved. The fix is a strict decomposition chain: each level is fully explained by the level above it, and nothing above is left un-broken-down.
| Level | Answers | Example (patient-portal project) |
|---|---|---|
| Scope statement | What are we building, and what's explicitly out? | "A patient-facing web portal for appointment booking and records access; excludes billing." |
| Deliverable | What tangible outcome proves a chunk of scope is done? | Appointment booking module; Records viewer module; Auth & identity module |
| Work package | The smallest deliverable chunk you'll estimate, cost, schedule, and assign to one owner | "Build appointment search & slot-booking API" |
| Activity / task | The individual steps a person actually does day-to-day | "Design slot-locking schema", "Write booking endpoint", "Write integration tests" |
The WBS covers the top three levels (scope → deliverable → work package). Activities/tasks are what you sequence and estimate to build the schedule. Mixing these levels up — e.g. trying to schedule at the "deliverable" level — is the single most common planning mistake.
100%
The WBS must capture 100% of scope — no more, no less. Anything not in the WBS is not in the project.
8/80
Rule of thumb: a work package should take roughly 8 to 80 hours — big enough to be worth tracking, small enough to estimate accurately.
1 owner
Every work package has exactly one accountable owner — shared ownership is how work packages silently stall.
🔁
Why the order matters
Each step feeds the next — skip one and everything downstream is guesswork
1. Decompose scope into work packages (WBS) → 2. Estimate effort/duration/cost per work package → 3. Sequence activities with dependencies → 4. Schedule them on a calendar with resources → 5. Find the critical path to know your real finish date → 6. Baseline it, then track with EVM.
🧩
What a WBS actually is
A deliverable-oriented hierarchy, not a to-do list
A Work Breakdown Structure is a hierarchical decomposition of the total scope of work into smaller, manageable pieces, organised around deliverables — not phases, not people, not chronology. A common trap: PMs build an "activity-oriented" WBS that looks like a project plan (Design, Build, Test, Deploy). That's a schedule wearing a WBS costume — it tells you nothing about what's actually being delivered.
Decomposition approaches
| Approach | Organised by | Best for |
|---|---|---|
| Deliverable-based | Major product components | Product builds — the PMI-recommended default |
| Phase-based | Lifecycle stages | Regulated / contractual projects with gated phases |
| Hybrid | Deliverables at top, phases inside each | Most real software projects |
📏
The two governing rules
Break both and the WBS is broken
The 100% rule
The WBS includes 100% of the work defined by the scope — including project management itself — and nothing that isn't in scope. Child elements at each level must sum to exactly their parent; no gaps, no overlaps.
The 8/80 rule
A work package shouldn't be smaller than ~8 hours (not worth separately tracking) or larger than ~80 hours / one reporting period (you'd lose visibility until it's nearly done). Split anything bigger.
The WBS dictionary — the part everyone skips
The tree alone is ambiguous. Every work package needs a one-line entry defining: ID, description, owner, acceptance criteria, estimated effort/cost, and dependencies. Without this, two people read the same box on the tree and imagine two different deliverables.
Good WBS habits
Nouns, not verbs — "Booking API", not "Build the booking API"
Decompose until a single owner can estimate it confidently
Include non-obvious scope: PM overhead, documentation, environment setup
Common mistakes
Decomposing to different depths across branches for no reason
Making it a task list ordered by time (that's the schedule's job)
Skipping the dictionary — the tree without definitions invites scope disputes
🌳
Worked example — patient portal WBS
Deliverable-based, numbered, three levels deep
1.0Patient Portal Project
1.1Project Management
1.1.1Planning & governance
1.1.2Status reporting & RAID log
1.2Auth & Identity Module
1.2.1SSO integration
1.2.2MFA enrolment flow
1.3Appointment Booking Module
1.3.1Slot search & booking API
1.3.2Booking confirmation & reminders
1.4Records Viewer Module
1.4.1Records read API
1.4.2Document viewer UI
1.5Deployment & Cutover
1.5.1UAT & sign-off
1.5.2Production go-live
1.3.1 "Slot search & booking API" is a work package — the level you'll estimate, assign, and schedule. Below it, in the schedule (not the WBS), it decomposes further into activities like "design schema", "build endpoint", "write tests".
📐
Estimation techniques
Pick the technique that matches how much you actually know right now
| Technique | How it works | Use when |
|---|---|---|
| Analogous | Scale from a similar past project's actuals | Very early, little detail — rough order of magnitude |
| Parametric | Rate × quantity (e.g. $/line of code, hours/screen) | You have a reliable historical unit rate |
| Three-point / PERT | Weighted average of optimistic, most likely, pessimistic | Meaningful uncertainty per task; you want a confidence range |
| Bottom-up | Estimate every work package, sum upward | WBS is mature enough — most accurate, most effort |
| Expert judgment | Ask the people who'd actually do the work | Always — combine with any technique above |
| Relative sizing | Story points / T-shirt sizes vs. a reference task | Agile teams; effort is more knowable than duration |
Accuracy ranges by project phase (PMI convention)
Order of magnitude
Early concept stage.
-25% / +75%
-25% / +75%
Budget estimate
Scope roughly defined.
-10% / +25%
-10% / +25%
Definitive
WBS & design mature.
-5% / +10%
-5% / +10%
Never present a number without its range. "$400K" invites a promise; "$400K, -10%/+25%, definitive-stage" invites a decision.
🎲
Three-point (PERT) estimating — the formula
Turns "how long will it take?" into a number with honest uncertainty attached
For each activity, get three numbers from whoever will do the work: Optimistic (best case), Most likely, Pessimistic (worst realistic case, not "asteroid strike"). PERT weights the most-likely case 4× because extremes are, by definition, less probable.
Expected duration
E = (O + 4M + P) / 6
Standard deviation
SD = (P − O) / 6 — your uncertainty band
Worked example: a "booking API" task — O = 3 days, M = 5 days, P = 12 days.
E = (3 + 4×5 + 12) / 6 = 35 / 6 = 5.8 days. SD = (12 − 3)/6 = 1.5 days.
Report it as 5.8 days, roughly ±1.5 — not a bare "6 days," which hides that the true worst case is 12.
E = (3 + 4×5 + 12) / 6 = 35 / 6 = 5.8 days. SD = (12 − 3)/6 = 1.5 days.
Report it as 5.8 days, roughly ±1.5 — not a bare "6 days," which hides that the true worst case is 12.
Reduces estimation bias
Ask the person doing the work, not their manager
Use a real, documented past project for analogous estimates
Add a contingency reserve sized to known unknowns (from risk register)
Common bias traps
Planning fallacy — assuming this task will go better than every similar past task
Anchoring — the first number said in the room becomes everyone's estimate
Confusing effort (person-hours) with duration (calendar time, availability-adjusted)
Contingency reserve covers known unknowns — risks you identified on the risk register (e.g. "third-party API might need extra integration work"). It's added to specific estimates and the PM controls it directly.
Management reserve covers unknown unknowns — things nobody could have foreseen. It sits above the project budget, and drawing on it usually needs sponsor approval. Mixing the two hides how much real contingency you have left.
Management reserve covers unknown unknowns — things nobody could have foreseen. It sits above the project budget, and drawing on it usually needs sponsor approval. Mixing the two hides how much real contingency you have left.
📅
Milestones — the markers that matter
Zero-duration events, not deliverables in disguise
A milestone marks a significant point in time — it has zero duration and consumes no resources itself. Its job is to make progress visible to people who don't read Gantt charts: sponsors, steering committees, contract counterparties.
Good milestones
"UAT sign-off complete" — binary, verifiable, dated
Tied to a payment trigger or contractual gate
Placed at the end of a phase or major dependency
Bad milestones
"Development 50% complete" — not binary, not verifiable
So frequent (weekly) they lose signal value
Defined without an owner who can confirm they're met
🔗
Dependency types
How one activity's timing constrains another's
| Type | Meaning | Example |
|---|---|---|
| Finish-to-Start (FS) | B can't start until A finishes — the default, ~90% of dependencies | Can't test the API until it's built |
| Start-to-Start (SS) | B can't start until A starts | Documentation can start once coding starts |
| Finish-to-Finish (FF) | B can't finish until A finishes | QA sign-off can't close until dev closes |
| Start-to-Finish (SF) | B can't finish until A starts — rare | Old system can't be shut down until the new one starts |
Lag
Forced delay after a dependency is satisfied. "Concrete cures 2 days after pouring before framing starts."
Lead
Overlap that pulls a successor forward. "UI design can start 3 days before backend design finishes."
Every dependency should be classified as mandatory (physically required), discretionary (best-practice sequencing, could be reordered), or external (outside the team's control, e.g. vendor delivery). Discretionary dependencies are your flexibility when you need to compress the schedule.
🏗️
Building the schedule, in order
1. Decompose work packages into activities → 2. Sequence them with dependency types → 3. Estimate duration per activity (§Estimation) → 4. Assign resources and apply calendars (holidays, part-time availability) → 5. Run the network through the Critical Path Method → 6. Place milestones at natural checkpoints → 7. Baseline it before work starts.
🎯
What the critical path actually is
The longest path through the network — and the only one with zero slack
With many activities running in parallel, some paths through the network are shorter than others. The critical path is the longest chain of dependent activities from start to finish — it determines the minimum possible project duration. Delay any activity on it by a day, the whole project slips a day. Delay an activity not on it, and nothing happens — up to a point (its float).
The Critical Path Method (CPM), step by step
| Step | What you compute | Formula |
|---|---|---|
| Forward pass | Earliest Start / Earliest Finish per activity, left to right | EF = ES + duration; ES of a successor = max(EF of predecessors) |
| Backward pass | Latest Start / Latest Finish, right to left from the project end | LS = LF − duration; LF of a predecessor = min(LS of successors) |
| Float | Slack each activity has before it delays the project | Total Float = LS − ES (= LF − EF) |
| Critical path | The chain where Total Float = 0, start to finish | — |
🧮
Worked example, fully solved
A diamond network — two parallel paths that converge
Network: A → {B, C} in parallel, B → D, C → E, then D and E both feed F (the finish). Durations in days: A=2, B=5, C=3, D=4, E=5, F=2.
| Activity | Dur. | ES | EF | LS | LF | Float |
|---|---|---|---|---|---|---|
| A | 2 | 0 | 2 | 0 | 2 | 0 |
| B | 5 | 2 | 7 | 2 | 7 | 0 |
| C | 3 | 2 | 5 | 3 | 6 | 1 |
| D | 4 | 7 | 11 | 7 | 11 | 0 |
| E | 5 | 5 | 10 | 6 | 11 | 1 |
| F | 2 | 11 | 13 | 11 | 13 | 0 |
Critical path = A → B → D → F, total duration 13 days (highlighted). Path A→C→E→F is 12 days — one day of float. If C or E slips by up to 1 day, the project still finishes on day 13. If B slips even half a day, the whole project slips.
Try it yourself with your own durations in the Calculator tab — same network, editable numbers.
⚡
Compressing the schedule & why float matters
Crashing
Add resources to critical-path activities to shorten them — costs more money, only works on the critical path. Crashing a non-critical activity is wasted spend.
Fast-tracking
Run activities in parallel that were originally sequential (e.g. start build before design is 100% signed off) — adds rework risk instead of cost.
Float on non-critical paths is your resource-levelling buffer — move people off slack activities temporarily to help the critical path without changing the finish date. Watch for near-critical paths (1–2 days of float): a small slip turns them critical, so treat them with almost the same discipline.
🎲
Three-point (PERT) estimate calculator
Units are whatever you're estimating in (days, hours). Formula: E = (O+4M+P)/6, SD = (P−O)/6.
Result
5.8
Expected duration (E)5.83
Standard deviation (SD)1.50
~68% confidence range (±1 SD)4.33 – 7.33
~95% confidence range (±2 SD)2.83 – 8.83
🔗
Critical path calculator
Same diamond network from the worked example — change durations and watch the critical path move
Network: A → (B, C) → B→D, C→E → (D, E) → F
| Activity | Dur. | ES | EF | LS | LF | Float |
|---|
Result
Project duration13 days
Critical pathA → B → D → F
🧠
Test yourself
0 / 8
Running a project that is slipping? Book a 30-minute delivery review with Siva: we look at your plan, your numbers and the one thing to fix first.
Companion to Chapters 5 & 6 of The Discipline of Delivery by Siva Prasad. Read the chapter to understand why the discipline matters, then use this guide to practise the how.