http://www.brighthubpm.com/resource-management/5055-project-crashing-what-options-do-you-have/
The above article is a quick guide to reference when considering whether or not to “crash” a project schedule.
There are many ways to crash a project schedule and there are pros and cons to all of the various methods, but the most important thing to keep in mind when crashing a project is the costs associated with crashing. The article mentions that the key to crashing a project is to obtain the maximum amount of time reduction for the minimum cost.
The article also list several different methods of crashing a project, these are but not limited to, increasing your resources and fast tracking.
The most common method of crashing is increasing your resources. We referenced this method in class during our Rock’n Bands exercise. We were given the option of adding another worker on to the project in order to decrease the amount of time each activity required. However, there was a cost to this due to the extra communication and organization that was required for this additional worker. The risk in using this method is the quality of the additional resource may not be up to the same standard as those already on the project. In the case of the Rock’n Bands, if the additional worker is not as productive as the original workers then they can actually slow the project down. Time that the more productive members could have spent on the completing the project, now is going to coaching along the less productive worker.
Another method mentioned in the article is fast tracking. This method revolves around reducing inefficiencies in order to shorten project times. This can be accomplished through breaking longer tasks into shorter chunks, reducing lag times between tasks, and reducing scope in order to eliminate non-critical tasks.
However, the most successful project crashing often involves some combination of adding resources and finding ways to more efficiently use the resources you already have.
One of the last things the article mentions, but is one of the most important things to keep in mind when considering crashing a project and that is when NOT to crash a project. Sometimes the costs associated with crashing a project can outweigh the benefits.
My question for the class is, in your class project or in your work experience, were there times where you had to crash a project and if so what were the most important factors you considered when deciding whether or not crashing the project was the best course of action?
As we were working on our project, I think the only time we had to crash a project component was when we were looking for a site for our dinner event. Things didn’t go as planned, so we ended up throwing a lot of man-hours at it. The outcome wasn’t what we had expected, and while it all worked out in the end, crashing that step of our project didn’t produce the outcome we had hoped.
Professionally, I have been involved in crashing several projects. Each time that happened, we had simply thrown more resources at the problem. Often times when this happens it’s because an unexpected business development has forced the group to alter our timeline. Most recently, my company was in the midst of a major database platform conversion as part of a larger integration project, which would have resulted in having the entire company on one single platform. In the midst of this project we got wind that we were likely to win at least $500MM in new business, and that on-boarding this new business would happen very close to the project’s implementation phase. In order to avoid what might have been an extremely chaotic situation, we had to crash basically the rest of the project.
As it turned out, several weeks after the crashing began and only four weeks out from implementation, the entire project came to a grinding halt as leadership decided the proposition was entirely too risky. All parts of the project in mid-flight were completed, and we will resume the project after the new business has been successfully on-boarded.