Project Management

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

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. 

8 comments
maazzarif
maazzarif

Respected sir, what's the condition/criteria for crashing activity duration ? please emphasize on this part of crashing(activity duration) . I found a following formula on internet? [min{normal duration-crash? duration , float limit}]..note: float limit is not equal to float..please help.

son_bolt
son_bolt

The explanation was simple and to the point.

shay_in_denver
shay_in_denver

Back in the 80's I was on a project team whose mandate was to replace all its legacy customer service and billing systems with a packaged solution. Senior management wanted the whole thing done in two years. We spent almost a month creating an elaborate project plan. The planning tool we used told us that, with current resources, the project would take four years. IT management then ordered us to rework the plan to fit it into 24 months. We accomplished this by estimating that everyone on the team would work a 60 hour week for two years straight: no vacations, no sick time, no holidays, no family emergencies, no training classes. And management wonders why deadlines are so rarely met.

wfroese
wfroese

In this case, if you are talking about a sizable project and it is seriously slipped and you must catch up to a deadline, then you should concentrate on being luckier. Somethings in big projects are done just for the safety of the project at the cost of taking more time. As it turns out, the whole project is at risk so now you should dump anything that is taking time away from development - testing, documentation, regular meetings and reporting. Those sorts of things are related to quality and reporting - replace that with hope. Swing for the fences!

techrepublic
techrepublic

Every time the almighty schedule is valued above quality, quality suffers. This is reason Number One why most software sucks. All other reasons place a very distant second. Fast Tracking: The reason things are done in sequence is that one activity feeds the next. You just can't pretend that this doesn't happen. Wishful thinking is always expensive. If any activities can be done in parallel, they should have been scheduled that way in the first place. Crashing: Here's a term used to describe a software system in the process of failure. When that process is complete, we say that the system has "crashed". It seems fitting that this same term is now being used to add inappropriate resources to "speed up" a project. Someone should be (re-)reading Brook's "The Mythical Man-Month". Nine women cannot make a baby in a month. And girls cannot make a baby at all! Will they never learn? In short, software takes a certain amount of time to build successfully. Any attempt to use arbitrary means to speed up the process WILL make it take longer and therefore, cost more. Just the opposite of what is desired. Software will NEVER achieve the reliability and security we all seek as long as the suits and bean counters are making what amounts to engineering decisions. They just aren't qualified.

rgouvea
rgouvea

Fast tracking is OK. Extreme programming is the last resource. I agree that paralel activities are sometimes a way to go. And if posible mesure things graphically to detect adverse tendencies. Examples are in "Practical Sw and Systems Measures - PSM". Take a look at their site.

HAL 9000
HAL 9000

And I'm not sure if the author still writes for TR but regardless with something so old I personally would not be expecting any form of answer. Col

MrGrumpy
MrGrumpy

This is another can of worms and seems to depend on schools of thought. I've seen managers who advocate that a task is either complete or not when tracking the schedule. No, 50% complete or nearly done.

Editor's Picks