It was Lady MacBeth who warned, “What’s done cannot be undone.” And yet, after scheduling project work, you may discover the schedule needs to be “crashed.” Crashing a project means shortening the project schedule by compressing the critical path without changing the sequence of work. The critical path is the longest sequence of activities that must be completed for the project to be finished on its due date. Because it is the minimum time it will take to complete an entire project—if something impacts the duration of work packages on this path, it will directly impact the finish date. Crashing involves a trade-off: shorter work package durations potentially require higher work package costs to meet the shorter schedule with additional resources.
Before crashing, ensure that reducing project duration is worth increased costs or other consequences. For example, is a penalty associated with project delay greater than the increased costs or compromised quality of shortening the duration?
Project managers too often must crash a project to meet a deadline set by someone else. As they consider ways to compress the critical path—overtime, additional resources, splitting into concurrent work packages—resources can become so strained that overall success is threatened. Sometimes shaving time cannot be achieved if part of the work simply cannot be done within the new deadline. In addition, crashing a project can put a strain on other projects within an organization as resources are redirected from other project work thereby delaying their important deadlines.
Gotta crash? Successfully crashing a project relies on having a good project plan. In projects, the work is broken into components—the various achievements and objectives that must be delivered during a project (deliverables). Deliverables are grouped into manageable work packages that allow a reasonable estimation of the time and resources needed to get this portion of the work done. Adjusting work packages on the critical path can make it possible to shorten the project timeline.
To crash a project, review the project plan and ask these questions:
Which work package durations on the critical path can be shortened? How?
Which work packages can be divided to run concurrently?
How can the relationship or order of work packages on the critical path be altered to shorten the schedule?
How can slack time be used to complete additional work or reallocated resources on the critical path?
What is the most likely potential problem posed by the chosen crash strategy? What three things can be done to prevent these from happening? What actions will you take if this problem happens anyway?
While crashing a project can be risky and expensive, when a shorter timeframe is essential, good project planning pays off. A successful project plan maps out exactly who is going to do what, when they are going to do it in calendar time, and how to mitigate any risks to the plan. Crashing a project relies on working with an accurate and comprehensive project plan and ups the stakes for project success throughout the life of the project.