Project Crashing: Schedule Compression Technique

Panic sets in as deadlines move closer and closer with no finish in sight. I have felt this far more times than I would have liked. The hope comes with the technique of project crashing. This technique allows the timeline to be accelerated without altering the scope and/or objectives.

The technique of schedule compression has helped many projects from falling apart. If you are planning to take a certification in project management or an advanced course in project management, one of the necessary skills is to be able to know when and how to crasha project schedule. Most PMP certification training programs provide this as one of the core skills that help in making the right decisions when faced with compression.

Project crashing is a technique where you speed up the processes to meet a specific deadline by adding more resources to the most critical tasks. In other words, you are going to be spending more to finish the project in a shorter time.

PMBOK guide explains crashing as a schedule compression technique that deals with the time and costs of a project to get the most time under the smallest costs. Simply put, the technique is how to find the least amount of money to buy time on a project.

The unique aspect of crashing is that you do not alter the work being produced or compromise on quality. Instead, you add resources to the equation. This can mean new team hires, overtime hours, contracted work, or new equipment rentals.

Despite how easily the terms crashing and fast tracking can be confused, they are different in almost every respect.

In fast tracking, tasks that have been originally planned to happen sequentially are run in parallel. This presents more risk, as you are working on dependent activities at the same time. On the contrary, crashing is more expensive, but safer. If you just need tasks finished faster, crashing is the direction you want to go.

Coordinating the two can sometimes be ideal, but that is a task that requires a lot of effort and solid leadership to be successful.

Crashing is not an option that should be used indiscriminately on delayed projects. I always wait for specific signals to recommend this approach.

You should crash your schedule when:

• You are markedly behind on a deadline that cannot be shifted
• There is a budget for more resources
• You have a clear understanding of the critical path
• Adding resources is likely to speed up the project
• There are quality constraints

You should NOT crash when:

• Your budget is burned out
• Tasks cannot be sped up by adding more people
• Scope changes are likely to be a better solution
• The delay is from external dependencies
• You would be adding more coordination nightmares by adding resources

In one construction project, for example, the client moved the completion date up by two months. We had the budget, and once foundation and framing crews were available, we were able to move them to accelerate active foundations and framing. That was a perfect example of a scenario where we were able to take advantage of schedule crashing. On the other hand, falling behind on unclear requirements during a software project was just a scope issue, and crashing wouldn't have helped.

Most people are dead set against a project being crashed, and perhaps rightly so. However, the advantages of project crashing, when done properly, are quite significant. Perhaps the most obvious advantage is, of course, the meeting of critical deadlines that seemed to be impossible. In fact, I have seen a number of projects that were able to avoid a substantial penalty clause being imposed due to the project being completed shortly before the deadline.

In contrast to reducing deliverables or cutting features, project crashing allows you to maintain your entire project scope. This is particularly important for protecting your reputation with clients, as well as your client relationships, as you will be completing everything your stakeholders requested.

From a risk perspective, crashing is preferable to fast-tracking. You are not executing tasks that are dependent on one another, meaning there is a lower chance of expensive rework. The risks taken are more controllable and easier to predict.

Grasping the triple constraints of project management provides insight into how crashing integrates into the overall strategy. You are deliberately assuming a higher cost to save time, with the scope remaining unchanged.

The truth about the disadvantages of project crashing is that it is expensive. Overtime wages, temporary workers, and high-cost contractors all create an economic burden. Equipment rentals also contribute to the cost. I have observed that the cost of crashing exceeds the original budget by 30-50%.

Your team is under more pressure and forced to work longer hours. This can result in burnout and a decline in morale, which can ultimately lead to lower productivity. Let's face it, the delays you are trying to avoid can return if your team is exhausted.

Your project will reach a point of diminishing returns. The addition of a third developer might enhance productivity, but the addition of a tenth may result in a decrease due to the increased need for coordination. This is where project management experience and careful budgeting become extremely important.

Being alert to quality issues is essential. In rush orders, testing and documentation are often deprioritised. I implement distraction-proof quality assurance checkpoints every step of the way to help capture issues before they become larger problems.

Methodical approaches are essential for successful project crashing. Here is my recommended process.

Step 1: Find the Critical Path

Only the activities of the critical path can be crashed as they directly contribute to extending the project's finish date. Refer to your project management plan to identify the activities with zero float that directly influence the project's deadline.

Step 2: Assess the Cost of Crashing

For every activity on the critical path, determine the cost of shortening the duration by 1 time unit. This cost, divided by the unit of time, will guide your decision on which activities to crash first, with those that have the lowest cost per unit time to crash prioritised.

Step 3: Plan the Compression

Prioritise the activities to be crashed based on the cost data. In some cases, it will be viable to crash multiple activities at once. In other cases, it will be necessary to crash one activity, recalculate the critical path, and make further decisions about what to crash. This is where decision tree analysis will become critical for evaluating your options.

Step 4: Quickly Prepare Required Contracts

With decisions made regarding which projects to crash, quickly prepare the necessary contracts. For example, contract labour, overtime, or shift realignment. Get expectations to them clearly.

Step 5: Very Close Monitoring

Crashing hasa far greater need for close monitoring than normal project management. Daily monitoring, tracking costs, and adjusting, of your own accord, is essential if things are not to go as anticipated, are all part of this.

A commercial building project had an expected duration of 10 months. 10 months into the project, the client had a more profitable tenant agreement and needed the building to be occupied two months earlier. It was impossible for us to walk away.

We looked at the critical path and determined that the work of finishing interiors could be accelerated. The downside of this was an estimated additional $45,000 for two more finishing crews, but the time saving was 6 weeks. Crashing the HVAC installation was also possible by bringing on a second contractor, which cost an additional $22,000 and saved 3 weeks.

Total additional costs of $67,000 and total time saving of 9 weeks meant we met the client's new deadline with a one-week buffer. The client was pleased, and the expense was justified simply by avoiding a penalty.

While compressing schedules, I have developed a number of rules that have worked for me consistently.

Always maintain clear, honest communication with stakeholders regarding costs and trade-offs. Keep them in the loop on all aspects. If crashing the schedule means going over budget, prior approval from stakeholders will need to be obtained.

Crashing should be concentrated on the critical path. I've seen project managers accelerate the wrong tasks, ones that have a good deal of float. It's a waste and quite annoying.

Help your team through the increased workloads by which team members worked additional shifts, and publicly appreciate this. Also, provide the needed resources to the team and be on the lookout for burnout. A team whose morale is depleted will have a positive drive not to produce good quality work, regardless of the pay.

Make sure to write down your revised calculations, your crashing decisions, and the results that came about from this data.
While it is clear that these will be useful for the exam, they will also ensure that you will be comfortable using them in the real world.

Knowing how to master techniques like crashing will enable you to differentiate yourself from the competition. Moreover, while schedule crashing isn't suitable for all situations, understanding the appropriateness of crashing in the required circumstances can positively affect your projects, your clients' relationships, and your career prospects. Consequently, the best approach is to use a combination of your analysis and reasoned thinking, rather than relying on the pressure from the deadline, to arrive at your decision.