Cost Reduction by Crashing of Activity

Optimizing Project Duration and Cost Through Schedule Compression

What is Crashing?

Crashing is a schedule compression technique used to reduce the project duration by adding additional resources to critical path activities at the least incremental cost.

It involves making cost-time tradeoffs to achieve the optimal balance between project duration and total cost.

When to Use Crashing

Important Considerations

Crashing is not always the best solution. Consider:

The Crashing Process

1

Identify Critical Path

Determine the current critical path and its duration using CPM.

Only activities on the critical path are candidates for crashing.

2

Determine Crash Costs

For each critical activity, identify:

3

Calculate Cost Slopes

Determine the cost per time unit for crashing each activity:

Cost Slope = (Crash Cost - Normal Cost) / (Normal Duration - Crash Duration)

The slope represents the additional cost per unit of time saved.

4

Prioritize Activities for Crashing

Start with activities that have the lowest cost slope (cheapest to crash per time unit).

Create a prioritized list of crashable activities.

5

Implement Crashing

Crash activities in order of priority until:

Time-Cost Tradeoff Curve

[Visualization of time-cost tradeoff showing optimal crash point]

The curve shows the relationship between project duration and total cost, helping identify the optimal crash point.

Crash Analysis Example

Activity Normal Duration Normal Cost Crash Duration Crash Cost Cost Slope Max Crash Days
A (Critical) 10 days $5,000 7 days $8,000 $1,000/day 3 days
B (Critical) 15 days $10,000 12 days $13,000 $1,000/day 3 days
C (Critical) 8 days $4,000 6 days $5,000 $500/day 2 days
D (Non-critical) 12 days $6,000 9 days $9,000 $1,000/day 3 days

Crashing Strategy

  1. First crash Activity C (lowest cost slope at $500/day) by 2 days → Total cost increase: $1,000
  2. Then crash Activities A and B (next lowest at $1,000/day) by 1 day each → Total cost increase: $2,000
  3. Total project duration reduced by 4 days (from 33 to 29 days) at additional cost of $3,000

Real-World Application: Software Development Project

Scenario: A software project has a critical path duration of 90 days, but the client needs it in 80 days to meet a trade show deadline. Early completion bonus: $50,000.

Crash Analysis:

Optimal Solution: Crash requirements by 3 days ($6,000), development by 7 days ($10,500), and testing by 0 days. Total cost: $16,500. Net gain: $33,500 bonus.

Knowledge Check

Question 1: An activity has normal duration 8 days ($4,000), crash duration 5 days ($7,000). What is its cost slope?

Question 2: Why shouldn't you crash activities that aren't on the critical path?

Scenario: Your project has two parallel critical paths after initial crashing. How does this affect further crashing decisions?

Advanced Crashing Concepts

Multiple Critical Paths

After initial crashing, new critical paths may emerge. You must then crash activities on all critical paths simultaneously to further reduce project duration.

Indirect Costs

Consider how crashing affects indirect costs (overhead, facilities, etc.) which may decrease with shorter durations.

Non-linear Crashing

In reality, cost slopes may not be linear - crashing becomes progressively more expensive.

Best Practices for Effective Crashing