Schedule Health Metrics: Activity Constraints

Schedule Health Metrics: Activity Constraints

by | 1 Jun, 2022 | Blog

In this article, we continue to review metrics for schedule health analysis. The first part, “Missing Dependencies” was covered here. Now let’s talk about activity constraints.

There are some project situations that require the use of constraints:

Delayed Start

Sometimes a project has a situation when it is impossible to start the activity even if all prerequisite work is completed.

Example: Project is ready to start testing but the test environment is only available from next week.

Deadlines

If a Project has committed dates, we need to understand how the project is performing against these commitments, also known as project deadlines.

Example: Based on the business case project committed to delivering three Outputs by 1st October, 1st January and 1st of April.

Locked Dates

Some projects have locked dates when there is no flexibility to move the start and finish dates.

Example: The Olympic opening ceremony in Brisbane is locked to 23 July 2032.

As Timely As Possible

If there is flexibility when activity could be performed without impacting key delivery dates there are three options to specify the start and finish date:

  • As Soon As Possible (ASAP)
  • As Late As Possible (ALAP)
  • As Timely As possible (ATAP)

Starting an activity ASAP is usually considered the best approach. In practice, however, starting the activity as soon as it can or leaving it ALAP can both have problems associated with them. ATAP could be achieved with constraints, lags or calendars. Constraints are more visible and often are the best approach.

Examples:

  • If the project might require delivery through the Caribbean in September, they might want to put in a constraint to delay the trip until October 15, after the height of the Atlantic hurricane season.
  • A union contract may expire on June 3, with the potential for a strike. In that case, the project might want to make sure that certain work gets performed before then.

How many constraint types are required to simulate these scenarios?

All possible scenarios in projects could be specified with only two types of constraints:

  • Start No Earlier Than (SNET)
  • Finish No Later Than (FNLT)

No Earlier Than (NET):  Prevent an activity from being scheduled to start before a specific calendar date.

No Later Than (NLT): Specify that an activity needs to be finished before a specific calendar date.

‘Deadline’ and ‘Locked dates’ events are presented with a milestone. As a milestone always has the same start and end dates there is no need to have additional Finish No Earlier Than (FNET) and Start No Later Than (SNLT) constraints. It just adds complexity to the schedule.

‘Locked dates’ and ‘As Timely As Possible’ scenarios could be represented by applying SNET and FNLT constraints simultaneously.

ASAP and ALAP are actually not constraints, even though they are listed in constraint types in Primavera and Microsoft Project. ASAP and ALAP could be presented as a switch as it is done in Spider Project.  

Activity constraints are essential to represent real-life project scenarios in schedules correctly. At the same time, incorrect application of constraints may have a negative impact on the management of project reserves or even the project delivery dates. Activity constraints may impact Free Float, Total Float and even Project Critical Path. This impact has to be analysed and accepted. So, we need Schedule Health Metrics to identify the incorrect application of activity constraints. There are some nuances that have to be discussed first.  

Constraint Terminology

Scheduling tools use different terms to describe types of constraints.

As explained above only ‘Finish No Later Than’ and ‘Start No Earlier Than’ are true types of constraints.

Primavera has 4 types of Start and 4 types of Finish constraints. Not all planners understand the difference between ‘Finish On’ vs ‘Mandatory Finish’ and ‘Start On’ vs ‘Mandatory Start’. The key difference is that ‘Mandatory’ constraints allow violation of schedule logic and ‘On’ constraints are complementary. As the result, it impacts the calculation of Total Float.

Microsoft Project offers users to decide whether the conflict is allowed:

Manage Deadlines

Also scheduling tools have totally different approaches to managing ‘Deadline’ scenarios.

  • Primavera has separate constraints types to simulate ‘Locked Dates’ and ‘Deadlines’ scenarios.
  • MS Project has an additional ‘Deadline’ field for the deadline date det up.
  • Spider Project always calculates Total Float with and without the deadline (NLT) It has additional column fields to present and compare both results.

These differences have to be reflected in the Constraints Health Check metrics.  

Hard and Soft Constraints

Some portfolios use ‘Hard’ and ‘Soft’ terms to divide constraints by softness.

There is no common agreement on what ‘Hard’ and ‘Soft’ actually mean.

Some Project Managers assume that ‘Soft’ constraints are ‘nice to have’ constraints and could be deleted if a fast-tracking is required. Others mean that ‘Soft’ constraints refer to resource (not technical) constraints. Arguably, the most popular differential amongst planners is based on a logical priority. ‘Soft’ constraints never violate network logic (but still may generate negative total float) and ‘Hard’ constraints take priority over network logic dependency relationships.

‘Hard’ constraints:

Delay of activity ‘A’ doesn’t push Activity ‘B’. The ‘No Later Than’ constraint followed. Relationship A->B is broken. The project is not logically driven anymore.

‘Soft’ constraints:

Delay of activity ‘A’ push Activity ‘B’. The ‘No Later Than’ constraint is ignored. Relationship A->B is followed. The project is logically driven.

However, some Primavera planners define ‘Hard’ constraints as ‘Mandatory Finish’ and ‘Mandatory Start’ constraints only and others also add ‘Start On’ and ‘Finish On’ constraints to the definition. Recently, I have seen scheduling standards that in one part of the document define ‘Hard’ as Mandatory Start and Finish only, and in another part of the document it also includes ‘Start on’ and ‘Finish On’. This could be driven by different definitions in international scheduling standards.

Planning & Scheduling Excellence Guide (PASEG) published by National Defence Industrial Association (NDIA) defines ‘Hard’ constraints based on Primavera terms (or did Primavera developers apply NDIA term?) and the definition includes 2 types only: ‘Must Finish On’ and ‘Must Start On’.

GAO Schedule Assessment Guide uses Microsoft Project terms (or did Microsoft developers apply GAO terms?) and the definition of the ‘Hard’ constraint includes 4 types: ‘Start No Later Than’, ‘Finish No Later Than’, ‘Must Start On’, and ‘Must Finish On’.

‘Start No Later Than’ and ‘Finish No Later Than’ constraints don’t violate the logic but are somehow still defined as ‘Hard’.  

DCMA 14 Points Schedule Assessment

DCMA 14 Points Schedule AssessmentDCMA 14 Points Schedule Assessment includes a metric to control the percentage of Hard constraints: “Number of activities with hard or two-way constraints should not exceed 5%”.

If a scheduled health check includes the terms ‘Hard’ & ‘Soft’, to avoid misunderstanding of the terms there need to be clear definitions established.

Points to Consider

  • All constraints must be explained. Ideally, the clarification has to be in the schedule but if a scheduling tool doesn’t have a feature to document and export this information a separate register should be created.
  • As each project is different by nature, criticality and management style it is not possible to define one metric that could clarify that the schedule has too many constraints. At the same time, a number of constraints in a schedule is a very good indicator that the schedule could be not logically driven.
  • Some Planners and Master Schedulers fail to appreciate the nuances of constraints and instead restrict their use altogether. Constraints are essential to represent the project work correctly. If constraints are prohibited the schedules could not be used to drive project delivery, only to satisfy someone’s need to say that the project has a schedule.
  • What type of schedule health metric to use depends on scheduling tools. Constraints in Spider Project never violate network logic, so metric is not required to control the quality of schedules. In Primavera and Microsoft Project, incorrect application of constraints may impact the calculation of Critical Path and Total Float, so users of these systems have to learn how the constraints work and decide which types of constraints have to be limited or restricted. They need a schedule quality metric to identify constraints.
  • If an activity already started it doesn’t matter if the start was constrained or not. Also, if an activity is completed it doesn’t matter if the start or finish of the activity was constrained. Such activities should be excluded from metrics.
  • Level of Effort, Hammock and WBS Summary activities should be without constraints. A separate metric should be developed to control that.
  • Primavera and Spider Project allow the setting of two constraints to the same activity while Microsoft Project allows only one. It limits Microsoft Project users to simulate all ATAP scenarios. As a workaround, all constraints (presented by milestones) could be stored under the same WBS. Then related activities are linked with the corresponding milestones. 
  • ‘Locked Dates’ and ‘ATAP’ are actually calendar constraints, not characteristics of activities and ideally have to be realised in the schedule via calendars and not via activity constraint dates. Unfortunately, Primavera is not able to calculate the schedule correctly taking both activity AND resource calendar constraints into account. Planners have to choose between activity OR resource calendars. Microsoft Project and Spider Project don’t have this problem. We will review this challenge in detail in a future post.

It also simplifies the control of constraints as all constraints outside of the WBS are considered as schedule quality issues. 

 

  • If an activity is left as late as possible, unforeseeable events can occur that make the activity take longer than anticipated, resulting in missed deadlines. So, it is strongly recommended to use pessimistic estimation as a base for all ALAP activities to have sufficient contingency and not delay the project.

Schedule Health Metrics: Constraints

Taking all these nuances into the consideration the following Schedule Health Metrics are useful:

Constrained Activities

A number and percentage of activities with constraints is a good indicator that could show that the schedule is not logically driven.

It is possible to develop filters to identify Hard and Soft constraints.

 

Primavera Hard Constraints Filter

Primavera Soft Constraints Filter

Unexplained constraints

Another Metric could help to identify constraints without an explanation. The method to identify them depends on the way the information is captured.

 

ALAP activities

Special attention has to be to all ALAP activities.

 

Technical and Resource Constraints  

Apart from DATES constraints, there are other types of activity constraints that also must be taken into the consideration:

  • Could an activity be split?
  • Does the activity need to be performed on the same date (or shift)?
  • How many minimum resources are required to complete the activity?
  • Is it technically possible to add more resources?
  • Would additional resources increase or decrease overall productivity?

 We are going to discuss these types of activity constraints in a future post.

Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma

Schedule Logic Check Metrics

Schedule Logic Check Metrics

by | 12 May, 2022 | Blog

One of the fundamental questions for any schedule health assessment is “Is the schedule logically driven?” There are some scheduling metrics that could help planners and schedulers to find the answer to this question. In this post, we will review some of them, that are related to missing dependencies.  

Missing Dependencies Metrics

Missing logic metrics is a group of metrics known as:

 

  • missing dependencies,
  • missing predecessors and successors,
  • open start & finish,
  • dangling activities.

This check is not as simple as many project managers and schedulers might think. In fact, it is actually very hard to answer the question: Are there any missing or incorrect dependencies in the schedule?

A very popular DCMA-14 Points schedule assessment includes a check of logic (metric N1). Schedulers who are familiar with a scheduling tool (usually Primavera or Microsoft Project) but lacking scheduling knowledge very often apply DCMA-14 “blindly”. Their schedule may have critical logical issues but is reported as a schedule with sufficient quality. I have seen this issue in small business projects and also in large construction programs. So, let’s review what needs to be considered for a comprehensive schedule logic analysis.

Missing Dependencies?

There is no metric that could confirm that a schedule has no dependencies missing.

The fact that each activity (except first and last) has a predecessor and successor doesn’t mean that another successor from/to this activity is not missing. The only way to guarantee that a schedule has correct logic is to implement correct schedule development and maintenance processes and apply control to ensure these processes are followed.

Each reporting period logic changes have to be analysed, documented and explained.

While scheduling metrics can’t guarantee that dependencies are not missing, some of them are good indicators that logic has to be checked and, if required, fixed. There are four primary schedule quality metrics used to indicate that a schedule may have a missing dependency:

♣   Missing Predecessor

All ‘Not Completed’ activities except 1st activity and external incoming activities must have a predecessor(s).

♣   Missing Successor

All ‘In Progress’ or ‘Not Started’ activities except the last activity and external outcoming activities must-have a successor(s).

♣   Open Start

Activities where only the predecessor(s) are either ‘Finish-to-Finish’ or Start-to-Finish resulting in an open start to the activity. All ‘Not Completed’ activities except 1st activity and external incoming activities must have at least one ‘Finish-to Start’ or ‘Start-to-Start’ predecessor.

♣   Open Finish

Activities where the only successor(s) are either ‘Start-to-Finish’ or ‘Start-to-Start’ resulting in an open finish to the activity. All ‘In Progress’ or ‘Not Started’ activities except the last activity and external outcoming activities must have at least one ‘Finish-to-Start’ or ‘Finish-to-Finish’ successor.

There is a number of points that have to be taken into consideration when these metrics are applied:

  • A project may have external dependencies and it is not always possible, and in some cases, not recommended to link schedules from different projects. Milestones representing such dependencies do not have predecessors or successors.
  • A Project may have Level of Effort (LoE), Hammock and WBS activities. Different scheduling tools implement these types of activities differently and this impacts the “missing logic” analysis. 

–   Hummocks in MS Project are shown without a predecessor and a successor but there is no way to identify “Hammock” type of activities in the system.

–   “WBS summary” activities in Primavera don’t need a predecessor or a successor. So they have to be excluded from the analysis. Another metric is required to check that “WBS summary” activities don’t have logic as Primavera permits linking activity to “WBS summary” activity.

–  In Primavera, if all activity successors are linked to LoE or “WBS summary” activities, the activity is actually missing a valid successor. Otherwise, based on the logic, there are no requirements to complete this activity. The same is applicable to predecessors. Such cases could only be identified via a specially developed project report, not via filters.

  • If a milestone has “Open Start” or “Open Finish” it actually doesn’t create any issues with logic. Milestones could be excluded from these metrics.
  • Microsoft Project has a unique feature to link activities with summary tasks. If this technique is applied it is very hard to analyse logic, as some of the activities are driven by logic from activities and some from summary tasks, so it is not recommended. An additional metric is required to identify summary tasks with processors and successors.

Filters

Missing logic metrics could be developed via filters in Primavera and Microsoft Project but, as described above, specifics of each tool have to be taken into account. Spider Project already has all these metrics build-in and also allows developing comprehensive additional filters as required.

Primavera filters to identify activities with missing logic:

♣  No Predecessors

♣  No Successors

♣  Open Finish

♣  Open Start

External Schedule Analysis Tools

When an external schedule analysis tool is used each metric has to be configured to address explained challenges. For example, Acumen Fuse has a pre-developed “Missing predecessors” metric. However, the metric includes ALL activities with missing predecessors. If an activity already started (or completed) it doesn’t matter if it has a predecessor or not. It is recommended to configure this metric to exclude these activities. Otherwise, the Acumen Fuse Report creates “noise” and may incorrectly show that the schedule has predecessors issues when it actually doesn’t.

Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma

Critical Path Drag

Critical Path Drag

by | 4 May, 2022 | Blog

Majority of project managers are familiar with the critical path method (CPM) and think that they know how to apply it to manage their projects.

Many scheduling software can compute and visualise Critical Path, so it is a no-brainer to use it. Usually, a project manager accepts the calculation as the schedule. The Critical path method doesn’t take resources, material and financial supply constraints into the consideration. So, the next steps become to assign resources, baseline the schedule and start to manage project progress.

This is because the project managers have forgotten that the “M” in CPM stands for method. The reality is that the first network is only the tentative schedule, giving just the data to implement the method fully. Once the initial CPM schedule has been computed and a logic diagram produced, the project manager is in a position to use the critical path method to save time and money. If, for instance, we want to shorten the project duration, we now know where to start: the current critical path!

There are three ways of trying to shorten the project:

1. Shorten the duration of activity on the critical path by:

  • adding extra resources
  • assigning resources with better productivity
  • ask resources to work more hours
  • change delivery method (a backhoe instead of 10 labours)
  • prune scope (gold planning)

2. Start critical activities earlier by:

  • applying anti-crashing method

3. Change logic and remove activity from the critical path by:

  • applying fast-tracking method

But the question is: Where should we add/remove these resources? Where should we review the scope? What will the effect be of such actions on the schedule and cost?

For the answers, we need CPM metrics.

One of the CPM metrics that could help us find the answers to the above questions was proposed by Stephan A. Devaux and explained in his “Total Project Control” book called Critical Path Drag. In the 1st edition, published in 1999, Stephan used the term DRAG (Devaux’s Removed Activity Guide), but since the 2nd edition, it was written as “Drag”.

In his book, Stephan described the Critical Path Drag metric as:

Critical Path Drag

Critical Path Drag is the quantification of the amount of time each activity is adding to the project.

To some extent this metric could be considered as an opposite to the Total Float metric.

Total Float

Total Float is the amount of time an activity can be delayed before its path becomes the longest path.

By contrast, drag is:

  • only#1 on the critical path; and
  • the amount of time by which an activity duration can be shortened#2 before its drag is reduced to zero.

Further decrease in the duration of the activity would not reduce the duration of the project as another path became critical. In other words, it is the amount of time that could potentially be saved on the project by reducing the duration of the activity (or removing an activity completely).

#1,2 The proposed explanation covers the majority of project scenarios, but not all of them. We will review such scenarios below.

Most of the software that computes Critical Path also could calculate Total Float (TF), but just a few can calculate Critical Path Drag, so this metric is still not well known. However, this computation is very important. Without understanding activity drags, well too often, implemented project optimisation measures don’t give the expected effect.

The formula for computing drag on a simple critical path network schedule is as follows:

  • If an activity is off the critical path, its drag = 0
  • If an activity is on the critical path and has nothing else in parallel#3, its drag = its duration
  • If an activity is on the critical path and has other activities in parallel, its drag is the lowest number between:

– activity duration
– total float of the parallel activity with the least total float

A programming formula may look something like this:
= IF (Critical = “Yes”, Min (duration, min({total float of parallel activities}), 0)

#3 Parallel activities belong to a parallel stream. They are not necessarily planned to be performed at the same time as the analysed activity.

Critical Path Drag Calculation

Let’s review the following simple project:

With all “Finish-to-Start” dependencies, the duration of this project is 18 days. Drag for first and last activities is equal to the duration of activities.
The drag for the second critical activity is only 3 days. This means that if the activity will be reduced by 3 days, the project also will be reduced by 3 days. Any further optimisation would not decrease the duration of the project as this activity would not be on the new critical path anymore.

Let’s assume it is possible to add resources to the 10-days activity and complete this activity twice quicker. The new duration of this activity will be 5 days:

The project has a new Critical Path and as we expected duration decreased to 15 days.

Drag for 2nd and 3rd critical activities is 2 days each. However, it doesn’t mean that if both activities are reduced by 2 days, the project will be 4 days shorter! The drag is not cumulative.

Negative Critical Path Drag

Let’s consider a slightly more complex example: a working typical fragment “1 km of Road Construction”. There are only 20 activities in this fragment, but there are much harder to calculate critical path drag manually. Let’s use a scheduling tool, Spider Project, to calculate CP drag for each activity:

1 km of Road Construction.

There are 10 critical activities and all of them have Critical path drag <>0. In this project fragment, the first and the last critical activities have CP drag equal to the duration of the activity. In other cases, drag is less than the activity duration. Also, there are 3 critical activities where drag is less than zero. Let’s analyse how it is possible.
As it was explained in the “Project Anti-Crashing Method” post, in some cases project duration could be reduced by increasing a critical activity duration:

In this example, the CP drag of the activity “C” will be negative. If the duration of this activity is reduced to zero, the duration of the project will be increased from 42 to 50 days. So, CP drag will be minus 8 days.
At the same time, if it is possible to increase the duration of activity “C” by 14 days, the duration of the project will be decreased from 42 to 28 days (!)

Critical Path Drag on non-critical activities

It is logical to think that project duration could be reduced by optimising activities on a critical path only. However, there are project scenarios when decreasing the duration of the non-critical activity could reduce the overall duration of the project.
In the previous post, we reviewed a project fragment when activities have different calendars.

Activity “A” only could be performed on weekdays and activity “B” only could be performed on weekends.

Activity “A” has 4 days of the total float, so it is not on the critical path. However, if we reduce the duration of this activity to 5 days, the overall duration also will be reduced from 14 days to 7 days.

So, the CP drag of activity “A” will be >0. How much exactly? Well, it depends..
If it is based on the activity “A” 5-days calendar, CP drag is 5 days. If 7-days calendar, CP drag is 7 days.

Summary

  • The Critical Path method gives project teams information to optimise their project plans, not the final schedule. The method has optimisation metrics for that.
  • Activity Drag is an important Critical Path metric that allows prediction of how the applied effort would shorten project duration
  • In some cases Activity Drag could be negative
  • When different calendars are applied non-critical activities may have a positive ‘Activity Drag’. Optimisation of these activities would shorten the project duration.

We are going to review other Critical Path optimisation metrics in future posts.

Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma

Hidden Project Schedule Opportunities

Hidden Project Schedule Opportunities

by | 3 Apr, 2022 | Blog

A few days ago, I had organised a poll on LinkedIn and asked a simple question: Can project duration potentially be reduced by decreasing the duration of non-critical activity (total float >0)?

While the poll is still open, and the final result may still slightly change, it is already clear that half of the responders believe that reducing an activity that is not on the critical path would never change the duration of the project, and another half don’t think so. Most of the project participants believe that they know how the critical path method works, so why is there no agreement on a simple question then?
By organising this poll, I wanted to demonstrate the fact that project management is not as simple as it is presented in project management trainings, and even in global standards or organisational frameworks (PMBOK, NASA, etc.). The courses and standards always simplify reality to make it easier to understand.
Apart from project management, it is hard to find another area where professionals continue to apply simplified methods to solve complex and complicated problems, and real project management is never simple. To pass a project management exam, what you need to know is not the same as what we need to know to manage projects!
A real-life project is not just a list of activities with ‘Finish-to-Start’ type of dependencies, as is shown in almost all books that explain project management methods (incl. critical path method) and techniques.

It also includes:

  • Start-to-Start, Finish-to-Finish and even Start-to-Finish dependencies;
  • Double dependencies;
  • Resource limits;
  • Hard & Soft constraints;
  • Different resource & activity calendars;
  • Lags & leads;
  • Risks & uncertainties.

Even the critical path method may not work as expected when these aspects are taken into account.

Let’s now go back to the question in the poll and find the correct answer. So far, in comments to the poll, there are no examples offered, that would demonstrate how a non-critical activity could potentially reduce the duration of the project. Let’s review a small project fragment:

Example

The fragment contains two linked (Finish-to-Start) activities with different calendars. The predecessor activity “A” has six days of duration and a 5-days (Mon-Fri) calendar. The successor activity has 2 days of duration and a weekend (Sat-Sun) calendar.

The duration of this fragment is 14 days. The activity “A” is not on the critical path as it has four days of the total float. However, if we could reduce this activity to 5 days, the overall duration will be reduced to 7 days:

This simple example demonstrates that in some cases, project duration could be reduced by decreasing the duration of a non-critical activity.
It is just one of the examples of “hidden opportunity” in our schedules. There are many others. Such opportunities often exist, but they are not obvious. Unfortunately, MS Project and Primavera don’t have built-in critical path metrics that could help project teams to identify project opportunities. I am going to explain such metrics in future posts.

Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma

Project Anti-Crashing Method

Project Anti-Crashing Method

by | 24 Mar, 2022 | Blog

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.

Anti-crashing

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

Crashing technic in scheduling:

Crashing is a project management method used to speed up a project’s timeline by adding extra resources without changing the project’s scope.

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.
Project Team assignment

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.

Let’s review the following example:

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.

Summary

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.

Anti-crashing is a project management method used to compress a schedule by reducing resources and without changing the project’s scope. This includes:

  • Reduce assigned resources
  • Assigned resources with a lower productivity rate
  • Change working calendars

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.

Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma