PMBOK and some other project management standards describe two key methods for schedule optimisation: fast-tracking and crashing.

Apart from these well-known methods, there is a method that hasn’t been described widely. So, let’s feel in the gap.

This method works as it sounds: opposite to the crashing method. So, let’s review the project crashing method first.

Adding extra resources is not the only way to reduce the duration of an activity.

• Activity duration can also be reduced by assigning resources with higher productivity rates or by changing resource calendars: extended working hours, work on weekends and holidays, additional shifts, etc.
• Project duration can be reduced only when crashing is applied to activities on the critical project path.
• Just like two women can’t deliver a baby in 4.5 months, the duration of some activities can not be reduced by deploying additional resources
• Duration of activities does not always have a linear dependency on a number of assigned resources. This issue was discussed in the “Project Team assignment” post.

The crashing method sounds very logical and easy to understand. However, project life is not as simple as it’s described in project management books. In real-life situations, there are cases when project duration can be shortened by REDUCING assigned resources.

Project Critical Path: A – B – C – D – E

Project Duration: 42 days

Resources assignments:

Activity “B”: 2 resources

Activity “C”: 2 resources

Activity “D” 2 resources

A project manager wants to speed up this project and has an opportunity to deploy additional resources to activities B, C and D.

 Let’s analyse how this potential optimisation would work:

 Assume critical Activity “B” has two additional resources assigned. Then the activity will be completed in 10 days (instead of 20 days), and the whole project will also be delivered 10 days sooner, equalling 32 days.

The same result will be seen, if Activity “D”, has 4 assigned resources (instead of 2).

 Now let’s apply crashing to Activity “C”. If 2 additional resources are assigned, this activity will be completed in 4 days (instead of 8).

The critical path will be the same, and the new duration of the project will be 46 days.

Wait, now the project will take 4 days longer, not shorter (!!!).

 What if we do the opposite and reduce the number of assigned resources in Activity “C” from 2 to 1?

In this case, Activity “C” will be completed in 16 days (instead of 8), and the new duration of the project will now be 34 days.

 So, as we can see, when we reduce the number of assigned resources, the duration of the activity will increase. However, the duration of the whole project will decrease (!!!).

It is not just a theoretical example; projects often have parallel activities performed by different teams or crews. In this case, start-to-start and finish-to-finish (sometimes lags and leads) logic is applied. Different teams/crews may have different productivity rates, and often the less productive team assigns extra recourses to their critical activity. However, applied crashing may sometimes lead to the opposite result. In those cases, projects need to apply the “anti-crashing” method instead.

Both crashing and anti-crashing methods focus on changes in resource management.

If the crashing method increases assigned resources to reduce the duration of critical activity, the anti-crashing method, on the opposite, reduces assigned resources to bring the start date of critical activity earlier.

Actual schedules are much more complex than the example in this post, and it is not always easy to identify when anti-crashing needs to be applied instead of crashing. In the next post, I am going to explain how to identify these cases.