Fast-tracking and crashing can get your project back on schedule

by Tom Mochal | Dec 18, 2006 8:00:00 AM

Tags: Project management, Tom Mochal, Project Management Newsletter

Takeaway: Tom Mochal cover these two methods of fixing a project schedule.

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

"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 you.�

6 comment(s)