7 Examples of Crashing

John Spacey, July 24, 2023

Crashing is a schedule compression technique that seeks to deliver project, initiative, task or activity faster by adding more resources. Generally speaking, this increases risk, cost and creates inefficiencies in order to improve delivery speed. The following are common examples of crashing.

Increased Staffing

Reassigning contributors to get more people working on the critical path of a project.

Overtime

Negotiating with existing resources to work longer hours for increased compensation.

Technology

Increasing the technology resources such as cloud computing budget available to a task.

Resource Optimization

Assigning senior and high performing resources to the critical path.

Workforce Expansion

Using consultants and freelancers to increase the number of people assigned to a project.

Debottlenecking

Clearing constraints so that resources can focus on the critical path. For example, canceling all meetings.

Charrettes

Putting a team in a room together until a critical task is completed.

Crashing Risks

There is a great deal of overhead in adding more resources to a task in areas such as communication and collaboration. This is summarized with the humorous analogy "nine mothers can't have a baby in one month." Crashing risks lower quality, more failures, cost overruns, reduced stakeholder satisfaction and decreased team morale.

Crashing vs Fast Tracking

Fast tracking is the practice of trying to deliver tasks with dependencies in parallel. As with crashing, this can accelerate the critical path of a project but increases risk and generally decreases efficiency. This is due to the complexity of trying to deliver a task at the same time as something on which the task depends. For example, trying to begin framing the walls of a house while the foundation is being constructed.

Crashing vs Scope Reduction

A more efficient approach to delivering things quickly is to identify what really needs to be delivered first and reducing scope. This can be done with pareto analysis or minimum viable product. It is common for stakeholders to claim they need expansive requirements on an aggressive deadline. This requires an executive with much authority and change management experience to push them to prioritize into small but fast releases.

Next: Schedule Compression