Project managers should evaluate their schedules on a weekly
basis to ensure their project remains on track. If the project starts to drift,
there are a number of techniques that can be used to get back on schedule. Most
of these are not dramatic.

Tips in your inbox

Looking for expert IT project management? Get the help you need from TechRepublic’s free Project Management newsletter, delivered each Wednesday.

Automatically sign up today!

However, let’s assume that your project starts to slip
dramatically. It may not be possible to get back on track through the typical
schedule management techniques. Let’s further assume that the project deadline
is fixed and can’t change. In this case you may need to employ more dramatic
means. Two techniques to consider are fast tracking and crashing.

Fast tracking

Fast tracking means that you look at activities that are
normally done in sequence and assign them instead partially in parallel. For
instance, normally you would not start constructing a solution until the design
was completed. However, if you were fast-tracking, you would start constructing
the solution in areas where you felt the design was pretty solid without
waiting for the entire design to be completed. Fast-tracking always involves
risk that could lead to increased cost and some rework later. For instance, in
the example of designing and constructing an application, it’s possible that
the design might change before it is finalized, and those final changes may
result in having to redo some of the construct work already underway.

A good rule of thumb is that sequential activities can
sometimes be fast-tracked by up to 33%. In other words, if you’re
fast-tracking, you can start the second of two sequential activities when the
first activity is 66% complete. There is risk involved. However, this seems to
be a level of fast-tracking risk that is normally acceptable.


“Crashing” the schedule means to throw additional
resources to the critical path without necessarily getting the highest level of
efficiency. For instance, let’s say one person was working on a ten-day
activity on the critical path. If you were really desperate to shorten this
timeframe, you might add a second resource to this activity. In fact, the
resource may not have all the right skills and he might work five days just to
reduce the overall time by two days.

On the surface, the prior tradeoff might not make sense.
After all, why would you have a person work five days just to reduce an
activity by two days? It’s not efficient. However, can you imagine a project
that was so important that you were willing to make this kind of tradeoff?
Think about the YR2K projects. When the end of 1999 was rolling around, many
companies were throwing resources onto projects; desperate to get them
completed on time. They were fast-tracking.

Additional resources may come from within the project team,
or they may be loaned temporarily from outside the team. One of the goals of
crashing the schedule is to minimize the incremental cost. However, in exchange
for completing some work ahead of schedule, crashing usually always leads to
some additional incremental cost to the project. If you’re willing and able to
spend more to accelerate the schedule, fast-tracking may be a viable option for