First of all let's start by defining what does it really mean to crash time or costs. This can be simply called schedule crashing and according to Project-Management.com
As defined by BusinessDictionary.com, schedule crashing is “Reducing the completion time of a project by sharply increasing manpower and/or other expenses,” while the Quality Council of Indiana‘s Certified Six Sigma Black Belt Primer defines it as “…to apply more resources to complete an activity in a shorter time.” (p.V-46). The Project Management Body of Knowledge (PMBOK), fourth edition describes schedule crashing as a type of schedule compression, including overtime and paying for expedited delivery of goods or services as schedule crashing techniques (PMBOK, p. 156), though I generally think of overtime as another type of schedule compression – not crashing.
From a scheduling perspective, schedule crashing assumes that a straight mathematical formula exists between the number of laborers, the number of hours required to complete the task, and the calendar time required to complete the task. Said simply, if a 40-hour task takes one person five days to complete (40 hours/one person * 8 hours/day=5 days), then according to schedule crashing, assigning five resources would take one day (40 hours/5 people*8 hours/day=1day).
In that same article, they provide the answer to what you're looking for (how can a project manager decide if crashing will help?),
Is the task (or group of tasks) in the critical path? Tasks in the critical path are affecting the overall duration and the delivery
date of your project, while tasks outside of the critical path are not
affecting your delivery date. Unless the task your considering
crashing is in the critical path or will become a critical task
activity if it substantially slips, crashing the activity is a waste
Is the task (or group of tasks) long? If the task is short and does not repeat over the course of the project, then it’s unlikely
you’ll gain any benefit from crashing the activity. A long task or
task group, however, is far more likely to benefit from the addition
of a new resource, as can tasks that require similar skills.
Are appropriate resources available? Crashing is rarely useful when qualified resources are not available. Is there a qualified
person on the bench who can be added to the project team to perform
the work? If not, can someone be brought in quickly who has the needed
skills? Recruiting skilled resources is a costly and time-consuming
activity, so by the time the resource(s) are added to your team, the
task may be complete and your recruiting efforts wasted.
Is ramp-up time short? Some types of projects require a great deal of project-specific or industry-specific knowledge and it takes
time to transfer that knowledge from the project team to the new team
members. If the ramp-up time is too long, then it may not make sense
to crash the schedule.
Is the project far from completion? Often, people consider crashing when they’re near the end of a project and its become clear
that the team will not meet it’s delivery date. Yet, this may be the
worst time to crash the schedule. Frederick Brooks told the story
about his schedule crashing attempt in “The Mythical Man-Month” where
he added resources to one of his projects at the tail end, which
further delayed delivery. In most cases, schedule crashing is only a
viable option when a project is less than half complete.
Is the work modular? On many projects, the work being delivered is modular in nature. For example, in automotive engineering, it’s
possible for one part of the team to design the wiring for a new
vehicle model while another part of the team designs the audio system
that relies upon electricity, as long as points of integration and
dependencies are defined early. Through fast-tracking, or completing
these tasks in parallel, it becomes beneficial to also add resources,
crashing the schedule.
Will another pair of hands really help? All of us have heard that “too many cooks can spoil the broth,” but this also applies to
engineering, software development and construction. Consider where the
new resources would sit, how would they integrate with the current
team, would their introduction cause an unnatural sharing of roles?
So ask yourself these questions while looking at your project and have fun making it happen.