The schedule has slipped, the finish date has not moved, and the stem asks what the project manager should do. Four options follow: add people, overlap two activities, cut scope, ask the sponsor for more time. Candidates who have only memorised the words crashing and fast tracking will get roughly half of these questions right, because both words appear in the options and both sound plausible.
The questions are not actually asking you to define the terms. They are asking you to read two specific facts out of the scenario — which activities are on the critical path, and whether extra resources exist — and let those facts pick the technique. Once you read for those two things, the category stops being a coin flip.
What compression is, and what it is not
PMI's Lexicon of Project Management Terms (version 5.0, updated January 2026) defines schedule compression as "a technique used to shorten the schedule duration without reducing the project scope."
The last four words are the whole trick. Any option that drops a feature, defers a deliverable, or trims a requirement is not schedule compression — it is a scope change, and on the exam it is usually a change request rather than a scheduling decision. Likewise, an option that moves the finish date is not compression either; it is a baseline change. When a question is framed as "the deadline is fixed and scope is approved," those two families of answers are already eliminated before you compare the remaining two.
That leaves the two techniques the Lexicon names. Crashing is "a schedule compression technique used to shorten the schedule duration for the least incremental cost by adding resources." Fast tracking is "a schedule compression technique in which activities or phases normally done in sequence are performed in parallel," for at least part of their duration.
Fast tracking costs no money and buys you risk
Fast tracking changes the logic of the network. Work that was planned to run in sequence is overlapped — a finish-to-start relationship becomes a start-to-start with a lead, or a downstream activity begins on a partial input rather than a finished one.
Nothing is purchased, so the budget does not move. What moves is risk. The overlapped activity is now working from something provisional, and if that something changes, the work done against it may need to be redone. The PM PrepCast's treatment of these items makes the practical version of the point: a prototype can start before the design is fully complete, provided enough of the specification is settled to build against.
Two limits matter on the exam. The first is dependency type. Overlapping is only available where the sequence was a choice — a preferred practice, a convention, a team's habit. Where the sequence is physically or contractually required, it cannot be overlapped at all, and an option that proposes doing so is wrong regardless of how urgent the scenario sounds. iZenBridge's guide to the two techniques states this plainly: only the discretionary relationships are candidates.
The second limit is diminishing returns. Past a certain amount of overlap, more parallelism produces rework rather than compression. A scenario that describes a team already running three overlapped workstreams and still behind is usually not asking for a fourth.
Crashing spends money and buys you calendar
Crashing adds resources: more people on an activity, approved overtime, an expedited delivery, a second shift. The schedule shortens and the cost goes up, which is why the Lexicon definition specifies least incremental cost — the technique is not "add resources," it is "add the resources that buy the most days per dollar."
That phrasing is also the exam's favourite distinction between two crashing options. If one option adds people to a critical activity and another adds people to an activity with float, the second is wrong, because compressing work that is not on the critical path does not change the project duration. It only increases that activity's float.
Crashing has its own ceiling. Some work does not go faster with more hands — the Dummies PMP study material describes per-activity crash limits, where an activity can be shortened only so far or not at all. Curing, testing, and regulatory review windows are the standard examples. And beyond a point, additional people increase coordination effort faster than they increase output, which iZenBridge notes as the reason extra resources eventually only consume budget.
The two facts that decide the answer
Almost every compression question tells you which technique is available, in a clause that is easy to skim past.
The resource clause decides crashing. "Using the existing team," "with no additional budget," "the contractor cannot provide more staff" — any of these removes crashing from the table, and the answer is fast tracking where the dependencies allow it. Conversely, "the sponsor has approved additional funding" is an invitation to crash.
The dependency clause decides fast tracking. "Testing cannot begin until the build is complete because of the integration requirement" is a mandatory sequence and rules overlapping out. "The team has always run design review before development starts" is a discretionary one and opens it up.
When both clauses are permissive, the convention in most study material is to prefer fast tracking first, since it does not consume budget, then crash for whatever compression remains. When neither is permissive, the correct answer is usually not a compression technique at all — it is to analyse the variance and raise a change request.
| Fast tracking | Crashing | |
|---|---|---|
| What changes | Network logic — activities overlap | Resources on an activity |
| Cost effect | None directly | Increases |
| Risk effect | Increases, mainly rework | Modest, mainly coordination |
| Blocked by | Mandatory dependencies | No resources or budget |
| Applies to | Critical path activities | Critical path activities |
| Stem clue | "No extra budget or staff" | "Funding approved" |
Where the point is usually lost
Three mistakes account for most of the misses.
Compressing off the critical path. The question names an activity that is late, the candidate compresses that activity, and the project finish does not move because the activity had float. Identify the critical path before choosing anything.
Treating a scope cut as compression. "Defer the reporting module to phase two" shortens the schedule, but it is not compression, and in a scenario with an approved baseline it requires a change request.
Ignoring the resource clause. This is the most common one, because it is a subordinate clause in the middle of a long stem. A scenario that says the recovery must happen with the current team has already told you the answer is not crashing.
How to practise it
When you review schedule questions, do not check whether you got them right. Check whether you can point at the words in the stem that made the answer correct. For this category there should be two: the phrase that established which activities drive the finish date, and the phrase that established whether money or people were available.
If you cannot find both phrases in a question you answered correctly, you guessed well rather than read well, and the next version of that question will not be as kind.