Fast-tracking means scheduling tasks in parallel when possible. Crashing is adding people or spending money to complete work earlier. Don’t be overly ambitious with these techniques. Here are some dos and don’ts for fast-tracking and crashing:
Do look for opportunities to fast-track or crash. These strategies can shorten the schedule, but also add risk — so make sure they’re worth it. Fast-tracking increases the risk of rework because products developed in parallel might not integrate. Crashing increases cost, because you must obtain and coordinate additional resources.
Do add review tasks after fast-tracking. Adding review time lenthens your schedule, but not as much as you save by fast-tracking. Reviews mitigate the integration risk of fast-tracking. Team members who work on parallel tasks should conduct joint reviews to ensure products are compatible.
Do use skilled resources to crash your tasks. Adding skilled team members can improve the quality of the product and save time.
Don’t add marginal skills to tasks you’re crashing. Lack of skill creates more overhead – ensure you have capable people. Also, limit the number of people on crashed tasks. Too many people get in each other’s way, wasting time and money.
Don’t compromise project integrity by fast-tracking testing. Testing tasks should be exempt from fast-tracking. Testing evaluates the appropriateness of your products. You can’t conduct high-integrity tests while product development is still in progress. If you do that, you’ll need additional regression testing, which negates the fast-tracking time savings.
Don’t apply both fast-tracking and crashing to the same tasks. This increases risk dramatically and is rarely successful. I call this “fast-crashing,” because, like a car accident, you can’t help but look, though the results aren’t pretty.
For more on these techniques, watch my LinkedIn scheduling course