liveBook · Manning

Project crashing

As explained in Statistics Every Programmer Needs

Project crashing is a scheduling technique that shortens project duration by reducing the time allocated to one or more critical-path activities, usually at additional cost.

Project crashing shortens a project by reducing the duration of one or more critical-path activities, usually through overtime or added resources. Because schedule, cost, and scope are interconnected, acceleration is worthwhile only when earlier completion justifies the additional expense. section 13.5 section 13.6

Use the cost-effective crashing procedure:

  • Replace expected activity times with most-likely times and recalculate the critical path when the estimates differ. section 13.5
  • Calculate each activity’s weekly crash cost, using the additional cost per unit of time saved and assuming linear crash costs. section 13.5
  • Select critical-path activities with the lowest weekly crash costs; crashing noncritical activities raises cost without shortening the overall project. section 13.5

Automated reporting tool project

The activity estimates classify A, B, C, D, E, G, J, K, and L as critical. Activities A, B, C, E, G, K, and L each have a $1,000 weekly crash cost, while noncritical activities such as F, H, and I should not be crashed merely to reduce duration. section 13.5

Table 13.5 Most likely and crash estimates for the automated reporting tool project in weeks and dollars. The most effective way of accelerating a project timeline is to crash one or more critical path activities with the lowest weekly crash costs.
Activity
Time (weeks)
Cost ($)
Weekly crash cost ($)
Critical path?
Most likely
Crash
Most likely
Crash
A
3
2
5,000
6,000
1,000
Yes
B
2
1
4,000
5,000
1,000
Yes
C
3
2
5,000
6,000
1,000
Yes
D
5
4
9,000
11,000
2,000
Yes
E
3
2
5,000
6,000
1,000
Yes
F
4
3
8,000
9,000
1,000
No
G
4
2
8,000
10,000
1,000
Yes
H
3
2
5,000
7,000
2,000
No
I
3
2
5,000
6,000
1,000
No
J
4
2
7,000
10,000
1,500
Yes
K
3
1
5,000
7,000
1,000
Yes
L
2
1
4,000
5,000
1,000
Yes

Compare most-likely and crash durations, costs, weekly crash costs, and critical-path status for each project activity. section 13.5

How Statistics Every Programmer Needs covers it

How deep it goes
Explains the technique through critical-path recalculation, weekly crash costs, activity selection, and a linear-cost assumption.
Examples
Uses an automated reporting tool project with activity estimates, crash estimates, costs, and critical-path labels.
What it assumes
Assumes familiarity with critical paths, project activities, schedules, and costs.
What you can do after
Apply project crashing by recalculating critical paths, comparing weekly crash costs, and prioritizing eligible activities.
How it connects
Connects project crashing to critical paths, project schedules, costs, scope, and probability of on-time completion.
Cover of Statistics Every Programmer Needs
liveBookmanning.com
Read Statistics Every Programmer Needs on liveBook Get the book at manning.com

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Statistics Every Programmer Needs. The section links point to the parts of the book it draws on.