Crashing vs fast-tracking, shown on a Gantt chart

How do compression techniques differ?

Crashing shortens task durations; fast-tracking overlaps tasks previously planned in sequence. On a Gantt chart, crashing makes bars shorter. Fast-tracking keeps their length but changes when they start.

Both are known as schedule compression techniques. PMI's PMBOK Guide names them as the two standard ones, and they turn up on almost every PMP exam prep list for that reason. Choose between them by comparing the extra spending for crashing with the risk and possible rework from fast-tracking.

Cutting scope makes the project smaller rather than faster, so it is a scope decision rather than compression. Moving the deadline is not compression either. When both are ruled out, consider crashing and fast-tracking.

Why does critical path matter?

The critical path sets the finish date. It is the longest chain of linked tasks, with no room for any task to slip. Tasks off that path have float: they can finish earlier or later without changing the project's end date. Shortening them adds float rather than advancing completion. If the idea is new, finding the critical path covers how to trace it.

The worked example is a small customer portal. Requirements sign-off takes 5 working days. Design and data migration can both start after that. The build waits for design, testing waits for both the build and the migration, and the help articles only wait for design. The portal needs to be live by working day 40, when a large customer's contract comes up for renewal. As planned, it goes live on day 45.

Sample data: a customer portal plan in working days, with the critical path highlighted in red.

Three chains run through the plan:

• Requirements, design, build, testing: 5 + 10 + 20 + 10 = 45 days. This is the critical path.
• Requirements, migration, testing: 5 + 25 + 10 = 40 days, so the migration has 5 days of float.
• Requirements, design, help articles: 5 + 10 + 8 = 23 days, with 22 days of float.

The project needs to save 5 days on the first chain. Keep watching the second chain: it starts only 5 days shorter and can become critical as the first chain shrinks.

Which task should you crash?

Calculate the extra cost per day saved for each critical task. Start with the cheapest option and re-check the critical path after every change. Cost per day saved equals extra cost divided by days saved.

The two cheapest options in the table, help articles at $250 a day and migration at $500, are the two that save nothing. That is not a contrived trick of the example. Off-path tasks are often the cheapest to speed up precisely because nobody is under pressure there, and they are the first thing a team under pressure offers to throw money at.

Following the method:

1. Testing first. It is the cheapest critical task at $700 a day. Crashing it by the full 3 days costs $2,100 and moves go-live from day 45 to day 42. Testing sits on both of the long chains, so the migration keeps its 5 days of float.
2. Design next. At $900 a day it is cheaper than the build. Two days cost $1,800 and bring go-live to day 40.
3. Stop and re-check. The deadline is met for $3,900. The migration chain is now 5 + 25 + 7 = 37 days, so it still has 3 days of float.

Sample data: the same plan after crashing testing by 3 days and design by 2.

Now suppose the customer asks for day 37. The only critical task left to crash is the build, at $1,200 a day, and 3 days of it bring both chains to exactly 37. From that point two paths are critical, and any further day means crashing the build and the migration together, at $1,700 a day. That jump is the normal shape of crashing. The first days are cheap, the cost per day climbs as the cheap options run out, and it climbs sharply once a second path catches up with the first.

One caveat on the arithmetic. The table assumes a task can be crashed by part of its range at the same daily rate, which is rarely quite true. A contract developer who joins for six days does not save six-twentieths of the build. Someone has to brief them, review their work and answer their questions, and that time comes out of the people already on the task. Use the table to rank options, not to promise exact figures, and check durations with the people doing the work. The page on estimating task durations covers where those numbers should come from.

How does fast-tracking change bars?

Fast-tracking overlaps bars that previously ran end to start. In the portal example, the build can overlap part of design. As planned, developers wait for every screen to be designed. If the designer finishes the core screens first, the build can start on those while the remaining screens are still being drawn.

On the chart, that overlap is drawn by splitting the design task in two. "Design core screens" takes the first 5 days and links to the build with an ordinary finish-to-start link. "Design remaining screens" takes the next 5 and links to the build with a finish-to-finish link: the build cannot be finished before the last screen is designed. The build now starts on day 11 instead of day 16.

Sample data: the same plan fast-tracked, with design split so the build overlaps the second half.

Splitting the task is a better habit than the usual alternative, which is a lead: a finish-to-start link with a negative offset, saying "start 5 days before this ends". Many tools have no lead setting at all, and a lead hides what the overlap actually depends on. A split names it. Anyone reading the chart can see that the build depends on the core screens being finished, and can ask whether they are.

The result is go-live on day 40 with no extra spend on people, the same date the crashed plan reached for $3,900. The migration bar also turns red. The fast-tracked build chain is 5 + 5 + 20 + 10 = 40 days, exactly the length of the migration chain, so the plan now has two critical paths and no float on either. A one-day slip in data migration, which had 5 days of room in the original plan, is now a one-day slip in the launch.

Then there is rework, the cost fast-tracking does not show on the chart. If the remaining screens force changes to pages that are already built, the build runs longer. Say it adds 2 days: with no float anywhere, go-live moves to day 42. The fallback is to crash testing, still the cheapest option at $700 a day. Fast-tracking first and crashing with what is left is a common and sensible combination. Plan the combination before rework occurs.

Which should you try first?

Try fast-tracking first when tasks can safely overlap: it adds no direct cost, though the overlap carries a risk of rework. Choose crashing when extra spending is preferable to uncertainty, or when tasks cannot overlap.

A few questions settle it quickly:

• Can partial output support work? A build can start on approved core screens. Painting cannot start on a half-plastered wall. If the answer is no, the dependency is real and there is nothing to fast-track.
• Is the output stable? Overlapping onto a design that the client has not seen yet is a bet. Overlapping onto a design signed off in sections is a plan.
• Will more people help? Fred Brooks's well-known observation about software projects, that adding people to a late project tends to make it later, holds for any work where newcomers need ramp-up time and coordination. Testing, data entry and supplier lead times crash well. Writing, design direction and anything one person holds in their head crash badly.
• How much float remains? If the parallel chain has little float, both techniques will soon make it critical, and the plan becomes fragile in two places instead of one.

If you are dealing with too much work for the same few people, rather than a date that needs moving, the problem is overload, and resource leveling is the closer fit. Leveling usually pushes dates out; compression pulls them in.

Where does schedule compression fail?

Compression fails when teams shorten tasks with float, miss a new critical path, overlap work that must stay sequential or ignore the loss of schedule flexibility.

• Paying for float: crashing a visible, noisy task that is not on the critical path. The help articles in the example are the trap: cheap, easy to speed up and worth nothing to the date.
• Not re-checking the path: crashing the build by 6 days because it was critical on Monday, when after 3 days the migration chain had become just as long. The second half of that spend saves nothing.
• Overlapping a real dependency: removing a link because the date demands it, not because the work allows it. If the link was there because the second task needs the first task's output, removing it does not remove the need.
• Forgetting what was traded: a compressed plan has less float and less room for surprises. Tell people that the new date is tighter, not just earlier, and keep the old plan to compare against. The page on tracking delays covers watching plan against actual once the work is running.

Most of these come down to dependencies drawn carelessly in the first place. If links in your plan mean "usually happens after" rather than "cannot start until", the critical path is invented and so is every compression decision based on it. Which tasks to link is worth a second look before you spend money.

Crashing and fast-tracking questions

Is fast-tracking riskier than crashing?

Usually, yes. Crashing has a known cost that you agree to up front, while fast-tracking's cost is rework that may or may not happen. Crashing has its own risk, though: new people can slow a task down before they speed it up, so a crashed duration is also an estimate.

Can you crash and fast-track the same project?

Yes, and it is common. A typical approach is to fast-track where an overlap is safe, then crash the cheapest remaining critical task to cover the gap or the expected rework. Re-check the critical path after each change, because each one can make another chain critical.

Does fast-tracking increase cost?

Not directly, which is its appeal. It can increase cost indirectly through rework, extra coordination between overlapping teams and the chance of a delay on a plan with less float. Budget a little for rework when you decide to overlap.

Can you promise that date?

Trace the critical path, list what each critical task would cost to shorten, and look for one overlap that is genuinely safe. Make one change at a time and check which chain is longest after each. Then tell people what the new date cost: the money, the float that is gone, and the parallel chain that is now critical.