Plan for Plan B
“In government, the political environment and public stakeholders play a major role in decisions to crash a schedule. When that needs to happen, the first thing we look at is the critical path activities that will yield the biggest compression benefits and then determine which can be done with minimal-to-no impact to the project budget.
Depending on project complexity and requirements, it can be a good idea to do up-front contingency planning—develop a list of critical path activities and tasks that could be outsourced quickly, or make note where resources are more abundant. As you build the project schedule in the initiation phase, identify those ‘crash’ opportunities, though you may or may not choose to deploy these.”
—Candice Leonard, strategic systems and section, Oregon Department of Transportation, Salem, Oregon, USA
Communicate the Crash
“ I decide to crash the schedule when part of the project will jeopardize a main step in the schedule. For example, in a commissioning phase, if four or five different companies are scheduled to work within the same time frame and if a component is missing, it will cost more money to reorganize this phase. So, the cost of expediting one component will be lower than the cost of jeopardizing the milestone.
The biggest challenge to successful crashing is properly communicating its importance. That means talking to team members, for whom the crash is a new priority over regular tasks, the design leader and the project purchaser, as well as any suppliers involved.
I also check that every component will be ready on time and refocus our expectations if necessary. For example, I work with the design leader to make sure that all the parts are compatible. If we need to, we might ask the supplier to manufacture components very quickly, omitting the usual painting, which can be done later.”
—Jérôme Huet, PMP, project manager, engineering, procurement and construction, head of project managers group, Sandvik Construction, Paris, France
Consider the Long View
“There are four reasons that could make me decide to crash a schedule: The project is delayed, I require a team for another project that's time-critical, I have a free resource, or I have a resource that needs to be trained on a particular technology.
In the ideal scenario, only the first reason would be valid. But we live in the real world, so other reasons also come into play. Even if you're working on one project, you're aware of other requirements and other projects, and you may need to crash the schedule so that another project may also take off.”
—Abhigyan Srivastava, PMP, senior project manager, HCL Infosystems Ltd., Noida, India, via the PMI Project, Program and Portfolio Management LinkedIn Group
Avoid the Burn
“When a deadline cannot be extended (after confirming with the client and project sponsor), and other parts of the project cannot be modified or shortened to free up resources for the delayed parts, crashing becomes the only option. There are pluses and minuses, of course. It helps you recover the schedule, but sometimes at the risk of a tired staff (if you're using the same project resources), miscommunication (if you're using new resources), lack of time to test adequately and lower quality.
If using new resources, build in time to bring them up to speed. If using the same resources, be careful not to burn them out. Provide a clear project plan on the crashing to project stakeholders. Clarity is key for the crashing tasks, so be clear at a granular level: Who is assigned which tasks? How long will each person be working on them? What are the expected results of the crashing?”
—Julio Calderon, PMP, program manager, Symitar, San Diego, California, USA
Seek Returns
“The traditional goal of crashing is to obtain the greatest amount of compression for the least incremental cost. But the least incremental cost is not sufficient; we need to obtain the greatest ROI for the crash investment. Analyzing this variable—after considering other techniques—we can determine if crashing the project is actually a good option in a particular instance.
If crashing adds new resources to a project, there are new associated risks and costs. Added resources can have a big impact at the management level. You should consider this impact and define the best way to manage the project with the new resources. Finally, note that gain in performance is not proportional to resources added; additional resources can sometimes reduce project performance.
Here's an example: We're thinking of crashing the schedule of an ongoing project and have three scenarios to consider.
The Fast Track
There's more than one way to compress a schedule. Fast-tracking is a common alternative to schedule crashing. With fast-tracking, certain tasks are overlapped despite their dependencies. What do you prefer: schedule crashing or fast-tracking? Share your thoughts on the PMI Project, Program and Portfolio Management LinkedIn Group.
- Temporarily add a new senior team member Trade-off: 5 days of delay on the schedule for knowledge transfer and resolving miscommunication issues Gain: 25 days
Net Time Reduction on the Schedule: 20 days - Temporarily add a new junior team member Trade-off: 10 days of delay on the schedule for knowledge transfer and resolving miscommunication issues
Gain: 10 days
Net Time Reduction on the Schedule: 0 days Remove this option. - Add a new tool to automate a task Trade-off: 5 days of delay for training Gain: 35 days
Net Time Reduction on the Schedule: 30 days
But then you need to calculate the ROI of crashing the schedule. I use the following formula: ROI = (profit per day × time gained in productivity) - resource cost. In the two remaining options, the calculations would be:
- ROI (new senior team member) = (US$2,000 × 20) – US$20,000 = US$20,000
- ROI (new tool) = (US$2,000 × 30) - US$45,000 = US$15,000
This analysis shows that the best choice here is to add a new senior team member when we crash the schedule.”
—Patricia Lira Mogollón, PMP, project manager, operational efficiency, auto leasing company Arval, BNP Paribas Group, Paris, France
What's Your Problem? We'll help you solve it by asking practitioners around the world for advice. Send your project questions or issues to [email protected].
PM NETWORK JULY 2014 WWW.PMI.ORG
JULY 2014 PM NETWORK