SE423 · Software Project Management · Chapter 08
Scheduling and Tracking:
the map, and proof you followed it.
A schedule is a promise with dates on it. This chapter is about making that promise honestly — breaking work down (WBS), figuring out what depends on what (network diagrams), finding the one sequence of tasks that controls your deadline (the critical path), and then, once the project is running, proving with numbers — not vibes — whether you're actually on track (Earned Value).
WBS → Network → CPM → PERT
Worked critical-path example
Brooks's Law
Earned Value (PV/EV/AC/CPI/SPI)
§ 01 — THE CONTINUUM
Planning → Estimating → Scheduling → Tracking
Schedule development is not a single step — it's the culmination of Project Time Management: activity definition, activity sequencing, activity resource estimating, and activity duration estimating, all feeding one iterative process.
🧭
Memory hook
"Plan it, Estimate it, Schedule it, Track it."
Each word adds one more piece of precision to the last. Plan = what
(no dates yet). Estimate = how much (size/duration, still no dates). Schedule =
when (adds start/end dates, dependencies, resources). Track = how honest was the
plan (uses monitoring to check reality against it).
Plan
Identify activities — no dates yet
Just the checklist of what must happen. No commitments on when.
Estimate
Determine the size & duration of activities
How big is each piece of work? Still no calendar dates attached.
Schedule
Adds specific start/end dates, dependencies, and resources
This is where the network diagram, CPM, and PERT live.
Track
Uses monitoring and tools to check accuracy
Determines whether the plans, estimates, and schedule are actually holding up. This is where Earned Value lives.
How to schedule — the 4-step recipe
1. Identify "what" needs to be done → WBS
2. Identify "how much" (the size) → size estimation techniques
3. Identify dependency between tasks → dependency graph / network diagram
4. Estimate total duration → the actual schedule
2. Identify "how much" (the size) → size estimation techniques
3. Identify dependency between tasks → dependency graph / network diagram
4. Estimate total duration → the actual schedule
Controlling factors in schedule development
Project scope statement is the source of assumptions (PMI: schedule-related
factors considered true/real/certain) and constraints (factors that limit the PM
team's options during network analysis, e.g. "only use internal HR"). Date constraints
and milestones matter most.
Project management plan — nearly every sub-plan can influence scheduling, but the risk register and risk-associated plans are the most critical influence.
Project management plan — nearly every sub-plan can influence scheduling, but the risk register and risk-associated plans are the most critical influence.
§ 02 — WORK BREAKDOWN STRUCTURE
WBS: the checklist that everything else is built on
The WBS lists the major project outputs and the departments/individuals primarily responsible for them — a hierarchy from Level 1 (whole project) down to individual Tasks.
🌳
Memory hook — the WBS hierarchy
"Project → Function → Activity → Task"
Function: a management activity often spanning the whole project
life (project management, risk management, change management). Activity: an
element of work with expected duration/cost/resources — can be subdivided further.
Task: the lowest level of work in the real schedule — typically too granular to
show on a preliminary WBS.
WBS Types (three flavors)
| Type | Also called | Used by / example |
|---|---|---|
| Process WBS | Activity-oriented | PM; e.g. Requirements, Analysis, Design, Testing |
| Product WBS | Entity-oriented | Engineering manager; e.g. Financial engine, Interface system |
| Hybrid WBS | Both combined | Lifecycle phases at high level, component/feature detail within — not unusual, since processes produce products |
Process WBS rules of thumb
List of activities, not things. Items can come from the SOW (statement of work),
proposal, brainstorming, stakeholders, team.
Describe activities using "bullet language" — meaningful but brief labels.
All WBS paths do not have to go to the same level. Do not plan more detail than you can manage.
Describe activities using "bullet language" — meaningful but brief labels.
All WBS paths do not have to go to the same level. Do not plan more detail than you can manage.
WBS Techniques
how to actually build one🏗️
Memory hook
"Top Bosses Ask Really Boldly"
Top-Down · Bottom-Up · Analogy · Rolling
Wave · Brainstorming — and all five rely on Expert Judgment.
| Technique | How it works | Best when |
|---|---|---|
| Top-Down | Start at the overall goal/deliverable, break into major components then subcomponents. Start at the highest level, systematically increase detail. | Problem well understood; technology/methodology not new; similar to an earlier project — but applied in the majority of situations anyway. |
| Bottom-Up | Start by identifying detailed tasks, then group into higher-level categories/summaries. | Pro: detailed. Con: time consuming, needs requirements to be more complete. |
| Analogy | Use a WBS from a similar past project as a template, adapt to current context. | Pro: based on past actual experience. Con: needs a comparable project. |
| Rolling Wave | Plan at a high level initially, add detail as more information becomes available. 1st pass: 1–3 levels deep → gather more requirements/data → add detail later. | Early phases of a project, or long projects where later detail can't be known yet. |
| Brainstorming | Generate every activity you can think of, then group into categories. | Can be combined with Top-Down on the same WBS. Get the people who'll do the work involved — buy-in matters. |
Work Packages (Tasks) — sizing rules
Generic term for a discrete unit of work with definable end results — the basis for
monitoring & reporting progress (can tie to budget/charge numbers, has resources
assigned).
The "1-to-2" rule: often sized for 1–2 persons for 1–2 weeks.
The "4/40" or "8/80" rule: shortest/longest duration — size from 4 to 40 hours to avoid micromanagement, or up to 80 max to ensure visibility.
Ideally shorter rather than longer — longer packages need subjective in-progress estimates, which are less trustworthy than a clean "done."
The "1-to-2" rule: often sized for 1–2 persons for 1–2 weeks.
The "4/40" or "8/80" rule: shortest/longest duration — size from 4 to 40 hours to avoid micromanagement, or up to 80 max to ensure visibility.
Ideally shorter rather than longer — longer packages need subjective in-progress estimates, which are less trustworthy than a clean "done."
WBS Guidelines
Should be easy to understand. Some companies standardize schemes (e.g. Project Mgmt. is
almost always a top-level item). What often hurts most is what's missing. Break
down until you can generate accurate time & cost estimates. Ensure each element
corresponds to a deliverable.
WBS is the basis for: network
scheduling, costing, risk analysis, organizational structure, control, and measurement.
§ 03 — NETWORK ANALYSIS
Turning dependencies into a diagram
Network analysis is the technique that generates the project schedule. It may combine several methods: Gantt Charts, the Critical Path Method (CPM), the Critical Chain Method (CCM), what-if analysis, and resource leveling. The Precedence Diagram Method (PDM) is the graphical network technique used to establish activity sequencing.
Terminology
get these exact — exam-testedActivity. Always consumes time, may also consume resources
(task and activity are used equivalently).
Critical. A critical activity/event
must be achieved by a certain time — it has no latitude (slack/float).
Critical path. The
longest path through a project network. Because it has no slack, all
activities on it must complete as scheduled or the end date slips.
Events. The beginning and ending points of activities — a
specific point in time.
Milestone. An event representing a
point of special significance in a project — usually completion of a major phase.
Project reviews are often conducted at milestones.
⏳
Memory hook
"Longest path wins — and it never gets a day off."
The critical path is the longest, not the most important-looking,
path. It has zero slack by definition — that's the whole test for whether a task is on
it.
Creating a precedence table
Documents task durations and interdependencies. Include a duration estimate per task —
any risky task (technology, skills, dependencies) should carry a contingency
factor. Determine predecessor/successor relations as a team effort — this also
surfaces possible parallel tasks that can shorten the schedule.
Sample precedence table
| Task | Duration | Dependencies |
|---|---|---|
| A — Architecture & design strategy | 9 | start |
| B — Decide on number of releases | 5 | A |
| C — Develop acceptance test plan | 7 | A |
| D — Develop customer support plan | 11 | B, C |
| E — Final sizing & costing | 8 | D |
A graphic model portraying the sequential relationship between key events — it communicates the plan of action to the team and the client clearly and precisely. This exact table/diagram is reused as the running example for PERT and CPM below.
§ 04 — PERT ESTIMATION TECHNIQUE
Three numbers instead of one guess
Program Evaluation & Review Technique (PERT) was developed to handle uncertainty in activity durations, by asking for three time estimates instead of a single confident (and usually wrong) one.
📐
Memory hook
"Optimist once, Realist four times, Pessimist once — divide by six."
The most likely time gets 4x the weight of the optimistic or
pessimistic ones. That's why the denominator is 6 (1 + 4 + 1).
TE = (Eoptimistic + 4·Emost likely + Epessimistic) / 6
TE = PERT activity duration estimate (expected time)
sE = (Epessimistic − Eoptimistic) / 6
standard deviation — measures the uncertainty / variability in the
estimate. (Standard deviation itself is a statistical metric for how spread out data points
are from the mean.)
The three estimate points
Most likely (M): the estimate that occurs with greatest frequency.
Optimistic (O): shortest duration — taken as the 10th percentile value.
Pessimistic (P): longest duration — taken as the 90th percentile value.
Optimistic (O): shortest duration — taken as the 10th percentile value.
Pessimistic (P): longest duration — taken as the 90th percentile value.
Worked example (from the slides)
Activity R→S has O=2, M=4, P=5.
TE = (2 + 4×4 + 5) / 6 = 23 / 6 = 3.8
TE = (2 + 4×4 + 5) / 6 = 23 / 6 = 3.8
Numbered rectangles/nodes = events or milestones. Directional arrows = dependent tasks that must
complete sequentially. Diverging arrows from one node (e.g. 1→2 and 1→3) = possibly concurrent
tasks. Dotted lines = a "dummy activity" — a dependency that does not require resources or
time, used purely to preserve correct network logic (e.g. showing that "user test" needs both
"training" and "conversion" done, without drawing a real task for it).
§ 05 — CRITICAL PATH METHOD (CPM)
Forward pass, backward pass, and the zero-slack test
CPM calculates theoretical start/finish dates for every activity without regard for resource limitations — which can cause resource over-allocation or inefficient multitasking (that gap is exactly what the Critical Chain Method fixes later).
Forward pass vs. backward pass
Forward pass: schedule calculations that identify the early start (ES) and
early finish (EF) dates of activities and the project.
Backward pass: schedule calculations that identify the late start (LS) and late finish (LF) dates, plus total and free float.
Backward pass: schedule calculations that identify the late start (LS) and late finish (LF) dates, plus total and free float.
Total float vs. free float
Total float (TF): how long an activity can be delayed without delaying the
whole project. Global to the project.
Free float (FF): how long an activity can be delayed without delaying its successor activities. Local to the activity's neighborhood.
Free float (FF): how long an activity can be delayed without delaying its successor activities. Local to the activity's neighborhood.
🎯
Memory hook
"Slack = wiggle room. Zero slack = no wiggle room = critical."
Slack time (float) = the amount of delay tolerable in an activity's
start/finish without delaying project completion. Slack = LF − EF (or LS − ES). The
sequence of activities with zero slack is, by definition, the critical path.
If a non-critical activity (slack > 0) gets delayed past its late finish, it
becomes critical and the completion date slips.
Same network as §03 (A=9, B=5, C=7, D=11, E=8; B and C both depend on A; D depends on both B and C; E depends on D).
| Task | Duration | Depends on | Early Start | Early Finish | Late Start | Late Finish | Slack |
|---|---|---|---|---|---|---|---|
| A | 9 | none | 0 | 9 | 0 | 9 | 0 |
| B | 5 | A | 9 | 14 | 11 | 16 | 2 |
| C | 7 | A | 9 | 16 | 9 | 16 | 0 |
| D | 11 | B, C | 16 | 27 | 16 | 27 | 0 |
| E | 8 | D | 27 | 35 | 27 | 35 | 0 |
Reading the table: D can't start until both its predecessors finish, so its Early
Start = max(B's EF=14, C's EF=16) = 16 — the later branch wins. Working backward from the
project end (35), only B has room to slip (2 units) before it would force D to start late.
Critical Path = A – C – D – E (35 time units total) · Critical Tasks = A, C, D, E · Non-critical path = A-B-D-E · Non-critical task = B only (2 units of slack time).
Critical Path = A – C – D – E (35 time units total) · Critical Tasks = A, C, D, E · Non-critical path = A-B-D-E · Non-critical task = B only (2 units of slack time).
What CPM answers: (1) What is the duration of the project? (2) By how much will the
project be delayed if any one activity takes N days longer? (3) How long can certain activities
be postponed without increasing total project duration?
§ 06 — GANTT CHARTS
The chart everyone reads, the chart that hides dependencies
A Gantt Chart (named for Henry Laurence Gantt) is a table of task information plus a horizontal bar chart showing schedule against time — used constantly for planning and tracking, but with real limits.
Advantages
Easy to understand. Easy to change. Can show planned vs. actual
progress and task dependencies.
Disadvantages
Very low information density — lots of wasted space, not very useful
for large projects. Only a vague description of the project. Does not always show
interdependency of activities, and may not reveal the results of an early or late start.
A, B, C, D, E. A and B have no preceding activities. C requires B complete first. D
cannot start until both A and B are complete. E requires both A and C complete.
Durations: A=9, B=3, C=9, D=5, E=4. Question: what's the shortest time to complete the
project, and which activities are critical?
Without a graphical picture of the dependencies, you cannot identify the critical path
from the duration list alone — this is exactly why network diagrams exist, not just Gantt bars.
Working it out: A runs 0–9. B runs 0–3. C (needs B) runs 3–12. D (needs A & B, so starts at
max(9,3)=9) runs 9–14. E (needs A & C, so starts at max(9,12)=12) runs 12–16.
Total time = 16 days. Critical chain = B → C → E (3+9+4=16); A and D both finish
early and carry slack.
Task
1-45-89-1213-16
A (9d)
B (3d)
C (9d)
D (5d)
E (4d)
Gold bars = the
critical chain (B→C→E, 16 days). Blue bars = non-critical, they carry slack.
§ 07 — CRITICAL CHAIN METHOD (CCM)
CPM's sequel: now with actual resource limits
The Critical Chain Method improves on CPM by accounting for resource availability — CPM computes dates as if every resource were infinitely available, CCM does not.
Core idea
CCM focuses on the resources required for activities, trying to keep them leveled
throughout the project. It assumes all activities have a statistically-probable
range of durations, and uses that to build a more flexible, resilient schedule.
Resources are assigned using most likely durations. The longest resource-constrained
sequence of activities is called the critical chain (vs. the resource-blind
critical path in CPM).
Worked scenario (mobile app, 6-month timeline)
1. Identify critical tasks — e.g. UI development, external API integration,
testing. 2. Estimate task duration, accounting for potential delays. 3. Create
a buffer at the end of the timeline to protect the deadline even if some tasks run
long. 4. Manage the critical chain — reallocate resources, adjust priorities as
needed. 5. Monitor progress continuously and adjust the plan.
🛡️
Memory hook — the three buffer types
"Please Feed Resources"
Project buffer (contingency for the whole project, inserted
at the very end — a delay in the longest path eats into this) · Feeding buffer
(inserted where a non-critical chain feeds into the critical chain, so upstream
slippage doesn't touch the critical chain) · Resource buffer (alerts/placeholders
ensuring critical resources are ready exactly when needed).
Tasks are sequenced to avoid resource conflicts (no multitasking),
ensuring shared resources aren't double-booked — that resource-awareness is CCM's entire reason
for existing over plain CPM.
§ 08 — REFINING THE SCHEDULE MODEL
What-if analysis, resource leveling, leads & lags, calendars
What-if analysis
A scenario-based analysis of the schedule to determine the effect of various scenarios
on the project — e.g. delaying delivery of a critical component by various amounts, or
asking "what if the COTS supplier can't provide it at all?" The most common technique
uses Monte Carlo simulation to generate a population of possible schedule
outcomes — like running the same project 10,000 times with the same resources, different
boundary conditions, and no memory between runs. Very useful for contingency and risk
response planning.
Resource leveling
Applied to a schedule already analyzed by CPM, to address resource availability being
constrained by time or amount, or to keep resource usage constant. Needed when resources
are over-allocated or double-booked. May change the critical path in the schedule
model. Approaches: assign under-allocated resources to multiple tasks; move key
resources off non-critical tasks; delay a task's start until resources are free
(possibly using lags); split tasks into subtasks assignable to different resources.
Leads and lags
Refines a schedule once the major network-analysis effort is done — used to meet imposed constraints, help resource leveling, or build in contingency reserves.
Lead time: Task B starts before Task A finishes —
the tasks overlap.
Lag time: Task B starts some time after Task A
finishes — a deliberate gap/delay is inserted.
Calendars
Identify the days/dates when work can actually be performed.
General project calendars govern overall limits on when project work may happen (e.g. client site shuts down for 3 weeks in summer).
Resource calendars govern limits on when a particular resource/resource group may work (e.g. individual vacation schedules, team training schedules).
General project calendars govern overall limits on when project work may happen (e.g. client site shuts down for 3 weeks in summer).
Resource calendars govern limits on when a particular resource/resource group may work (e.g. individual vacation schedules, team training schedules).
🕸️
Project schedule network diagrams
Shows both network logic (sequencing) and critical-path schedule activities — usually as an activity-on-node diagram.
📊
Gantt charts
Specialized bar-chart format for start/end dates and durations — easy to read, limited by low information density.
🚩
Milestone charts
A "stripped-down" version of a Gantt chart, showing only milestones.
§ 09 — REDUCING PROJECT DURATION
Crashing, fast-tracking, and why "just add people" backfires
Four levers to shorten a schedule: reduce scope (fewer outputs), add resources (more people), increase concurrency (parallel tasks), or substitute activities. Schedule compression specifically shortens the schedule without changing scope, to meet constraints, imposed dates, or other objectives.
Crashing
Analyzes cost/schedule trade-offs to get the greatest compression for
the least cost: add resources to critical-path tasks, be more efficient, change the
approach used, work overtime — or limit/reduce requirements, or resequence tasks.
Fast-tracking
Activities normally done sequentially are done in parallel instead.
Only works when activities can actually overlap. Can lead to rework and
increased risk from unforeseen dependencies — it trades safety for speed.
Boehm's limit: for both crashing and
fast-tracking, you cannot compress a schedule by more than 25%.
🔥
Brooks's Law
"Adding manpower to a late software project makes it later."
From Fred Brooks's The Mythical Man-Month: "Cost varies as
product of men and months, progress does not" — progress does not scale linearly. The
man-month as a unit for measuring job size is a "dangerous and deceptive myth."
| Cause | The trap | The fix |
|---|---|---|
| Over-optimism | "All programmers are over-optimists" — the false assumption that each task takes only as long as it "ought to." | Consider the larger probabilities. |
| Confusing effort with progress | Assuming you can just throw more people at a problem and get linear acceleration. | Don't assume adding people will solve the problem. |
| No pushback on deadlines | Managers accept unrealistic deadlines or vague estimates instead of defending the schedule. | Good managers defend the integrity of the schedule, even when unpopular. |
| Poor progress monitoring | Without clear metrics, slippage goes unnoticed until too late. | Use objective, measurable checkpoints. |
| Adding manpower when slipping | Like dousing a fire with gasoline — Brooks's Law. | Reallocate/replan instead of just adding bodies. |
The communication-overhead math
channels = n(n − 1) / 2 → O(n²)
n = number of team members. Every person you add doesn't just add
their own output — it adds a new communication link to everyone already there.
A 12-month project: 1 person → 12 months. 2 people → 7 months
(2 man-months of overhead "lost"). 3 people → 5 months (3 man-months lost). Adding
people has diminishing — and eventually negative — returns.
The most mis-scheduled phase: testing
Testing is the most linear process, so delays in earlier phases compress the time
left for it. This is particularly bad because it happens late, without warning,
and is expensive: primary cost = time/effort to fix bugs; secondary cost = rework,
missed deadlines, reputational damage, or production failures. Fix: allocate more
test time and understand that testing depends on completed, integrated components.
"Gutless estimating": estimators who
don't push back on unrealistic deadlines. A project goes a year late "one day at a
time" — via missed check-ins, untracked slippage, and quiet scope creep. Studies show
each task actually takes twice as long as estimated, and only ~50% of the work
week was actual programming. Fixes: no "fuzzy" milestones (avoid "almost done" —
use measurable deliverables), reduce the role of conflict (honest dialogue between devs
and managers), identify the "true status" via metrics/demos/tracking.
🔁
The whole scheduling workflow, end to end
Define → Sequence → Estimate effort → Assign resources → Apply calendars → Estimate duration → Forward/backward pass → What-if → Level resources → Compress if needed
Define activities (WBS template helps) → sequence what's logically
possible (resource allocation comes later) → estimate effort in labor units (e.g.
staff-days) → identify resources per activity → apply calendars to the framework →
estimate duration based on assigned resources → run forward/backward pass CPM to build
the schedule model → run what-if scenario analysis for contingency/risk response → apply
resource leveling → apply schedule compression only if still needed.
§ 10 — PROJECT TRACKING
"On schedule" is a number, not a feeling
Tracking uses monitoring and tools to determine whether plans, estimates, and schedules are actually accurate — replacing "I think we're fine" with a metric.
Compare an ideal project's visibility (constant, granular signal throughout) against an
efficient project (frequent but lighter check-ins), a well-run waterfall project
(visibility concentrated near phase boundaries, murky in between), and a typical project
(visibility only at a few widely-spaced points — the riskiest pattern, since problems can hide
for a long time before anyone notices).
The "Illusion of Progress" — percent complete
Early phases (design/specification) finishing first can create a false sense of
completion. A task-count view can suggest ~50% done, while the most effort-intensive,
risk-prone phases (coding, testing) are still underway or not even started.
Naïve view — task status only
| Task | Complete? |
|---|---|
| Conceptual Design | Complete |
| Program Specification | Complete |
| Coding | In Progress |
| Documentation | In Progress |
| User Manual Production | Not Started |
| Testing | Not Started |
Honest view — effort-weighted
| Task | Hours complete / total |
|---|---|
| Conceptual Design | 200 / 200 |
| Program Specification | 300 / 300 |
| Coding | 150 / 600 |
| Documentation | 10 / 100 |
| User Manual Production | 0 / 400 |
| Testing | 0 / 500 |
660 / 2100 × 100 = 31.4% complete
— nowhere near the "half done" impression the task list gave.
EVM is a project control methodology that integrates scope, schedule, and cost. It provides a quantitative basis for measuring project performance, enables early detection of deviations, supports forecasting, and gives a consistent way to talk about progress.
💰
Memory hook — the five EVM metrics
"Planners Earn Actual Cost Speed"
PV (Planned Value) · EV (Earned Value) · AC (Actual
Cost) · CPI (Cost Performance Index) · SPI (Schedule Performance Index).
| Metric | Definition | Formula |
|---|---|---|
| PV — Planned Value | Budgeted cost of work scheduled | % planned × total budget |
| EV — Earned Value | Budgeted cost of work performed | % complete × total budget |
| AC — Actual Cost | Actual cost incurred for work performed | tracked from financials |
| CPI — Cost Performance Index | Cost efficiency | EV ÷ AC |
| SPI — Schedule Performance Index | Schedule efficiency | EV ÷ PV |
Variance formulas: CV (Cost Variance) = EV −
AC · SV (Schedule Variance) = EV − PV. On an exam, you may be given some
values and asked to calculate the rest.
Using Earned Value Tracking — the full workflow
Setup
1. Establish a WBS to divide the project into manageable components
2. Identify the activities required under each WBS element
3. Estimate the effort per activity (labor hours or cost)
4. Schedule tasks: start/end dates and resources
5. Assign planned value to each task
1. Establish a WBS to divide the project into manageable components
2. Identify the activities required under each WBS element
3. Estimate the effort per activity (labor hours or cost)
4. Schedule tasks: start/end dates and resources
5. Assign planned value to each task
Execution
6. Update the schedule by reporting % complete per task
7. Record actual costs on activities (real expenditures)
8. Calculate EV metrics: EV, PV, AC, CPI, SPI
9. Analyze variance: CV = EV − AC; SV = EV − PV
10. Take corrective action: reallocate resources, adjust scope, revise schedule
6. Update the schedule by reporting % complete per task
7. Record actual costs on activities (real expenditures)
8. Calculate EV metrics: EV, PV, AC, CPI, SPI
9. Analyze variance: CV = EV − AC; SV = EV − PV
10. Take corrective action: reallocate resources, adjust scope, revise schedule
Total Budget: 1000 person-hours. Task A estimated at 100 hours.
Planned Value (PV) = 100 · Actual Cost (AC) = 120 · % Complete = 100% → Earned Value (EV) = 100.
CPI = 100 ÷ 120 = 0.83 → over budget (you spent more than the work was worth).
SPI = 100 ÷ 100 = 1.0 → on schedule (exactly the work planned for this point got done).
Planned Value (PV) = 100 · Actual Cost (AC) = 120 · % Complete = 100% → Earned Value (EV) = 100.
CPI = 100 ÷ 120 = 0.83 → over budget (you spent more than the work was worth).
SPI = 100 ÷ 100 = 1.0 → on schedule (exactly the work planned for this point got done).
Avoid "fuzzy" milestones: earned value credit is given only when a task
is 100% complete — partially completed tasks are not given partial credit in most
software projects. Break large tasks into subtasks (recall the 8–80 hour rule) so completions
happen often enough to track. Use objective progress measures (demos, deliverables) and
encourage honest reporting and team buy-in.
Agile companion metrics: velocity & burndown
Velocity = Σ (time estimated for each story completed in the iteration)
Uses story points as the effort unit in an Agile/iterative context.
If a team completes 10 stories in a two-week sprint, each worth 3
story points → velocity = 30 points/sprint. Velocity tends to stay fairly
constant, so it's useful for forecasting: a 300-point backlog at 30 points/sprint needs
10 more sprints — at 2 weeks each, that's 20 more weeks. The customer picks
which stories fill each iteration up to that velocity.
Burndown chart
A visual of how much work remains in a project/sprint over time — starts at total
work, trends toward zero as work completes. Offers real-time visibility: encourages
daily accountability, helps forecast completion, reveals early warning signs of
slippage, and supports data-driven retrospectives.
§ 11 — CHEAT SHEET
Every technique, one scan
| Tool / Technique | What it computes | Key limitation |
|---|---|---|
| WBS | Hierarchical checklist of all work (Function → Activity → Task) | What's missing hurts most; don't over-plan detail you can't manage |
| Precedence / Network Diagram | Sequential relationships between activities | Doesn't itself give durations or the critical path — needs CPM/PERT on top |
| PERT | TE = (O + 4M + P) / 6 — expected duration under uncertainty | Still an estimate, not a guarantee; needs 3 honest inputs |
| CPM | Forward/backward pass → ES, EF, LS, LF, slack → the critical path | Ignores resource availability entirely |
| CCM | Resource-constrained critical chain + buffers (project/feeding/resource) | More complex to set up and maintain than plain CPM |
| Gantt Chart | Visual bar timeline of activities vs. time | Low information density; may hide dependencies |
| What-if / Monte Carlo | Distribution of possible schedule outcomes under scenarios | Only as good as the scenario assumptions fed in |
| Resource Leveling | Smooths over-allocated resources | Can change the critical path |
| Schedule Compression (crash/fast-track) | Shortens duration without cutting scope | Max ~25% (Boehm); fast-tracking adds rework risk |
| Earned Value (EVM) | PV, EV, AC → CPI (cost efficiency), SPI (schedule efficiency) | Needs 100%-complete task credit, not fuzzy estimates |
CPI > 1 / SPI > 1
Under budget / ahead of schedule. Good news — verify it's not from cutting corners.
CPI = 1 / SPI = 1
Exactly on plan. Rare, and worth double-checking the reporting isn't just fuzzy.
CPI < 1
Over budget — the work performed cost more than it was worth (e.g. 0.83 = paying $1.20 for $1.00 of value).
SPI < 1
Behind schedule — less work got done than was planned for this point in time.
§ 12 — COMMON MISTAKES
What actually gets missed on the exam
The specific wrong answers students give, concept by concept.
1. CPM vs. CCM — which one respects resource limits?
✗ WRONG"CPM already accounts for resource availability, so it's the same as CCM."
✓ RIGHTCPM calculates dates without regard for resource limitations. CCM is the one that focuses on resources and can lead to a different critical chain than CPM's critical path.
2. The PERT formula weighting
✗ WRONGTE = (O + M + P) / 3 — a plain average of the three estimates.
✓ RIGHTTE = (O + 4M + P) / 6 — most likely is weighted 4×, and the divisor is 6, not 3.
3. Total float vs. free float
✗ WRONGTreating "slack" as one single number that means the same thing everywhere in the network.
✓ RIGHTTotal float is global — how much an activity can slip without delaying the whole project. Free float is local — how much it can slip without delaying its immediate successor. They can differ.
4. Percent complete by task count
✗ WRONGCounting "2 of 6 phases done" as 33% complete.
✓ RIGHTWeight by effort/hours: 660 of 2100 total hours = 31.4% — early, cheap phases finishing first creates a false "illusion of progress" if you just count tasks.
5. CPI vs. SPI — which denominator is which?
✗ WRONGDividing EV by PV to get "cost performance," or EV by AC to get "schedule performance."
✓ RIGHTCPI = EV ÷ AC (cost efficiency — compares earned value to what was actually spent). SPI = EV ÷ PV (schedule efficiency — compares earned value to what was planned by now).
6. Crashing vs. fast-tracking
✗ WRONGUsing the terms interchangeably, or thinking fast-tracking means "add more people."
✓ RIGHTCrashing = add resources/cost to critical-path tasks (a cost/schedule trade-off). Fast-tracking = run normally-sequential activities in parallel — no extra cost, but real risk of rework from unforeseen dependencies.
7. "We're behind — let's add more developers"
✗ WRONGAssuming headcount scales output linearly, so 2× people finishes in half the time.
✓ RIGHTBrooks's Law: adding manpower to a late software project makes it later — new people need onboarding, and communication overhead grows as n(n−1)/2, i.e. O(n²).
8. Reading a critical path straight off a Gantt chart
✗ WRONGAssuming the longest-looking bar, or the bars in a Gantt chart alone, reveal the critical path.
✓ RIGHTWithout the dependency graph, you cannot identify the critical path from durations/bars alone — that's exactly what a precedence network diagram is for.
§ 13 — POP QUIZ
Click a question to reveal the answer
MC · Using the network A(9)→[B(5)/C(7)]→D(11)→E(8), what is the length of the critical path?
35 time units, along path A–C–D–E (9+7+11+8=35). Path A–B–D–E only totals 33, since B's early finish (14) is lower than C's (16) and D must wait for the later branch.
Short answer · An activity has O=6, M=9, P=18. What's its PERT expected time?
TE = (6 + 4×9 + 18) / 6 = (6+36+18)/6 = 60/6 = 10.
True / False · A Gantt chart, by itself, always clearly shows the interdependency of activities.
False. Gantt charts are listed with the explicit disadvantage that they "do not always show interdependency of activities" — that's what network diagrams are for.
MC · Which schedule-compression technique risks rework because it overlaps activities that would normally run sequentially?
Fast-tracking. Crashing instead adds resources/cost to critical-path tasks — it doesn't inherently overlap work.
Short answer · Given EV = 100, AC = 120, PV = 100, compute CPI and SPI, and interpret each.
CPI = 100÷120 = 0.83 → over budget. SPI = 100÷100 = 1.0 → exactly on schedule.
MC · For a 5-person team, how many communication channels exist by Brooks's formula?
n(n−1)/2 = 5×4/2 = 10 channels.
Short answer · What's the difference between total float and free float?
Total float: how long an activity can slip without delaying the whole project (global). Free float: how long it can slip without delaying its immediate successor activities (local).
MC · According to Boehm, what's the maximum you can compress a schedule via crashing or fast-tracking?
25%. Beyond that, neither technique is considered reliable.
§ 14 — PRACTICE LAB
Full worked problems, straight from the slide deck's own examples
Same shape as what shows up on the exam — worth drilling until automatic.
1. Project has activities A, B, C, D, E. A and B have no predecessors. C
requires B complete. D requires both A and B complete. E requires both A and C complete.
Durations: A=9, B=3, C=9, D=5, E=4. Find the shortest total project time and the
critical activities.
→ 16 days; critical chain = B → C → E
Why: E can't start until max(A's finish=9, C's finish=12)=12, so E finishes
at 16. That 16 is driven by the B→C→E chain (3+9+4=16), which beats the A→D chain
(9+5=14) — so B, C, E are critical and A, D carry slack.
2. Given the effort-weighted table — Conceptual Design 200/200, Program
Spec 300/300, Coding 150/600, Documentation 10/100, User Manual 0/400, Testing 0/500 —
what is the true percent complete, and why might a naive "tasks done" count mislead you?
→ 660 / 2100 = 31.4% complete
Why: two of six tasks show "Complete," which naively suggests ~33-50% done
— but those two tasks are cheap (200+300=500 of 2100 total hours). The expensive,
risk-heavy phases (coding, testing) barely started, so effort-weighting gives the honest
number.
3. Task A is budgeted for 100 hours out of a 1000-hour project. It is now
100% complete and actually cost 120 hours. Compute CPI and SPI and state whether the
project is over/under budget and ahead/behind schedule.
→ CPI = 0.83 (over budget) · SPI = 1.0 (on schedule)
Why: PV=100 (planned), EV=100 (100% complete × 100 budgeted), AC=120
(actual spend). CPI=EV/AC=100/120=0.83 <1 → over budget. SPI=EV/PV=100/100=1.0 → exactly
on schedule.
4. A team of 6 developers is being considered for a project. Using Brooks's
communication-overhead formula, how many communication channels exist, and what does
that imply about adding a 7th developer mid-project?
→ 6×5/2 = 15 channels at 6 people; adding a 7th raises it to 21
Why: channels = n(n−1)/2 grows quadratically (O(n²)). Adding the 7th person
doesn't just add their output — it adds 6 new communication links, plus onboarding time,
which is exactly why Brooks's Law says adding people to a late project makes it later.
5. A WBS lists top-level items as "Requirements," "Analysis," "Design," and
"Testing." Is this a Process WBS or a Product WBS, and who typically uses this type?
→ Process WBS (activity-oriented)
Why: the top-level items are activities/phases, not deliverables/entities
(a Product WBS would instead list things like "Financial engine" or "Interface system").
Process WBS is typically used by the PM.