Fast-Track or Crash? I Prefer Neither

Fast tracking and crashing project schedules are drastic measures to attempt to correct a failing projectI like the sound of “fast track.” “Crashing?” – not so much.

Just the term itself – “crashing the schedule” – sounds destructive rather than constructive.

Fast tracking and crashing are two techniques that Project Managers have used to bring projects that are seriously behind schedule back on track.

Personally, I’m not a huge fan of either technique. While these strategies may salvage the schedule, at what price? What of the project objectives? What of quality, functionality, healthy work environment, and/or reputation?

My preference would be to bite the bullet, alert the stakeholders of the problem as soon as it is known, and negotiate relief. Extending the deadline and increasing the budget is often preferable to delivering a shoddy system on time. True, projects such as Y2K remediation of a past era, or health insurance enrollment deadlines, or civic elections don’t have that luxury. But most projects do.

In my previous article, “These are the Human Factors that Cause Schedule Slippage”, I make the case for attentively controlling the schedule. By recognizing the factors that contribute to schedule slippage, and preventing them from occurring in the first place, it is possible to keep the project on track.

Admittedly though, projects do go awry, even under the watchful eye of an experienced Project Manager.

So, what of fast tracking and crashing? Sometimes these more drastic methods do become necessary, especially when the project deadline is mandated, and schedule compression is warranted.

Fast tracking

Think of fast tracking as executing several tasks in parallel (or some degree of overlap) versus executing them in sequence as originally scheduled. Such schedule compression is favored on projects for which the implementation date is immovable, and the system design is highly modularized. Highly modularized designs allow for more of the work to be isolated within the functional silos and thereby lend themselves to more parallel effort.

Take an example from the building industry. Typically, the drywall crew comes in after the plumbers have roughed in the plumbing and fixtures. If pressed for time, the sheetrock could be installed in rooms where no plumbing is required, to allow the plumbers to complete their work.

Similarly, on an IT project, subsystems for which the designs are complete may move to the development phase, while the remaining subsystems continue in design.

This technique can be highly effective. It does, however, require constant vigilance to judiciously stage the overlapping work. Subsystems still undergoing design may create dependencies for already developed modules, thus requiring rework. Subsystems still in design may require changes to the database design, which might in turn ripple through already developed modules. Staff required in development may have ongoing design responsibilities and are stretched too thin. The opportunity for error, poor quality, and missed objectives is increased.

Unless planned and executed well, fast tracking could put the project further at risk. At the very least, the high likelihood of rework would add to the cost of the project, even if the schedule is salvaged.


I have never favored this technique. In my opinion, it is the epitome of the mythical man month. (“The bearing of a child takes nine months no matter how many women are assigned” (Brooks, 1975, p.17)).

Crashing the schedule adds resources to a project that is off-track. Resources are added to reduce the remaining duration, specifically of the critical path. This technique is most effective if the additional resources are assigned to work on discrete tasks that do not require much ramp up.

Take another example from the building industry. If the pouring of the foundation and slab are delayed, it is possible to add an extra concrete crew and double up on the cement trucks. The crews could work on opposite sides of the building and meet in the middle, essentially cutting the duration in half.

Similarly, for an IT project. If the design is complete and the subsystems are highly modularized, additional developers could be brought in to work on distinct subsystems on the critical path.

However, adding resources to tasks already underway could result in an overall slowdown. Similarly, for complex tasks that require the new resources to be trained and/or oriented. Not only do the new resources require time to ramp up before they are productive, but a productive resource must stop what she is doing to provide the required instruction.

Crashing the schedule actually can have a detrimental effect on the project. It introduces more chaos for an already tense team that is scrambling to get back on track. It reduces the existing team’s productivity as they stop to bring their new teammates up to speed. The gain realized by adding extra resources is never an hour-for-hour gain. In the worst case, it causes further schedule slippage. Cost is increased, and the required schedule improvement may not happen.

The best way to avoid having to resort to fast tracking or crashing the schedule is to carefully monitor and constantly control the schedule to keep it in line. This is far superior to employing such drastic measures to attempt to fix a serious schedule slippage.


Brooks, Frederick P., Jr. The Mythical Man-month: Essays on Software Engineering. 1975. Reading, MA: Addison-Wesley Publishing Company, Inc., 1982, Print.

Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.