Study the PMI-SP by tracing decisions, not memorizing terms. Each scheduling concept changes what you would do next on a project; practice identifying which concept a scenario is really testing, commit to an answer, and check it against the worked reasoning and rubrics below.
Total float and free float answer two different questions
Total float measures how long an activity can slip before the project finish moves; free float measures how long it can slip before a successor's early start moves. Scenarios turn on which of those dates a delay actually threatens.
Total float is the slack between early and late dates, computed as late finish minus early finish on each activity. Free float is the slack before a successor is delayed, which can be smaller when a successor is pinned by its own constraints or by another predecessor. An activity can hold generous total float and zero free float at once, and a constraint or an open-ended activity can distort both numbers. Before quoting any float value, check what the network and its constraints actually say rather than what a single activity's bar seems to suggest.
Build the scenario habit: when a question says an activity 'will slip by six days,' ask which date is affected. If the activity carries eight days of total float, the finish is safe and the better response is usually to monitor and record the consumption. If the same slip lands on an activity with zero free float but ten days of total float, the successor still starts on time, yet your float consumption must be reported honestly. Naming which kind of float is being consumed is the decision the scenario is quietly testing.
- Negative float means the modeled logic already cannot meet an imposed date; recovery requires a change, not patience.
- Float created by a constraint can disappear the moment the constraint is removed, so tie float conclusions to the constraints that produced them.
- Near-critical paths deserve the same scrutiny as the driving path, because compression and leveling can promote them.
Trace the network by hand before trusting any tool
A forward pass calculates early dates; a backward pass from the required finish calculates late dates and float. Doing this manually on six to ten activities builds exactly the reasoning that scenario questions demand.
Start with a simple precedence network and fix your conventions: early start, early finish (early start plus duration in a day-count convention), then push early dates forward through every path. Pull late dates backward from the required finish, and float falls out as the difference. Once that is automatic, add the precedence diagramming relationships: start-to-start and finish-to-finish links, and lags, checking each time whether the lag or the activity's duration is what actually drives the successor's start.
Practical exercise: draw six activities — A (5 days) feeds B (3 days) and C (8 days); B and C both feed D (4 days); D feeds E (2 days). Compute early dates, then late dates against a required finish of day 19. Expected observations: the path A-C-D-E drives the finish and is critical, so A, C, D, and E all carry zero total float; B carries five days of total float and also five days of free float, because its successor D cannot start before day 13; C has no free float because D waits directly on it. Self-check rubric: forward dates consistent on every path (2 points), backward dates and float values correct (2 points), and you can state what happens to the finish if C slips one day versus B slipping one day (2 points). Repeat with different durations until you score 6/6 in under ten minutes.
Fast tracking and crashing spend two different currencies
Fast tracking overlaps sequential activities and spends rework and coordination risk; crashing adds resources or cost to critical activities. Decide from which scarce resource the scenario says the project is short: time-risk tolerance or budget.
Both techniques act only on the path that controls the finish; shortening anything else moves nothing. Fast tracking converts finish-to-start logic into start-to-start overlap or parallel work, which shortens the model but invites out-of-sequence execution, redesign, and dispute exposure. Crashing shortens durations by adding cost, and its benefit per unit of money shrinks as paths converge, because each compression step can shift the driving path onto what was previously a near-critical chain.
Worked scenario: a 40-week finish must move to 36 weeks. Activity F (critical, 10 weeks) can be crashed to 6 weeks at $4,000 per week; activity G (8 weeks, holding 3 weeks of float) can be crashed to 5 weeks at $2,000 per week. The tempting mistake is buying G's cheaper weeks — but G's float means the crash delivers zero schedule benefit and pure cost. The better decision is crashing F by four weeks ($16,000), then re-running the network, because F's compression may hand control of the finish to another chain and cap further gains. The rule that matters: cost per week saved is only meaningful on the path that controls the finish.
Status the schedule against the data date, not against hope
An update re-forecasts the finish from the data date using remaining durations and current logic. Percent complete alone cannot produce a forecast; the credibility of an update rests on its remaining durations.
Every update anchors at the data date: actual starts and finishes are locked, remaining durations are re-estimated, and the network recalculates. Watch for out-of-sequence progress — work performed before a predecessor finished — because it breaks the relationships the baseline relied on and can silently detach activities from the logic that justified their dates. Compare each new forecast with the baseline, not with last period's forecast; a schedule can improve week over week while still losing ground against its original plan.
Worked scenario: a 20-day activity started five days late and has now been in progress for 15 days, reporting 50 percent complete with '10 days remaining.' The plausible mistake is deriving the remainder as half of 20 days, which silently assumes production will return to the planned rate. The observed rate says otherwise: 50 percent of the work consumed 15 days, so the remaining half needs roughly 15 more days at the same output. The better decision is to base the remaining duration on measured production — about 15 days, not 10 — and report the resulting forecast, which is already 5 days late at the start. Why it matters: optimistic remaining durations hide the slip until recovery is expensive and corrupt every downstream metric built on the update.
Resource smoothing and leveling move work in different ways
Smoothing resolves overloads inside existing float and never moves the finish; leveling may extend the project and change the critical path. Scenarios signal the choice through whether the end date is negotiable.
Smoothing shifts tasks within the float they already hold so that resource histograms stay under their limits; total float absorbs the moves and the completion date is untouched. Leveling drops that protection when float runs out: it delays activities, can push the finish, and can promote a near-critical path to critical. That last effect is the subtle one to practice — after leveling, yesterday's float-based reasoning may no longer hold, so every decision that depended on a float value must be revisited.
Use a two-question decision rule on scenarios. If the question fixes the finish date and mentions an overload, the intended answer is smoothing within float, with leveling's consequence — a later finish or changed driving path — documented if float proves insufficient. If the question fixes resource limits and allows the end date to move, leveling is legitimate, and a complete answer states the new finish and the new critical path. The defensible response names both effects, the schedule impact and the resource impact, rather than presenting either technique as free.
A stable SPI can hide a slipping critical path
Measure schedule health with float trends, longest-path movement, and milestone variance together. A schedule performance index near 1.0 can coexist with an eroding driving path when non-critical work absorbs the effort.
The schedule performance index compares the value of work performed to the value planned; below 1.0 means work is completing more slowly than planned. Its interpretation limits matter as much as its definition: effort on float-rich activities can hold SPI near 1.0 while the driving path erodes, and as a project nears completion the index drifts toward 1.0 because the planned value remaining shrinks. Read it alongside float consumption and milestone trends; never treat it as a stand-alone verdict on schedule health.
Practice reading three signals together: how much total float remains on the driving path and how quickly it is being consumed across updates; whether the longest path has migrated to different activities since the last update; and whether key milestones are forecasting later than baseline. Scenarios that present several healthy-looking metrics plus one eroding float figure are asking which signal actually controls the finish. That analysis — spotting the controlling signal among flattering numbers — is the monitoring habit worth rehearsing until it is automatic.
Document logic and assumptions the way a reviewer would read them
Every date in a schedule model rests on documented logic, calendars, constraints, and assumptions. Professional responsibility means an independent reviewer could reproduce your forecast and find progress honestly reported.
Keep the audit trail a reviewer would need: the reason each constraint exists, which calendar each resource follows, where lags were substituted for real relationships and why, and which version is the protected baseline. Retain the baseline unchanged and measure every update against it. When reporting, separate what the model forecasts from what stakeholders hope for; adjusting status so a report reads better misrepresents performance and conflicts with the professional standards this credential is built on.
This documentation habit also sharpens scenario answers: when dates are disputed or progress ran out of sequence, the defensible option is the one whose logic, assumptions, and reporting are transparent. Use these readiness checks before moving from concept study to timed practice: you can hand-trace a network of six to ten activities and state total float, free float, and the driving path without software; given a compression target, you can pick the activity to act on and name the re-check that follows; given a status report, you can explain what the data date, remaining durations, and out-of-sequence work imply for the forecast; you can distinguish smoothing from leveling and state each one's effect on the driving path; and you can list the records a reviewer needs to reproduce your logic.
| Technique | What it changes | Main cost or risk | Choose it when the scenario says… |
|---|---|---|---|
| Fast tracking | Overlaps activities that were sequential | Rework, coordination load, dispute exposure | Time is short and the overlap is genuinely manageable |
| Crashing | Shortens critical durations by adding resources | Cost rises; benefit shrinks as paths converge | Budget can buy time on the path controlling the finish |
| Smoothing | Moves work within existing float | Float is consumed; finish untouched | The finish date is fixed and float is available |
| Leveling | Delays work to fit resource limits | Finish may move; driving path can change | Resource limits are hard and the end date can move |
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.